Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #14399 > unrolled thread

Beyond QA: Uploaders field hygiene

Back to article view | Back to linux.debian.project

Contents

  Beyond QA: Uploaders field hygiene Tobias Frost <tobi@debian.org> - 2026-08-15 10:40 +0200
    Re: Beyond QA: Uploaders field hygiene Jonas Smedegaard <dr@jones.dk> - 2026-08-15 12:30 +0200
      Re: Beyond QA: Uploaders field hygiene Jonas Smedegaard <dr@jones.dk> - 2026-08-15 13:30 +0200
      Re: Beyond QA: Uploaders field hygiene Jonas Smedegaard <dr@jones.dk> - 2026-08-16 11:00 +0200
        Re: Beyond QA: Uploaders field hygiene Simon Josefsson <simon@josefsson.org> - 2026-08-16 13:40 +0200
          Re: Beyond QA: Uploaders field hygiene Jonas Smedegaard <dr@jones.dk> - 2026-08-16 14:40 +0200
            Re: Beyond QA: Uploaders field hygiene Simon Josefsson <simon@josefsson.org> - 2026-08-16 16:10 +0200
      Re: Beyond QA: Uploaders field hygiene Simon Josefsson <simon@josefsson.org> - 2026-08-16 11:00 +0200
        Re: Beyond QA: Uploaders field hygiene Richard Lewis <richard.lewis.debian@googlemail.com> - 2026-08-16 13:40 +0200
          Re: Beyond QA: Uploaders field hygiene Andrey Rakhmatullin <wrar@debian.org> - 2026-08-16 14:10 +0200
            Re: Beyond QA: Uploaders field hygiene Marc Haber <mh+debian-project@zugschlus.de> - 2026-08-16 14:40 +0200
              Re: Beyond QA: Uploaders field hygiene Andrey Rakhmatullin <wrar@debian.org> - 2026-08-16 15:30 +0200
              Re: Beyond QA: Uploaders field hygiene Holger Levsen <holger@layer-acht.org> - 2026-08-16 15:30 +0200
                Re: Beyond QA: Uploaders field hygiene Marc Haber <mh+debian-project@zugschlus.de> - 2026-08-16 15:30 +0200
                  Re: Beyond QA: Uploaders field hygiene Holger Levsen <holger@layer-acht.org> - 2026-08-16 16:50 +0200
              Re: Beyond QA: Uploaders field hygiene Jonas Smedegaard <dr@jones.dk> - 2026-08-16 15:30 +0200
    Re: Beyond QA: Uploaders field hygiene Andrey Rakhmatullin <wrar@debian.org> - 2026-08-15 14:50 +0200
    Package metadata (was: Beyond QA: Uploaders field hygiene) Martin <debacle@debian.org> - 2026-08-15 17:40 +0200
      Re: Package metadata (was: Beyond QA: Uploaders field hygiene) Charles Plessy <plessy@debian.org> - 2026-08-23 11:10 +0200
        Re: Package metadata Martin <debacle@debian.org> - 2026-08-23 12:00 +0200
    Re: Beyond QA: Uploaders field hygiene Chris Hofstaedtler <zeha@debian.org> - 2026-08-15 21:10 +0200
    Using helper tools to mainain the Uploaders field Charles Plessy <plessy@debian.org> - 2026-08-16 23:50 +0200

Page 1 of 2  [1] 2  Next page →

#14399 — Beyond QA: Uploaders field hygiene

[Multipart message — attachments visible in raw view] — view raw

You all may have seen bugs filed by the MIA team to update the Uploaders
list. These bugs are usually the consequence of an MIA case concluding
that a contributor is no longer active and should no longer be listed as
an uploader.

But this is not just an MIA team task. The Uploaders field is part of
the package's maintenance metadata, and keeping it reasonably accurate
should be part of maintaining the package. If you notice that someone
listed there no longer appears to be actively maintaining the package,
please consider cleaning it up.

Nobody should be expected to investigate the current status of every
person listed there as part of every upload. This is a best-effort
maintenance task, not another bureaucratic requirement.

