[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Team uploads.

Charles Plessy wrote:
> Dear all,
> It was proposed in 2009 to formalise "Team uploads" in analogy to the "QA
> uploads", as a special case of NMU, where most conventions are relaxed.
> http://lists.debian.org/e13a36b30904052052g73850787vcc8b2035640d75b7@mail.gmail.com
> While there was interest, the discussion eventually ended with no action.

I personally like the idea of formalizing team uploads. So far I have
signed packages off by the team - which as a consequence means the
package does not show up on my QA page. As a non-DD, I have to find
sponsors and "lintian clean" packages just "sells better".
  Having read the previous mail exchanges, however, I see the logic in
not using the team and accepting the two lintian warnings.

> In the context of the Debian Med packaging team, I have started to make “Team
> uploads”, for packages that are maintained by my team but for which I do not
> want to add myself in the Uploaders field.
> For these NMUs, I apply the following exceptions:
>  - Normal incementation of version number,
>  - no delay,
>  - no patch to the BTS, but a direct commit to our repository,
>  - start the changelog by a “Team upload.” entry.

In my team (pkg-java) we seem to treat these upload as completely normal
Maintainer Uploads; meaning that the "Team Uploader" is not restricted
to "minimal changes" but may[1] fix whatever needs to be done (e.g. fix
lintian warnings/errors).
  Personally I like this because just doing a NMU-like upload leaves the
package in a mess and unattractive for people to actually take over.

There was a debate about the usage of MU-versioning would make it harder
to track with the package do not have a(n active) long term uploader. I
think this is more of a problem for the team and no QA at first. Because
either the team will pull their ${noun} together every now and then to
fix the package (meaning it is regularly[2] updated) or it will wither
and wane like any other unmaintained package.
  In the former case the package may not be getting as much love as it
ought too get, but the team will keep it "release ready" and in the
latter case it will get NMU repeatedly (from non-team members) like a
"normal" unmaintained package.

It may be a better solution for teams to have a (e.g.) wnpp-like package
to trace which of their packages need a new long term maintainer.
Reporting bugs against wnpp itself sort of suggests that the team is
orphaning it, which is (usually) not the case.

> This triggers Lintian warnings, that I ignore. The attached untested patch
> may solve the problem.
> If others are interested to follow the same approach, I propose to use the following
> wiki page to draft a common reference: http://wiki.debian.org/TeamUpload.
> Have a nice sunday,

Thank you, I am having a nice Sunday; I hope you do as well,

[1] Possibly "should"/"must" - I have never tried leaving unrelated
lintian warnings/errors (to the bug(s) I am fixing) in the package.

[2] Being a very relative term here.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: