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 "w
On Sun, Mar 7, 2010 at 1:47 PM, Charles Plessy 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 y
Charles Plessy 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) <
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
Jan Hauke Rahm 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 unmistakl
On Mon, Mar 08, 2010 at 09:28:11AM -0800, Russ Allbery wrote:
> Jan Hauke Rahm 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 pa
Charles Plessy 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 th
Jan Hauke Rahm 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
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 wan
note 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).
>
> T
r 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
h 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 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.
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 d
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 n
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
Raphael Hertzog writes:
> On Mon, 06 Apr 2009, Russ Allbery wrote:
>> Charles Plessy 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
On Mon, 06 Apr 2009, Russ Allbery wrote:
> Charles Plessy 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 main
Charles Plessy 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 upl
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 si
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 ve
s 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
> >
> 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
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
>
Romain Beauxis (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 tha
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 e
Raphael Hertzog (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
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
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
gt;
> 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 t
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
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 th
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 do
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
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
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
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
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 huma
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 uploa
> 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 mer
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
> upload
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
>>>
; 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?
>
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 usefu
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";
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
Maintain
46 matches
Mail list logo