As the scope of the MIA process is contributor activities in Debian as a
whole, the MIA team cannot provide this information on a per-package
basis. If someone is still active in Debian but has quietly moved away
from a specific package, the maintainer is in the best position to
notice these package-specific changes. This complements the MIA team's
Debian-wide perspective and can also provide useful triggers for MIA
cases.

As a related point, when an ITS process results in a change of package
maintainership, the Uploaders field should be cleaned up, particularly
when Uploaders have not responded in the process.  The ITS procedure
should be updated to make this explicit; this is something that should
be discussed on debian-devel rather than anticipated here.

One final clarification: this mail is not intended to reopen the broader
discussion about the usefulness or future of the Uploaders field. That
is a separate discussion, and this is not the place to have it. For now,
we are simply describing the expectations under the current model. These
recommendations can and should be revisited if there are changes in how
we treat the Uploaders field.

Coming back to where we started: keeping the Uploaders field reasonably
up to date also means fewer "Remove from Uploaders" bugs from the MIA
team. A little best-effort maintenance here may therefore save everyone
some work later.

-- 
For the MIA team, with thanks to my fellow MIA team members Paul Gevers
and Nilesh Patra for their reviews and suggestions,
 
tobi

[toc] | [next] | [standalone]

#14400

[Multipart message — attachments visible in raw view] — view raw

Quoting Sebastiaan Couwenberg (2026-08-15 11:07:03)
> On 8/15/26 10:25 AM, Tobias Frost wrote:
> > But this is not just an MIA team task. The Uploaders field is part of
> > the package's maintenance metadata, and keeping it reasonably accurate
> > should be part of maintaining the package. If you notice that someone
> > listed there no longer appears to be actively maintaining the package,
> > please consider cleaning it up.
> 
> This will result in no-human-maintainers lintian issues, because many packages are on life support with team uploads where no person wants to commit to the package by adding themselves to Uploaders.
> 
> I guess we should just acknowledge that fact in the override comment.

If noone in a team wants to commit to a package by adding themselves as
in the Uploaders field, it seems that package is team-*un*maintained
and that fact should be acknowledged by moving the package to QA team.

Like Tobias, I am *not* proposing anything new here, I am reflecting on
our current rules for package maintenance in Debian.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#14401

[Multipart message — attachments visible in raw view] — view raw

Quoting Tobias Frost (2026-08-15 10:25:18)
> One final clarification: this mail is not intended to reopen the
> broader discussion about the usefulness or future of the Uploaders
> field. That is a separate discussion, and this is not the place to
> have it.

Quoting Sebastiaan Couwenberg (2026-08-15 12:41:27)
> On 8/15/26 12:10 PM, Jonas Smedegaard wrote:
> > Quoting Sebastiaan Couwenberg (2026-08-15 11:07:03)
> >> On 8/15/26 10:25 AM, Tobias Frost wrote:
> >>> But this is not just an MIA team task. The Uploaders field is part of
> >>> the package's maintenance metadata, and keeping it reasonably accurate
> >>> should be part of maintaining the package. If you notice that someone
> >>> listed there no longer appears to be actively maintaining the package,
> >>> please consider cleaning it up.
> >>
> >> This will result in no-human-maintainers lintian issues, because many packages are on life support with team uploads where no person wants to commit to the package by adding themselves to Uploaders.
> >>
> >> I guess we should just acknowledge that fact in the override comment.
> > 
> > If noone in a team wants to commit to a package by adding themselves as
> > in the Uploaders field, it seems that package is team-*un*maintained
> > and that fact should be acknowledged by moving the package to QA team.
> 
> The package is still team maintained, new upstream releases get packaged and bugs get triaged, but only the minimum amount of effort is put in those packages.
> 
> Orphaning the package will make it fall of radar and not even receive that little work.
> 
> I'd prefer for policy 5.6.3 to drop the "at least one human" requirement, to allow for team maintained packages no person takes responsibility for.

It seems you want to discuss changing the rules - that's confusing.

This thread is about existing rules.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#14405

[Multipart message — attachments visible in raw view] — view raw

