Re: Maintainers, teams, Uploaders, DMs, DDs, etc.

2012-06-16 Thread Darren Salt
I demand that Arno Töll may or may not have written... [snip] 2) ... Drive-by sponsoring does not work. It's annoying and back-breaking to the sponsored maintainer to have a package containing lots of fixes and maybe a new upstream version but nobody who uploads the you've been working on

Maintainers, teams, Uploaders, DMs, DDs, etc.

2012-06-13 Thread Ian Jackson
It's evident from recent conversations in various places that we are confused about: - what Maintainer and Uploaders mean - who is entitled to do what when - in some cases, the distinction between ability and permission etc. I'm going to try to set out my understanding of the current best

Re: Maintainers, teams, Uploaders, DMs, DDs, etc.

2012-06-13 Thread Bernhard R. Link
* Ian Jackson ijack...@chiark.greenend.org.uk [120613 17:35]: 5. Introduce a new conventional location for information useful to NMUers, debian/README.nmu Explicitly state that someone preparing or sponsoring an NMU should consult this file. Statements in this file may

Re: Maintainers, teams, Uploaders, DMs, DDs, etc.

2012-06-13 Thread Arno Töll
Hi, first: thank you. Recent threads show, we clearly need a discussion like this and hopefully people will take it as an opportunity to leave this thread a bit more enlightened. On 13.06.2012 17:35, Ian Jackson wrote: Instead, when a package team or lead maintainer accepts someone into

Re: Maintainers, teams, Uploaders, DMs, DDs, etc.

2012-06-13 Thread Gergely Nagy
Ian Jackson ijack...@chiark.greenend.org.uk writes: So for example, DDs have enormous theoretical power but there are strong and well documented social controls on how they should exercise that. I think as a matter of principle that the same principle should apply to DMs: it is easy to

Re: Maintainers, teams, Uploaders, DMs, DDs, etc.

2012-06-13 Thread Arno Töll
Hi, as a clarification, because I was pointed to it: On 13.06.2012 18:54, Arno Töll wrote: Drive-by sponsoring makes this even more complicated and is not helping anybody. We should stop advocating drive-by sponsoring at all. ... with the exception of evident cases like RC bug fixes,

Re: Maintainers, teams, Uploaders, DMs, DDs, etc.

2012-06-13 Thread Michael Gilbert
On Wed, Jun 13, 2012 at 1:35 PM, Arno Töll wrote: Hi, as a clarification, because I was pointed to it: On 13.06.2012 18:54, Arno Töll wrote: Drive-by sponsoring makes this even more complicated and is not helping anybody. We should stop advocating drive-by sponsoring at all. ... with the

Re: Maintainers, teams, Uploaders, DMs, DDs, etc.

2012-06-13 Thread Arno Töll
Hi, On 13.06.2012 19:46, Michael Gilbert wrote: I'm really not sure what your definition of drive-by is. Sometimes I'll make time to look at a package interesting me, I'll communicate with the sponsoree, upload it if they address my concerns, then follow it for a little while to make sure

Re: Maintainers, teams, Uploaders, DMs, DDs, etc.

2012-06-13 Thread Ansgar Burchardt
Hi, Ian Jackson ijack...@chiark.greenend.org.uk writes: I think the first three can be fixed relatively simply. I propose the following changes: 1. Change the definition of the Maintainer field to permit multiple entries. There are currently four different entities (3 humans and a

Re: Maintainers, teams, Uploaders, DMs, DDs, etc.

2012-06-13 Thread Charles Plessy
Le Wed, Jun 13, 2012 at 06:47:32PM +0200, Gergely Nagy a écrit : I think that would fit into debian/README.source nicely. Le Wed, Jun 13, 2012 at 06:54:35PM +0200, Arno Töll a écrit : README.source though, as people suggested in IRC. Le Wed, Jun 13, 2012 at 11:25:43PM +0200, Ansgar

Re: Maintainers, teams, Uploaders, DMs, DDs, etc.

2012-06-13 Thread Ben Finney
Arno Töll a...@debian.org writes: On 13.06.2012 17:35, Ian Jackson wrote: 1. Change the definition of the Maintainer field to permit multiple entries. There were probably technical reasons back then when introducing Uploaders. Maybe someone knows. I don't know of technical concerns