Re: Team uploads.
On Sun, Mar 7, 2010 at 1:47 PM, Charles Plessy ple...@debian.org wrote: 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. As the initiator of the previous thread, I'd like to thank you for pushing this. As far as implementation details go, would it be a good idea to also add dch --team, which would produce the right string for the purposes of quieting lintian? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e13a36b31003101808x5c2900f7qb9efa82236fec...@mail.gmail.com
Re: Team uploads.
On Thu, 2010-03-11 at 10:08 +0800, Paul Wise wrote: As far as implementation details go, would it be a good idea to also add dch --team, which would produce the right string for the purposes of quieting lintian? I think that would be useful. I think if we don't do this, many will simply wing it when writing the changelog rather than looking up the 'correct' way to quiet lintian. A thought: Maybe make it accept dch --team email/name of team for the cases where the QA team for some reason may be uploading in place of the normal team, or in the cases where there normally is no team. (Sorry if that is somewhat confusing, I have been up for 26 hrs I am seeing yellow elephants...) -- Luke Cycon lcy...@gmail.com signature.asc Description: This is a digitally signed message part
Re: Team uploads.
Le Sun, Mar 07, 2010 at 02:42:02PM +0100, Niels Thykier a écrit : 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). Hi Niels, I agree to this. Actually I forgot to add the minimal changes to the list of exceptions. In the end, it is simpler to describe a team upload as a normal upload made by a member of the team, rather than as a special case of NMU with exceptions covering all the rules. Are there other persons interested? Shall I go ahead and submit a patch to Lintian and the Developers Reference (plus perhaps the Policy to include a footnote containing the special changelog lines for NMU, QA, security and team uploads)? Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100308134047.ga30...@kunpuu.plessy.org
Re: Team uploads.
Hi Charles, On Mon, Mar 08, 2010 at 10:40:47PM +0900, Charles Plessy wrote: Are there other persons interested? Shall I go ahead and submit a patch to Lintian and the Developers Reference (plus perhaps the Policy to include a footnote containing the special changelog lines for NMU, QA, security and team uploads)? Fine for me. I understand there is some use of this proposal in teams and I don't see big reasons against it (those being said in the last thread about this). There is just one thing that bothers me: this new feature would invite teams to actually put noone in the uploaders list. The team would be maintainer and no real person would be listed in the package. And I don't like this possible outcome. From a QA (and MIA) perspective this is not a good idea. So if you're going to write patches as you said, please consider adding at least a should to policy about setting a real person as uploader when the maintainer is a team (i.e. mailing list). Hauke signature.asc Description: Digital signature
Re: Team uploads.
Jan Hauke Rahm wrote: Hi Charles, On Mon, Mar 08, 2010 at 10:40:47PM +0900, Charles Plessy wrote: Are there other persons interested? Shall I go ahead and submit a patch to Lintian and the Developers Reference (plus perhaps the Policy to include a footnote containing the special changelog lines for NMU, QA, security and team uploads)? Fine for me. I understand there is some use of this proposal in teams and I don't see big reasons against it (those being said in the last thread about this). There is just one thing that bothers me: this new feature would invite teams to actually put noone in the uploaders list. The team would be maintainer and no real person would be listed in the package. And I don't like this possible outcome. From a QA (and MIA) perspective this is not a good idea. So if you're going to write patches as you said, please consider adding at least a should to policy about setting a real person as uploader when the maintainer is a team (i.e. mailing list). Hauke Hi lintian already warns if a package has no human uploaders and a list as maintainer (the exception being the QA list) [1], so I believe this has already been taken care of. ~Niels [1] http://lintian.debian.org/tags/no-human-maintainers.html signature.asc Description: OpenPGP digital signature
Re: Team uploads.
On Mon, Mar 08, 2010 at 10:40:47PM +0900, Charles Plessy wrote:
Are there other persons interested? Shall I go ahead and submit a
patch to Lintian and the Developers Reference (plus perhaps the Policy
to include a footnote containing the special changelog lines for NMU,
QA, security and team uploads)?
I'm interested in the issue, but I confess the details of the 'solution'
you are proposing are not clear to me. For instance, how does lintian
know about the team members? (Not that it should enforce a specific
place where they should belong, I just want to understand better what
exactly you're proposing ...
How about adding to the wiki page http://wiki.debian.org/TeamUpload a
clear summary of the actual proposal?
Thanks for having revamped this,
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Team uploads.
Jan Hauke Rahm j...@debian.org writes: There is just one thing that bothers me: this new feature would invite teams to actually put noone in the uploaders list. The team would be maintainer and no real person would be listed in the package. Lintian attempts to detect this but may not be able to depending on where the maintenance team list is hosted. And I don't like this possible outcome. From a QA (and MIA) perspective this is not a good idea. Wholeheartedly agreed. So if you're going to write patches as you said, please consider adding at least a should to policy about setting a real person as uploader when the maintainer is a team (i.e. mailing list). devref 5.12 already has something about this, I believe. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y6i2iuz8@windlord.stanford.edu
Re: Team uploads.
Charles Plessy ple...@debian.org writes: Are there other persons interested? Shall I go ahead and submit a patch to Lintian and the Developers Reference (plus perhaps the Policy to include a footnote containing the special changelog lines for NMU, QA, security and team uploads)? Just for the record, in general for things like this the patch to the Developers Reference being accepted is a prerequisite for the Lintian patch being accepted (or at least some clear consensus, in case the devref maintainers are just busy). We try not to make policy in Lintian if it's already addressed somewhere else more authoritative (although don't always succeed). I personally think this is an odd idea and still think that it would be better to just add yourself to Uploaders, but I don't really care enough to actively argue against it. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tysqiuvr@windlord.stanford.edu
Re: Team uploads.
On Mon, Mar 08, 2010 at 09:28:11AM -0800, Russ Allbery wrote: Jan Hauke Rahm j...@debian.org writes: There is just one thing that bothers me: this new feature would invite teams to actually put noone in the uploaders list. The team would be maintainer and no real person would be listed in the package. Lintian attempts to detect this but may not be able to depending on where the maintenance team list is hosted. Although lintian is used by hopefully all maintainers (and is a great tool for such tasks), it is not the place to clarify how to package. It is the place to check what elsewhere was decided. And I don't like this possible outcome. From a QA (and MIA) perspective this is not a good idea. Wholeheartedly agreed. So if you're going to write patches as you said, please consider adding at least a should to policy about setting a real person as uploader when the maintainer is a team (i.e. mailing list). devref 5.12 already has something about this, I believe. Not quite. 5.12 recommends a way to deal with team maintenance but is not enough here. Reading 5.12 (list as maintainer, the one who feels responsible as uploader) still allows having no uploader when noone feels responsible. I'd like to see a clear and unmistakle sentence somewhere (i.e. policy or devref) saying that a package should have a real person as maintainer or uploader. But now that I think of it, this is not necessarily related to what Charles proposes. Hauke signature.asc Description: Digital signature
Re: Team uploads.
Jan Hauke Rahm j...@debian.org writes: Not quite. 5.12 recommends a way to deal with team maintenance but is not enough here. Reading 5.12 (list as maintainer, the one who feels responsible as uploader) still allows having no uploader when noone feels responsible. I'd like to see a clear and unmistakle sentence somewhere (i.e. policy or devref) saying that a package should have a real person as maintainer or uploader. But now that I think of it, this is not necessarily related to what Charles proposes. Agreed on both counts. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4tmiudr@windlord.stanford.edu
Re: Team uploads.
Dear all, I have updated http://wiki.debian.org/TeamUpload and submitted #573110 to the Developers Reference. I tend to manage my priorities by caring first of the packages listed in my QA page, and then the other packages of my team. But if I add myself as an uploader to all the packages I touch, the first will finally converge towards the second, which is not useful… After the patch to the Dev. Ref. is accepted, I will submit a simple patch to Lintian. I do not think that it is necessary for Lintian to cross-check if the DD doing the team upload is really a team member. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100309020527.ge25...@kunpuu.plessy.org
Re: Team uploads.
Charles Plessy ple...@debian.org writes: After the patch to the Dev. Ref. is accepted, I will submit a simple patch to Lintian. I do not think that it is necessary for Lintian to cross-check if the DD doing the team upload is really a team member. I agree. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zl2i452n@windlord.stanford.edu
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/e13a36b30904052052g73850787vcc8b2035640d7...@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,
~Niels
[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.
signature.asc
Description: OpenPGP digital signature
Team uploads.
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/e13a36b30904052052g73850787vcc8b2035640d7...@mail.gmail.com
While there was interest, the discussion eventually ended with no action.
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.
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,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
diff --git a/checks/nmu b/checks/nmu
index fd2febf..80a5eb5 100644
--- a/checks/nmu
+++ b/checks/nmu
@@ -42,6 +42,7 @@ my $info = shift;
my $changelog_mentions_nmu = 0;
my $changelog_mentions_local = 0;
my $changelog_mentions_qa = 0;
+my $changelog_mentions_team_upload = 0;
# This isn't really an NMU check, but right now no other check looks at
# debian/changelog in source packages. Catch a debian/changelog file that's a
@@ -60,7 +61,7 @@ my $changes = $entry-Changes;
$changes =~ s/^(\s*\n)+//;
my $firstline = (split('\n', $changes))[0];
-# Check the first line for QA and NMU mentions.
+# Check the first line for QA, NMU or team upload mentions.
if ($firstline) {
local $_ = $firstline;
if (/\bnmu\b/i or /non-maintainer upload/i) {
@@ -70,6 +71,8 @@ if ($firstline) {
}
$changelog_mentions_local = 1 if /\blocal\s+package\b/i;
$changelog_mentions_qa = 1 if /orphan/i or /qa (?:group )?upload/i;
+ $changelog_mentions_team_upload = 1 if /* Team upload/i;
+
}
my $version = $info-field(version);
@@ -111,6 +114,9 @@ if ($maintainer =~ /packag...@qa.debian.org/) {
if $version_nmuness == 1;
tag changelog-should-mention-qa,
if !$changelog_mentions_qa;
+} elsif ($changelog_mentions_team_upload) {
+ tag team-upload-has-incorrect-version-number, $version
+ if $version_nmuness == 1;
} else {
# Local packages may be either NMUs or not.
unless ($changelog_mentions_local || $version_local) {
Re: Team uploads
On Tue Apr 07 23:21, Gunnar Wolf wrote: In the pkg-perl group, at least, it is not at all uncommon that a team member (usually not a DD) works on a package and tags it as ready for upload. And then a DD just comes along, checks it, builds and uploads - without having worked with it. It is not precisely a sponsored upload, but a team activity for both. So, yes, we have usually worked aroud it by adding both the people who did the work and the DD to Uploaders: In that case, I'd just treat it as a sponsored upload, since the DD won't be in the changelog trailer. That's certainly what I do with pkg-java. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Team uploads
On Tue Apr 07 10:38, Charles Plessy wrote: so in the end, can we use the “ * QA upload.” special first line for non-uploader uploads without breaking the QA infrastructure? That's wrong if the maintainer is not debian...@lists. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Team uploads
Charles Plessy ple...@debian.org writes: Le Mon, Apr 06, 2009 at 11:51:54AM -0700, Russ Allbery a écrit : There still should be some humans in Maintainer/Uploaders who are taking primary responsibility for the package, but I think other team members should be able to do QA-style fixes and transition uploads without using NMU versioning or add themselves to Uploaders and hence imply that they're taking ongoing responsibility for the package. so in the end, can we use the “ * QA upload.” special first line for non-uploader uploads without breaking the QA infrastructure? No, that is reserved for orphaned packages and triggers other checks to ensure the maintainer is set appropriately. I think the conversation hasn't reached a conclusion yet about the right way to do this, but I doubt it would be reusing the key phrase for orphaned package uploads. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
On Mon, 06 Apr 2009, Russ Allbery wrote: Charles Plessy ple...@debian.org writes: so in the end, can we use the “ * QA upload.” special first line for non-uploader uploads without breaking the QA infrastructure? No, that is reserved for orphaned packages and triggers other checks to ensure the maintainer is set appropriately. I think the conversation hasn't reached a conclusion yet about the right way to do this, but I doubt it would be reusing the key phrase for orphaned package uploads. The simplest solution would be to use * Team upload as a new key phrase to mark such packages. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
Raphael Hertzog hert...@debian.org writes: On Mon, 06 Apr 2009, Russ Allbery wrote: Charles Plessy ple...@debian.org writes: so in the end, can we use the “ * QA upload.” special first line for non-uploader uploads without breaking the QA infrastructure? No, that is reserved for orphaned packages and triggers other checks to ensure the maintainer is set appropriately. I think the conversation hasn't reached a conclusion yet about the right way to do this, but I doubt it would be reusing the key phrase for orphaned package uploads. The simplest solution would be to use * Team upload as a new key phrase to mark such packages. Can anyone think of any drawbacks to that? (We really need a document somewhere listing all these key phrases -- I wonder if that would be appropriate for Policy given how much software now cares.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
Matthew Johnson dijo [Mon, Apr 06, 2009 at 08:24:44AM +0100]: It is a useful concept, but I would like to consider them as special case NMUs rather than special case MUs. Quite apart from the issue of deciding whether or not something is 'team maintained' in all cases, if you are a member of the team and you are making uploads to the package, then you should just add yourself to uploaders, surely...? That said, the option so far which is least bad is Team Upload in the same way as QA Upload, i.e. no NMU version number, no NMU procedures, no delay, etc, just something to ack the mismatch of changed-by and uploaders/maintainer. In the pkg-perl group, at least, it is not at all uncommon that a team member (usually not a DD) works on a package and tags it as ready for upload. And then a DD just comes along, checks it, builds and uploads - without having worked with it. It is not precisely a sponsored upload, but a team activity for both. So, yes, we have usually worked aroud it by adding both the people who did the work and the DD to Uploaders: Still, even if the package is group-maintained, it is good to be able to note who is most familiar or has worked most with the package - And the current scheme does not properly represent it (save for parsing debian/changelog) -- Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
On Mon, Apr 06, 2009 at 11:52:54AM +0800, Paul Wise wrote: In Debian we have several teams working on maintaining large numbers of packages (pkg-games, pkg-perl, pkg-gnome for example). I proposed[1] to silence the lintian NMU warnings in the case of team uploads; where the person doing the upload is a member of the team in Maintainers but is not present in Uploaders. Does anyone think this concept of team uploads has merit? It is a useful concept, but I would like to consider them as special case NMUs rather than special case MUs. - NMU version number - first changelog line contains TU / team upload / team NMU / ... - no need to put patch in bug - no need for NMU delay - no need to upload to delayed queue My reasoning is that a package that has had only team uploads for three years is a package where effectively no human is taking charge for maintaining it, just as a package that has had only NMU uploads in three years; I'd like QA / potential adopters to see that in the sequence of version numbers as they do now. -- Lionel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
On Mon Apr 06 08:18, Lionel Elie Mamane wrote: On Mon, Apr 06, 2009 at 11:52:54AM +0800, Paul Wise wrote: In Debian we have several teams working on maintaining large numbers of packages (pkg-games, pkg-perl, pkg-gnome for example). I proposed[1] to silence the lintian NMU warnings in the case of team uploads; where the person doing the upload is a member of the team in Maintainers but is not present in Uploaders. Does anyone think this concept of team uploads has merit? It is a useful concept, but I would like to consider them as special case NMUs rather than special case MUs. Quite apart from the issue of deciding whether or not something is 'team maintained' in all cases, if you are a member of the team and you are making uploads to the package, then you should just add yourself to uploaders, surely...? That said, the option so far which is least bad is Team Upload in the same way as QA Upload, i.e. no NMU version number, no NMU procedures, no delay, etc, just something to ack the mismatch of changed-by and uploaders/maintainer. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Team uploads
On Mon, Apr 06, 2009 at 08:18:33AM +0200, Lionel Elie Mamane wrote: On Mon, Apr 06, 2009 at 11:52:54AM +0800, Paul Wise wrote: In Debian we have several teams working on maintaining large numbers of packages (pkg-games, pkg-perl, pkg-gnome for example). I proposed[1] to silence the lintian NMU warnings in the case of team uploads; where the person doing the upload is a member of the team in Maintainers but is not present in Uploaders. Does anyone think this concept of team uploads has merit? It is a useful concept, but I would like to consider them as special case NMUs rather than special case MUs. - NMU version number - first changelog line contains TU / team upload / team NMU / ... - no need to put patch in bug - no need for NMU delay - no need to upload to delayed queue My reasoning is that a package that has had only team uploads for three years is a package where effectively no human is taking charge for maintaining it, just as a package that has had only NMU uploads in three years; I'd like QA / potential adopters to see that in the sequence of version numbers as they do now. I don't understand; what is the problem with team uploads? Sure, there can be problems in inactive teams, but just because some packages had team uploads doesn't mean they need special QA attention. Besides, I think the Gnome team still puts all team members into Uploaders via some debian/control pre-processing, maybe for the above reason. Getting rid of debian/control.in (unless needed otherwise) due to better team maintership handling might be good thing. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
On Mon, Apr 06, 2009 at 09:27:53AM +0200, Michael Banck wrote: On Mon, Apr 06, 2009 at 08:18:33AM +0200, Lionel Elie Mamane wrote: On Mon, Apr 06, 2009 at 11:52:54AM +0800, Paul Wise wrote: I proposed[1] to silence the lintian NMU warnings in the case of team uploads; where the person doing the upload is a member of the team in Maintainers but is not present in Uploaders. It is a useful concept, but I would like to consider them as special case NMUs rather than special case MUs. - NMU version number - first changelog line contains TU / team upload / team NMU / ... - no need to put patch in bug - no need for NMU delay - no need to upload to delayed queue My reasoning is that a package that has had only team uploads for three years is a package where effectively no human is taking charge for maintaining it, just as a package that has had only NMU uploads in three years; I'd like QA / potential adopters to see that in the sequence of version numbers as they do now. I don't understand; what is the problem with team uploads? Sure, there can be problems in inactive teams, but just because some packages had team uploads doesn't mean they need special QA attention. Just like NMUs: just because a package had a small number of NMUs does not mean it needs special QA attention. But a pattern of only NMUs is a tag for QA attention. As Paul means them (I'm in the team, but for this particular package I do work on it once, but don't take charge for any future work), team uploads have the same characteristic: if there are only team uploads, it is an indicator that nobody within the team feels responsible for the package. Yes, there can be corner cases where this is not the case. -- Lionel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
Le Mon, Apr 06, 2009 at 11:52:54AM +0800, Paul Wise a écrit : In Debian we have several teams working on maintaining large numbers of packages (pkg-games, pkg-perl, pkg-gnome for example). I proposed[1] to silence the lintian NMU warnings in the case of team uploads; where the person doing the upload is a member of the team in Maintainers but is not present in Uploaders. Does anyone think this concept of team uploads has merit? Hi Paul, I think that it is a good concept, but the linian warning has probably a good reason to exist. For instance, if a bug is closed as part of a Team upload, won't the BTS expect a NMU acknowledgement anyway? Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
On Mon, Apr 06, 2009 at 05:05:40PM +0900, Charles Plessy wrote: Le Mon, Apr 06, 2009 at 11:52:54AM +0800, Paul Wise a écrit : In Debian we have several teams working on maintaining large numbers of packages (pkg-games, pkg-perl, pkg-gnome for example). I proposed[1] to silence the lintian NMU warnings in the case of team uploads; where the person doing the upload is a member of the team in Maintainers but is not present in Uploaders. Does anyone think this concept of team uploads has merit? Hi Paul, I think that it is a good concept, but the linian warning has probably a good reason to exist. For instance, if a bug is closed as part of a Team upload, won't the BTS expect a NMU acknowledgement anyway? But it's not an NMU, the Team is effectively the maintainer. If the team isn't the maintainer, it's not team-maintained, by definition, I'd say. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
Le Monday 06 April 2009 08:18:33 Lionel Elie Mamane, vous avez écrit : My reasoning is that a package that has had only team uploads for three years is a package where effectively no human is taking charge for maintaining it, just as a package that has had only NMU uploads in three years; I'd like QA / potential adopters to see that in the sequence of version numbers as they do now. I do not agree with you. In the ocaml team, I have prepared uploads for some transitions for package for which I am not in the uploader field. I am not in the uploaders because I am not the main responsible for this packaging, however my upload uses the correct workflow, and does not mean that there is no maintainer, but only that for small repetitive tasks, another member of the team can take care of it. Hence, requiring NMU versioning and external patch system would really be a waste of time that would anihilate the efficiency of working in a team. That said, I have nothing strong against the lintian warning. After all, it is only a warning, and the NMU issues can be worked-out between human beings for sure... :-) Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
On Mon, Apr 06, 2009 at 10:46:19AM +0200, Romain Beauxis wrote: Le Monday 06 April 2009 08:18:33 Lionel Elie Mamane, vous avez écrit : My reasoning is that a package that has had only team uploads for three years is a package where effectively no human is taking charge for maintaining it, just as a package that has had only NMU uploads in three years; I'd like QA / potential adopters to see that in the sequence of version numbers as they do now. I do not agree with you. In the ocaml team, I have prepared uploads for some transitions for package for which I am not in the uploader field. I am not in the uploaders because I am not the main responsible for this packaging, however my upload uses the correct workflow, and does not mean that there is no maintainer, but only that for small repetitive tasks, another member of the team can take care of it. Yes, but if the main responsible for this package has done no work on it for three years, it is a sign that maybe he doesn't feel responsible anymore, or does not have time anymore or something like that. Not proof, just a sign. Just like NMUs. It falls in very well in the example you gave; some transitions were handled by mass-bug filing + delay + NMU of packages that had not transitioned, so the situation looks similar. For team uploads we remove the bug filing, the delay, most of the NMU procedures (delay, special handling of introduced patch, ...), but keep the NMU numbering. Hence, requiring NMU versioning and external patch system I did not say one should require an external patch system, quite the contrary. I wrote no need to put patch in bug, generalise that to no need to treat the change / patch specially; just commit it in the team's VCS repository, if that's what is usually done in that team. would really be a waste of time that would anihilate the efficiency of working in a team. The only burden I propose imposing is the NMU versioning, which does not feel to me like it is additional work. Instead of writing -3, write -2.1; only two keystrokes more. -- Lionel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
On Mon, 06 Apr 2009, Lionel Elie Mamane wrote: Just like NMUs: just because a package had a small number of NMUs does not mean it needs special QA attention. But a pattern of only NMUs is a tag for QA attention. As Paul means them (I'm in the team, but for The point of team upload is precisely so that you can update the package and not take responsibility for a package that you don't want to maintain in the long run. I was in many Uploaders field because lintian complain if you are not in Uploaders/Maintainer, yet I was there only for a single team upload for a perl or a python transition and using an NMU version would have been wrong because everything was properly done in the team VCS and there was no NMU to integrate for the next person working on the package. So I object to using NMU version for team uploads but I would like to have a mechanism for a team upload that doesn't lead to people adding themselves in Uploaders when they don't have a (real/long-term) commitment to the package. Then, the Maintainer/Uploader field would be again more accurate to know if we have people that care about the packages or not. So I see this change as good move to better detect that nobody cares about the package. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
On Mon, 06 Apr 2009, Charles Plessy wrote: I think that it is a good concept, but the linian warning has probably a good reason to exist. For instance, if a bug is closed as part of a Team upload, won't the BTS expect a NMU acknowledgement anyway? IIRC that concept died when we introduced version tracking so it should cause any problem. Bugs are always version closed (and no more tagged fixed/fixed-in-nmu). Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
On Mon, 06 Apr 2009, Emilio Pozuelo Monfort wrote: Raphael Hertzog wrote: So I object to using NMU version for team uploads but I would like to have a mechanism for a team upload that doesn't lead to people adding themselves in Uploaders when they don't have a (real/long-term) commitment to the package. You can put the team name and mailing list in the changelog. That will avoid the lintian warning and you can look for team uploads by looking at uploads with the team name in the Changed-By field. A recent example: I have seen that already but it's ugly as well. Changelog are written by humans and not lists and I like to have the name of someone (to blame) in the changelog entry. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
On 06/04/09 at 19:48 +0900, Charles Plessy wrote: Le Mon, Apr 06, 2009 at 12:13:45PM +0200, Raphael Hertzog a écrit : On Mon, 06 Apr 2009, Charles Plessy wrote: I think that it is a good concept, but the linian warning has probably a good reason to exist. For instance, if a bug is closed as part of a Team upload, won't the BTS expect a NMU acknowledgement anyway? IIRC that concept died when we introduced version tracking so it should cause any problem. Bugs are always version closed (and no more tagged fixed/fixed-in-nmu). Good :) Does it mean that the Developers Reference must be updated? Index: pkgs.dbk === --- pkgs.dbk (revision 6668) +++ pkgs.dbk (working copy) @@ -2073,13 +2073,6 @@ work on it. /para -para -To acknowledge an NMU, include its changes and changelog entry in your next -maintainer upload. If you do not acknowledge the NMU by including the -NMU changelog entry in your changelog, the bugs will remain closed in the -BTS but will be listed as affecting your maintainer version of the package. -/para - /section section id=nmu-binnmu No, that's still correct. If you don't include the changelog entry fixing the bug, then the BTS' version tracking will be confused, and think that your version still has the bug. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
Le Mon, Apr 06, 2009 at 12:52:22PM +0200, Lucas Nussbaum a écrit : On 06/04/09 at 19:48 +0900, Charles Plessy wrote: Le Mon, Apr 06, 2009 at 12:13:45PM +0200, Raphael Hertzog a écrit : On Mon, 06 Apr 2009, Charles Plessy wrote: I think that it is a good concept, but the linian warning has probably a good reason to exist. For instance, if a bug is closed as part of a Team upload, won't the BTS expect a NMU acknowledgement anyway? IIRC that concept died when we introduced version tracking so it should cause any problem. Bugs are always version closed (and no more tagged fixed/fixed-in-nmu). Good :) Does it mean that the Developers Reference must be updated? No, that's still correct. If you don't include the changelog entry fixing the bug, then the BTS' version tracking will be confused, and think that your version still has the bug. Aah thank you, that is clearer: I thought that it was meaning that it is still needed to re-iterate the Closes: command. So if we assume that in the case of “team uploads” the changes would be commited in the teams repository, as opposed to NMUs were the diff is sent to the BTS, it would definitely be useful to have the Debian tools to understand that it is correct that the person signing the changelog is not listed in the Uploaders: not the Maintainer: field. Would it be wrong to use the “ * QA upload” special first line, or is it better to reserve it to the QA team ? Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
Raphael Hertzog wrote: So I object to using NMU version for team uploads but I would like to have a mechanism for a team upload that doesn't lead to people adding themselves in Uploaders when they don't have a (real/long-term) commitment to the package. You can put the team name and mailing list in the changelog. That will avoid the lintian warning and you can look for team uploads by looking at uploads with the team name in the Changed-By field. A recent example: python-markdown (1.7-2) unstable; urgency=low [ Sandro Tosi ] * debian/control - switch Vcs-Browser field to viewsvn [ Emilio Pozuelo Monfort ] * debian/rules: Don't rely on python-support directory structure. Thanks Josselin Mouette. Closes: #517061. * Standards-Version is 3.8.0. No changes needed. -- Debian Python Modules Team python-modules-t...@lists.alioth.debian.org Wed, 25 Feb 2009 23:35:20 +0100 signature.asc Description: OpenPGP digital signature
Re: Team uploads
On Mon, 06 Apr 2009, Lionel Elie Mamane wrote: would really be a waste of time that would anihilate the efficiency of working in a team. The only burden I propose imposing is the NMU versioning, which does not feel to me like it is additional work. Instead of writing -3, write -2.1; only two keystrokes more. Too many tools assume that an NMU version is an NMU… for example the PTS would warn that a NMU has to be integrated/acknowledged. I don't see what the NMU versioning buys us. The fact that Uploaders is no more cluttered by entries for people that don't feel responsible seems like to compensate what the NMU versioning would bring us. You can also count the number of consecutive entries that use an email not listed in Uploaders to get a somewhat similar statistic than the one you're looking for. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
Le Monday 06 April 2009 12:27:22 Raphael Hertzog, vous avez écrit : You can put the team name and mailing list in the changelog. That will avoid the lintian warning and you can look for team uploads by looking at uploads with the team name in the Changed-By field. A recent example: I have seen that already but it's ugly as well. Changelog are written by humans and not lists and I like to have the name of someone (to blame) in the changelog entry. Hummm... For blaming, there should be the specific name of the responsible in the changelog. Also, it seems meaningful to me that the changelog is named after the team, it seems to be equivalent to the real world on behalf of the XXX team. A correct semantics could then be: $PACKAGE ($VERSION) unstable; urgency=low [ Romain Beauxis ] * Did a very bad thing -- Package Team package-t...@lists.alioth.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
On Mon, 06 Apr 2009, Romain Beauxis wrote: For blaming, there should be the specific name of the responsible in the changelog. Also, it seems meaningful to me that the changelog is named after the team, it seems to be equivalent to the real world on behalf of the XXX team. Except when you have multiple people listed you don't know who uploaded without resorting to who-uploads (or gpg check). Anyway, it's a matter of taste mainly. For me a changelog signature should refer to a human and not a mailing list. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
Raphael Hertzog hert...@debian.org (06/04/2009): Except when you have multiple people listed you don't know who uploaded without resorting to who-uploads (or gpg check). Not to mention cases where 5 people are listed there, and the package got sponsored by even someone else (any idea how many NMs there were in pkg-games?). For me a changelog signature should refer to a human and not a mailing list. Indeed, I like to know who took the “this package can be uploaded” decision, which is a bit more important than just committing a fix in $VCS and adding ones name to the changelog. A bit of final review has to be done, to ensure the whole is consistent; and I expect the trailer line to tell me who did that work. Mraw, KiBi. signature.asc Description: Digital signature
Re: Team uploads
Le Monday 06 April 2009 16:08:36 Cyril Brulebois, vous avez écrit : Indeed, I like to know who took the “this package can be uploaded” decision, which is a bit more important than just committing a fix in $VCS and adding ones name to the changelog. A bit of final review has to be done, to ensure the whole is consistent; and I expect the trailer line to tell me who did that work. Couldn't this also be a line in the changelog ? This is not a standard but this is done in many cases: [ Romain Beauxis ] * Upload to $TARGET Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
Romain Beauxis to...@rastageeks.org (06/04/2009): Couldn't this also be a line in the changelog ? Like the trailer line, yes. This is not a standard but this is done in many cases: [ Romain Beauxis ] * Upload to $TARGET Dunno about others, but I just see that as: this person chose to target this or that suite (e.g. unstable after a while in experimental, or experimental to keep things clear for testing/freeze), rather than a final decision. Mraw, KiBi. signature.asc Description: Digital signature
Re: Team uploads
On Mon, 06 Apr 2009 11:52:54 +0800, Paul Wise wrote:
In Debian we have several teams working on maintaining large numbers
of packages (pkg-games, pkg-perl, pkg-gnome for example).
True :)
I
proposed[1] to silence the lintian NMU warnings in the case of team
uploads; where the person doing the upload is a member of the team in
Maintainers but is not present in Uploaders. Does anyone think this
concept of team uploads has merit?
I agree that having to add yourself to Uploaders to avoid NMU
warnings (or listings under sponsored uploads on the DDPO page) is
a pain.
I'm just not sure about a viable solution; adding Team upload to
the changelog is clumsy too and only helps against the lintian
warnings but not against other mechanisms.
(And I agree with statements by others that NMU versions are wrong
and that group-address-in-changelog-trailer is at least weird.)
IMO the general problem is that our tools (both the locally installed
ones and the infrastructures ones) don't have a concept of teams
and team membership in itself. If we had a possibility to
declare/detect this package is team-maintained by $team, and $person
is member of $team, it would be easier ...
Cheers,
gregor
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`-NP: Joan Baez: For Sasha
signature.asc
Description: Digital signature
Re: Team uploads
Raphael Hertzog hert...@debian.org writes: The point of team upload is precisely so that you can update the package and not take responsibility for a package that you don't want to maintain in the long run. I was in many Uploaders field because lintian complain if you are not in Uploaders/Maintainer, yet I was there only for a single team upload for a perl or a python transition and using an NMU version would have been wrong because everything was properly done in the team VCS and there was no NMU to integrate for the next person working on the package. So I object to using NMU version for team uploads but I would like to have a mechanism for a team upload that doesn't lead to people adding themselves in Uploaders when they don't have a (real/long-term) commitment to the package. Then, the Maintainer/Uploader field would be again more accurate to know if we have people that care about the packages or not. So I see this change as good move to better detect that nobody cares about the package. Yeah, this is where I'm at with it too. There still should be some humans in Maintainer/Uploaders who are taking primary responsibility for the package, but I think other team members should be able to do QA-style fixes and transition uploads without using NMU versioning or add themselves to Uploaders and hence imply that they're taking ongoing responsibility for the package. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Team uploads
On Mon, Apr 06, 2009 at 11:51:54AM -0700, Russ Allbery wrote: Raphael Hertzog hert...@debian.org writes: The point of team upload is precisely so that you can update the package and not take responsibility for a package that you don't want to maintain in the long run. I was in many Uploaders field because lintian complain if you are not in Uploaders/Maintainer, yet I was there only for a single team upload for a perl or a python transition and using an NMU version would have been wrong because everything was properly done in the team VCS and there was no NMU to integrate for the next person working on the package. So I object to using NMU version for team uploads but I would like to have a mechanism for a team upload that doesn't lead to people adding themselves in Uploaders when they don't have a (real/long-term) commitment to the package. Then, the Maintainer/Uploader field would be again more accurate to know if we have people that care about the packages or not. So I see this change as good move to better detect that nobody cares about the package. Yeah, this is where I'm at with it too. There still should be some humans in Maintainer/Uploaders who are taking primary responsibility for the package, but I think other team members should be able to do QA-style fixes and transition uploads without using NMU versioning or add themselves to Uploaders and hence imply that they're taking ongoing responsibility for the package. +1, IANADD though. Hauke signature.asc Description: Digital signature
Re: Team uploads
Le Mon, Apr 06, 2009 at 11:51:54AM -0700, Russ Allbery a écrit : There still should be some humans in Maintainer/Uploaders who are taking primary responsibility for the package, but I think other team members should be able to do QA-style fixes and transition uploads without using NMU versioning or add themselves to Uploaders and hence imply that they're taking ongoing responsibility for the package. Hi all, so in the end, can we use the “ * QA upload.” special first line for non-uploader uploads without breaking the QA infrastructure? Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Team uploads
Hi all, In Debian we have several teams working on maintaining large numbers of packages (pkg-games, pkg-perl, pkg-gnome for example). I proposed[1] to silence the lintian NMU warnings in the case of team uploads; where the person doing the upload is a member of the team in Maintainers but is not present in Uploaders. Does anyone think this concept of team uploads has merit? 1. http://lists.debian.org/debian-lint-maint/2009/04/threads.html#00043 -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