Quoting Simon Josefsson (2026-08-16 10:31:59)
> Jonas Smedegaard <dr@jones.dk> writes:
> 
> > Quoting Sebastiaan Couwenberg (2026-08-15 11:07:03)
> >> On 8/15/26 10:25 AM, Tobias Frost wrote:
> >> > But this is not just an MIA team task. The Uploaders field is part of
> >> > the package's maintenance metadata, and keeping it reasonably accurate
> >> > should be part of maintaining the package. If you notice that someone
> >> > listed there no longer appears to be actively maintaining the package,
> >> > please consider cleaning it up.
> >> 
> >> This will result in no-human-maintainers lintian issues, because
> >> many packages are on life support with team uploads where no person
> >> wants to commit to the package by adding themselves to Uploaders.
> >> 
> >> I guess we should just acknowledge that fact in the override comment.
> >
> > If noone in a team wants to commit to a package by adding themselves as
> > in the Uploaders field, it seems that package is team-*un*maintained
> > and that fact should be acknowledged by moving the package to QA team.
> 
> I disagree -- and think this is at the core of what proper "team"
> maintainance of packages could be.
> 
> To me, team maintainance would be one where the team as a collective
> take responsibility for a package, but no individual person insists on
> the ego-boost of assigning personal ownership of the outcome, and
> through social means of the Uploader field signal that others should not
> feel the same level of ownership.

Do you mean "could be" and "would be" as future tense?

I am not simply nitpicking here - I genuinely find it quite confusing
to mix in speculations about future Debian into a conversation about
current rules in Debian.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#14408

[Multipart message — attachments visible in raw view] — view raw

Jonas Smedegaard <dr@jones.dk> writes:

>> I disagree -- and think this is at the core of what proper "team"
>> maintainance of packages could be.
>> 
>> To me, team maintainance would be one where the team as a collective
>> take responsibility for a package, but no individual person insists on
>> the ego-boost of assigning personal ownership of the outcome, and
>> through social means of the Uploader field signal that others should not
>> feel the same level of ownership.
>
> Do you mean "could be" and "would be" as future tense?

Yes.

> I am not simply nitpicking here - I genuinely find it quite confusing
> to mix in speculations about future Debian into a conversation about
> current rules in Debian.

Right, sorry for adding to that confusion.

I can't claim to understand what the current policy really is, or how it
is supposed to be implemented.  I'm not sure the MIA team post makes
that a lot more clearer either.  What seems clear is that the field is
not handled in a consistent way across the project, and the policies
around the fields could be clarified further.  So I jumped into
improvement mode, and wanted to take a step back and questioning the
basics.  I'm not sure we'll be able to find consensus on this topic
easily, but I think the current situation around Maintainer/Uploader
fields has a social dimension that affects long-term sustainability of
Debian so it is worthy of discussion.

/Simon

[toc] | [prev] | [next] | [standalone]

#14411

[Multipart message — attachments visible in raw view] — view raw

Quoting Simon Josefsson (2026-08-16 13:40:04)
> Jonas Smedegaard <dr@jones.dk> writes:
> 
> >> I disagree -- and think this is at the core of what proper "team"
> >> maintainance of packages could be.
> >> 
> >> To me, team maintainance would be one where the team as a collective
> >> take responsibility for a package, but no individual person insists on
> >> the ego-boost of assigning personal ownership of the outcome, and
> >> through social means of the Uploader field signal that others should not
> >> feel the same level of ownership.
> >
> > Do you mean "could be" and "would be" as future tense?
> 
> Yes.
> 
> > I am not simply nitpicking here - I genuinely find it quite confusing
> > to mix in speculations about future Debian into a conversation about
> > current rules in Debian.
> 
> Right, sorry for adding to that confusion.
> 
> I can't claim to understand what the current policy really is, or how it
> is supposed to be implemented.  I'm not sure the MIA team post makes
> that a lot more clearer either.  What seems clear is that the field is
> not handled in a consistent way across the project, and the policies
> around the fields could be clarified further.  So I jumped into
> improvement mode, and wanted to take a step back and questioning the
> basics.  I'm not sure we'll be able to find consensus on this topic
> easily, but I think the current situation around Maintainer/Uploader
> fields has a social dimension that affects long-term sustainability of
> Debian so it is worthy of discussion.

I agree that it is worthy of discussion whether our current rules make
sense to us or they need changing.

Please feel free to start such discussion - but separately from this
conversation, please.

This conversation is about clarifying our current rules, not which
different rules we might want instead, some day, if we can reach a
consensus on it.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#14416

[Multipart message — attachments visible in raw view] — view raw

Jonas Smedegaard <dr@jones.dk> writes:

> This conversation is about clarifying our current rules, not which
> different rules we might want instead, some day, if we can reach a
> consensus on it.

Great -- I'll fall back to reading the discussion so see if any easily
actionable rules materialize.  I'm not hopeful any sensible
interpretation of the current rules makes coherent sense or is
actionable at justifiable cost.  It would pacify my OCD to follow some
rule here; this concern often comes up for packages I contribute to.
The solution is mostly random depending on circumstances of the
particular package.  I don't care a lot about how the rule is as long as
it make sense and is actionable for all packages.

/Simon

[toc] | [prev] | [next] | [standalone]

#14406

[Multipart message — attachments visible in raw view] — view raw

Jonas Smedegaard <dr@jones.dk> writes:

> Quoting Sebastiaan Couwenberg (2026-08-15 11:07:03)
>> On 8/15/26 10:25 AM, Tobias Frost wrote:
>> > But this is not just an MIA team task. The Uploaders field is part of
>> > the package's maintenance metadata, and keeping it reasonably accurate
>> > should be part of maintaining the package. If you notice that someone
>> > listed there no longer appears to be actively maintaining the package,
>> > please consider cleaning it up.
>> 
>> This will result in no-human-maintainers lintian issues, because
>> many packages are on life support with team uploads where no person
>> wants to commit to the package by adding themselves to Uploaders.
>> 
>> I guess we should just acknowledge that fact in the override comment.
>
> If noone in a team wants to commit to a package by adding themselves as
> in the Uploaders field, it seems that package is team-*un*maintained
> and that fact should be acknowledged by moving the package to QA team.

I disagree -- and think this is at the core of what proper "team"
maintainance of packages could be.

To me, team maintainance would be one where the team as a collective
take responsibility for a package, but no individual person insists on
the ego-boost of assigning personal ownership of the outcome, and
through social means of the Uploader field signal that others should not
feel the same level of ownership.

I think this social signal related to the Maintainer/Uploaders field is
detrimental to a harmonous team spirit in the long run.  It establish
personal ownership and excludes others from feeling empowered to work on
the package, even though they are part of the same team, or if they are
a Debian Developer (which we would prefer to behave like a team).

I believe many Go packages in Debian has this property.  Few people
doing work on each of the dependent Go package cares about that
particular package strongly enough to insist that they have to must a
say in the packaging of it.  This is true for all the packages I help
work on, at least.

Thus, by getting rid of the Maintainer/Uploader fields, I believe we
could get a better collective long-term outcome for packages.  All
packages are collectively maintained by "Debian Developers", for which
we have a process for.  Yes, there will be local "accidents" where this
leads to bad mistakes in packages by people not familiar enough with a
package.  This will be used as an argument against this concept, and
against the people doing those mistakes.  I don't think it is a valid
argument.  It is an argument for improving QA tooling, documentation,
and collaboration processes.  Not for excluding people to contribute,
and further cementing the current situation.

We have some teams in Debian that operate like this, at least to me as
an outsider.  The release team, security team, and the DFSG team
generate artifacts that may sometime have personal names associated with
them (like security announcements), but it always feel like a group
effort rather than a personal effort.  I'm not sure people inside these
teams feel the same, but at least that's the perception I get from an
outside perspective.  I think that is a sign of maturity and health.

/Simon

[toc] | [prev] | [next] | [standalone]

#14407

Simon Josefsson <simon@josefsson.org> writes:

> Jonas Smedegaard <dr@jones.dk> writes:
>
>> Quoting Sebastiaan Couwenberg (2026-08-15 11:07:03)
>>> On 8/15/26 10:25 AM, Tobias Frost wrote:

>> If noone in a team wants to commit to a package by adding themselves as
>> in the Uploaders field, it seems that package is team-*un*maintained
>> and that fact should be acknowledged by moving the package to QA team.
>
> I disagree -- and think this is at the core of what proper "team"
> maintainance of packages could be.
>
> To me, team maintainance would be one where the team as a collective
> take responsibility for a package, but no individual person insists on
> the ego-boost of assigning personal ownership of the outcome

> Thus, by getting rid of the Maintainer/Uploader fields, I believe we
> could get a better collective long-term outcome for packages.

> Yes, there will be local "accidents" where this leads to bad mistakes
> in packages by people not familiar enough with a package.  This will
> be used as an argument against this concept

I think the argument for these fields isnt really about quality, but
more about the benefits of responsibility: sometimes there are different
ways of doing things (when do we start a transition? tabs or spaces in
postinst?  etc) and it's better if a small known group makes sets the
direction to avoid inconsistency, uncertainty and, hopefully,
arguments. It can also encourage people to take ownership and feel
involved.

(And keeping these fields in any form doesnt have to mean "only the
maintainer can ever make a change to this package", or "there has to be
a maintainer for every package" - fwiw i agree that lintian field is
unhelpful and should be downgraded)

[toc] | [prev] | [next] | [standalone]

#14409

[Multipart message — attachments visible in raw view] — view raw

On Sun, Aug 16, 2026 at 12:31:47PM +0100, Richard Lewis wrote:
>(And keeping these fields in any form doesnt have to mean "only the
>maintainer can ever make a change to this package", or "there has to be
>a maintainer for every package" - fwiw i agree that lintian field is
>unhelpful and should be downgraded)

As a reminder, having a human maintainer in a team-maintained package is a 
Policy "must".

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#14410

On Sun, Aug 16, 2026 at 04:55:03PM +0500, Andrey Rakhmatullin wrote:
>On Sun, Aug 16, 2026 at 12:31:47PM +0100, Richard Lewis wrote:
>>(And keeping these fields in any form doesnt have to mean "only the
>>maintainer can ever make a change to this package", or "there has to be
>>a maintainer for every package" - fwiw i agree that lintian field is
>>unhelpful and should be downgraded)
>
>As a reminder, having a human maintainer in a team-maintained package 
>is a Policy "must".

What exactly does that mean for my control file?

Greetings
Marc


-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

[toc] | [prev] | [next] | [standalone]

#14412

[Multipart message — attachments visible in raw view] — view raw

On Sun, Aug 16, 2026 at 02:20:00PM +0200, Marc Haber wrote:
>>>(And keeping these fields in any form doesnt have to mean "only the
>>>maintainer can ever make a change to this package", or "there has to be
>>>a maintainer for every package" - fwiw i agree that lintian field is
>>>unhelpful and should be downgraded)
>>
>>As a reminder, having a human maintainer in a team-maintained 
>>package is a Policy "must".
>
>What exactly does that mean for my control file?

*Technically* nothing AFAIK (as it's not in the RC policy). Most of 
lintian is like that though.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#14413

[Multipart message — attachments visible in raw view] — view raw

On Sun, Aug 16, 2026 at 02:20:00PM +0200, Marc Haber wrote:
> > As a reminder, having a human maintainer in a team-maintained package is
> > a Policy "must".
> What exactly does that mean for my control file?

it means, that if your control file doesnt contain a human uploader or
maintainer, your package is seriously buggy.


-- 
cheers,
	Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

"The two hardest problems in computer science are: (i) people, (ii), convincing
computer scientists that the hardest problem in computer science is people, and,
(iii) off by one errors." - Jeffrey P. Bigham

[toc] | [prev] | [next] | [standalone]

#14415

On Sun, Aug 16, 2026 at 12:58:14PM +0000, Holger Levsen wrote:
>On Sun, Aug 16, 2026 at 02:20:00PM +0200, Marc Haber wrote:
>> > As a reminder, having a human maintainer in a team-maintained package is
>> > a Policy "must".
>> What exactly does that mean for my control file?
>
>it means, that if your control file doesnt contain a human uploader or
>maintainer, your package is seriously buggy.

No need for a snappy answer when the original statement was missing the 
part you have mentioned.


-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

[toc] | [prev] | [next] | [standalone]

#14417

[Multipart message — attachments visible in raw view] — view raw

On Sun, Aug 16, 2026 at 03:27:30PM +0200, Marc Haber wrote:
> No need for a snappy answer when the original statement was missing the part
> you have mentioned.
 
why do you even ask if you cannot deal with a short answer?


-- 
cheers,
	Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

If you liked Corona, you will also enjoy the upcoming global climate disaster.

[toc] | [prev] | [next] | [standalone]

#14414

[Multipart message — attachments visible in raw view] — view raw

Quoting Marc Haber (2026-08-16 14:20:00)
> On Sun, Aug 16, 2026 at 04:55:03PM +0500, Andrey Rakhmatullin wrote:
> >On Sun, Aug 16, 2026 at 12:31:47PM +0100, Richard Lewis wrote:
> >>(And keeping these fields in any form doesnt have to mean "only the
> >>maintainer can ever make a change to this package", or "there has to be
> >>a maintainer for every package" - fwiw i agree that lintian field is
> >>unhelpful and should be downgraded)
> >
> >As a reminder, having a human maintainer in a team-maintained package 
> >is a Policy "must".
> 
> What exactly does that mean for my control file?

That it must list at least one active, human maintainer, in either of
the fields "Maintainer" or "Uploaders". And as Tobias points out
initiating this thread, known inactive human maintainers should be
dropped from those fields (only "should" - you don't violate any
policy by having crap in those fields, but make life harder for your
fellow developers in the MIA team by doing so).

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#14402

[Multipart message — attachments visible in raw view] — view raw

Thanks.

Many of my packages have "legacy" content in Uploaders (people who were 
in that field when I started maintaining those packages) and I always 
wondered what to do with that.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#14403 — Package metadata (was: Beyond QA: Uploaders field hygiene)

Which reminds me of an old idea somebody had decades ago: Having a
metadata database (sorry for the pleonasm, if it is one) in addition to
the fields in the package itself. That way updates of maintainer,
uploader, upstream homepage, etc. would not *require* a package upload.
At least on online services, such as tracker.d.o, the updated data would
be shown. Less CO₁ btw.! Technically, data could be taken from VCS, as
long as the VCS fields don't change.

(That would not change anything Tobi wrote, regarding hygiene.)

[toc] | [prev] | [next] | [standalone]

#14420 — Re: Package metadata (was: Beyond QA: Uploaders field hygiene)

Le Sat, Aug 15, 2026 at 03:03:48PM +0000, Martin a écrit :
>Which reminds me of an old idea somebody had decades ago: Having a
>metadata database (sorry for the pleonasm, if it is one) in addition to
>the fields in the package itself.

Hi Martin,

Maybe this one?

https://wiki.debian.org/UpstreamMetadata#Upstream_MEtadata_GAthered_with_YAml_.28UMEGAYA.29

I vividly remember when I had the idea on my bicycle.  It felt so good.

Have a nice week-end,

Charles

-- 
Charles Plessy                         Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team         http://www.debian.org/devel/debian-med
Tooting from work,               https://fediscience.org/@charles_plessy
Tooting from home,                 https://framapiaf.org/@charles_plessy

[toc] | [prev] | [next] | [standalone]

#14421 — Re: Package metadata

On 2026-08-23 12:23, Charles Plessy wrote:
> Le Sat, Aug 15, 2026 at 03:03:48PM +0000, Martin a écrit :
>>Which reminds me of an old idea somebody had decades ago: Having a
>>metadata database (sorry for the pleonasm, if it is one) in addition to
>>the fields in the package itself.
>
> https://wiki.debian.org/UpstreamMetadata#Upstream_MEtadata_GAthered_with_YAml_.28UMEGAYA.29

Yes. But I wonder, if only *upstream* metadata should be fetched from
VCS. Some fields from debian/control could, too, as long as not version
dependant. With the exception of VCS fields, maybe.

> I vividly remember when I had the idea on my bicycle.  It felt so good.

Best ideas come on the bicycle. Always!

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.project

csiph-web