Re: DEP1: how to do an NMU

[Lucas Nussbaum]

On 31/05/08 at 23:43 +0200, Frans Pop wrote:
> On Saturday 31 May 2008, Lucas Nussbaum wrote:
> > I also stressed that in the intro, and removed the second paragraph of
> > the intro, which didn't really add any value.
> 
> Agreed.
> 
> > +    * If the maintainer is usually active and responsive, have you
> > +      tried to contact him? In general it should be considered
> > preferable +      that a maintainer takes care of an issue himself and
> > that he is +      given the chance to review and correct your patch,
> > because he can +      be expected to be more aware of things that an
> > NMUer might miss.
> 
> "things" is a bit vague: s/things that an NMUer might miss/potential 
> issues which an NMUer might miss/

ACK

> > +This is not a license to perform NMUs thoughtlessly.  If you NMU when
> > +it is clear that the maintainers are active and would have
> > acknowledged +a patch in a more timely manner, or if you ignore the
> > recommendations of +this document, be warned, there is no protection
> > for you here.  You should +always be prepared to defend the wisdom of
> > any NMU you perform on its +own merits.
> 
> s/more timely/timely/
> 
> The "more" does not really refer back to anything.

ACK
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Misc development news (#8)

[Steve Langasek]

On Sun, Jun 01, 2008 at 12:50:24AM +0200, Peter Palfrader wrote:
> > - d-d-a is the list that all developers are supposed to be subscribed to,
> >   which means that's the list where announcements of general interest
> >   *should* go.

> It's not development related tho.

Description of that list is:

  Announcements for developers

  Announcements of development issues like policy changes, important release
  issues &c.

I.e., it's "for developers", which is not the same thing as "about
development".

> And most people really don't need to know it.

It's a policy change which should be communicated to the developer body.

> > This is information that does need to go
> > to /all/ developers, not just to the infrastructure-announce list

> Well, you can't please all of them.

Does this, in fact, please anyone other than you?  I've hardly seen a
clamour of voices demanding that infrastructure information not be posted to
d-d-a; AFAICS this was a unilateral change.

> Frankly, I think most of the posts to d-d-a have no place on that list in
> the first place.  If it's the list DD are required to subscribe to we
> should try to also send stuff there that they *read*.  I hardly read all
> of the posts sent there.

I don't see how that's an argument in favor of putting policy change
announcements that apply to all developers on a separate list that's of
/less/ general interest.

> What's the number of affected DDs here?  10?  20?

It's a policy change.  Policy changes affect all DDs, not just those who
currently have .ssh/authorized_keys files in place, and should be
communicated appropriately.

> >   The use of ~user/.ssh/authorized_keys files has been disabled since
> >   DSA1571 was announced.  While our initial plan was to allow them
> >   again eventually some bad experience with DDs' key handling has
> >   led us to reconsider that intent.

> > ... that means?  What bad key handling was seen that warrants such a policy
> > change?

> People submitting known bad keys to ldap and stuffing those in their
> authorized_keys files also.  What else did you think it meant?

I have no idea, because I don't understand why the above would warrant a
policy change wrt authorized_keys.  Surely, known bad keys could already be
dealt with using the blacklist support that was published as part of the
DSA, so why would we need to disable authorized_keys altogether when there's
support for handling this in the server itself?

Since you said "known bad keys", I assume that you are talking about the
blacklisted keys and not, say, DSS keys in general; for instance, as I noted
when we discussed my authorized_keys on gluck, the DSS key listed there has
been unused since before the OpenSSL vulnerability was introduced, so is
certainly not compromised by virtue of being a DSS key.  If you do actually
mean DSS keys, then, ok, it's an acknowledged bug in the openssh package
that one can't disable keys by type, so I can understand disabling arbitrary
authorized_keys as a workaround for this.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Misc development news (#8)

[Mohammed Adnène Trojette]

On Sun, Jun 01, 2008, Peter Palfrader wrote:
> It's not development related tho.  And most people really don't need to

It is developers related.

And http://lists.debian.org/devel.html reads:

debian-devel-announce: Announcements for developers

> know it.  I suppose etc/motd will eventually be updated to point to it
> also.

What's the use if you can't manage to login?

> Well, you can't please all of them.  Frankly, I think most of the posts
> to d-d-a have no place on that list in the first place.  If it's the
> list DD are required to subscribe to we should try to also send stuff
> there that they *read*.  I hardly read all of the posts sent there.

This is not a high traffic list. There is no spam on it. I personnally
do read at least the first lines.

> What's the number of affected DDs here?  10?  20?

Deleting or marking an email as read is easier than knowing that a
useful information has been sent on another mailing-list. And CC-ing dda
should do no serious harm, I guess.

> I think dia was the appropriate for that mail.  The pointer in buxy's
> mail was also fine, tho I wouldn't have placed it quite as prominently.

dia was appropriate, for sure. But I would have appreciated to be
informed on dda.

Anyway, please keep up the great work as DSA. That is what really
matters ;-)

-- 
Mohammed Adnène Trojette


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Misc development news (#8)

[Peter Palfrader]

[EMAIL PROTECTED] dropped]

On Sat, 31 May 2008, Steve Langasek wrote:

> I think this is a great example of why announcements like this should be
> sent to debian-devel-announce in the first place, instead of being relegated
> to the debian-infrastructure-announce list that most developers aren't
> subscribed to.

> - d-d-a is the list that all developers are supposed to be subscribed to,
>   which means that's the list where announcements of general interest
>   *should* go.

It's not development related tho.  And most people really don't need to
know it.  I suppose etc/motd will eventually be updated to point to it
also.

> This is information that does need to go
> to /all/ developers, not just to the infrastructure-announce list

Well, you can't please all of them.  Frankly, I think most of the posts
to d-d-a have no place on that list in the first place.  If it's the
list DD are required to subscribe to we should try to also send stuff
there that they *read*.  I hardly read all of the posts sent there.

What's the number of affected DDs here?  10?  20?

I think dia was the appropriate for that mail.  The pointer in buxy's
mail was also fine, tho I wouldn't have placed it quite as prominently.

>   The use of ~user/.ssh/authorized_keys files has been disabled since
>   DSA1571 was announced.  While our initial plan was to allow them
>   again eventually some bad experience with DDs' key handling has
>   led us to reconsider that intent.
> 
> ... that means?  What bad key handling was seen that warrants such a policy
> change?

People submitting known bad keys to ldap and stuffing those in their
authorized_keys files also.  What else did you think it meant?

-- 
weasel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DEP1: how to do an NMU

[Stefano Zacchiroli]

On Sat, May 31, 2008 at 07:18:14PM +0200, Frans Pop wrote:
> Because bugs may also have been (or seem to have been overlooked). The 
> risk here is that the person doing the NMU thinks "oh, that's an old 
> issue and the fix seems so simple" and goes ahead and NMUs it, while 
> there may be very valid reasons for not fixing it (or at least not with 
> _that_ fix).

Then they should have been mentioned in the bug log, shouldn't they?

... and IME they usually *are* for active teams, so I'm not sure I can
buy your argument. I rather conclude that active teams won't risk
anything with the procedure which is being proposed, while not active
teams will see NMUs, as they should.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Misc development news (#8)

[Steve Langasek]

> Mail-Followup-To: [EMAIL PROTECTED]

(Heh, eew)

On Fri, May 30, 2008 at 08:52:02PM +0200, Raphael Hertzog wrote:
> The news are collected on http://wiki.debian.org/DeveloperNews
> Feel free to contribute.

> ~/.ssh/authorized_keys will remain disabled by default
> --

>  Peter Palfrader announced on debian-infrastructure-announce[1] that DSA
>  will not reenable the usage of ~/.ssh/authorized_keys. One should use the
>  official LDAP infrastructure[2] to setup key-based SSH connection to
>  debian.org machines. There's an exception however, quoting Peter:

> > Should you need keys only on specific hosts for automated tasks like
> > updating stuff or syncing files between project machines or similar
> > we can enable a user editable authorized_keys file for specific users
> > on specific hosts.  Usually we would expect those keys to be limited
> > to use only from certain hosts (using from="") and limited to
> > allow execution of only certain commands (using command=" > Contact DSA if you have such a case.

I think this is a great example of why announcements like this should be
sent to debian-devel-announce in the first place, instead of being relegated
to the debian-infrastructure-announce list that most developers aren't
subscribed to.

- it's going to end up on d-d-a anyway because it's of sufficiently general
  concern that someone will forward it there
- d-d-a is the list that all developers are supposed to be subscribed to,
  which means that's the list where announcements of general interest
  *should* go.

Peter, please don't fragment our news feeds in this manner.  At least
provide this kind of information on *both* announcement lists, instead of
hiding it only on the infrastructure-announce list among other messages that
don't generally affect developers.  This is information that does need to go
to /all/ developers, not just to the infrastructure-announce list, because
it's not just a maintenance notification - it's a policy change that affects
how all developers interact with the project resources.

Also, could someone please elaborate on what:

  The use of ~user/.ssh/authorized_keys files has been disabled since
  DSA1571 was announced.  While our initial plan was to allow them
  again eventually some bad experience with DDs' key handling has
  led us to reconsider that intent.

... that means?  What bad key handling was seen that warrants such a policy
change?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DEP1: how to do an NMU

[Frans Pop]

On Saturday 31 May 2008, Lucas Nussbaum wrote:
> I also stressed that in the intro, and removed the second paragraph of
> the intro, which didn't really add any value.

Agreed.

> +    * If the maintainer is usually active and responsive, have you
> +      tried to contact him? In general it should be considered
> preferable +      that a maintainer takes care of an issue himself and
> that he is +      given the chance to review and correct your patch,
> because he can +      be expected to be more aware of things that an
> NMUer might miss.

"things" is a bit vague: s/things that an NMUer might miss/potential 
issues which an NMUer might miss/

> +This is not a license to perform NMUs thoughtlessly.  If you NMU when
> +it is clear that the maintainers are active and would have
> acknowledged +a patch in a more timely manner, or if you ignore the
> recommendations of +this document, be warned, there is no protection
> for you here.  You should +always be prepared to defend the wisdom of
> any NMU you perform on its +own merits.

s/more timely/timely/

The "more" does not really refer back to anything.

Thanks. For me this is a definite improvement.

Cheers,
FJP


signature.asc
Description: This is a digitally signed message part.

Re: DEP1: how to do an NMU

[Lucas Nussbaum]

On 31/05/08 at 21:02 +0200, Frans Pop wrote:
> On Saturday 31 May 2008, Luk Claes wrote:
> > Ok, though I'd rather have a (strong) recommendation to prod
> > maintainers (in a team or not), then to special case teams...
> 
> Sure. For me it is not necessarily about "teams", but more about "active": 
> likely to respond and take care of urgent issues him/her/themselves when 
> prodded, thus making an NMU unnecessary.
> 
> Basically I and several others have been asking to add something that 
> effectively (and more explicitly than in the current proposal) says:
> 
>Please consider before you NMU if just contacting the maintainer isn't
>likely to more effective than doing an NMU.
> 
>In general it should be considered preferable that a maintainer
>takes care of an issue himself and that he is given the chance to
>review and correct your patch, because he can be expected to be more
>aware of corner cases and complex interactions, things that an NMUer
>might miss.
> 
> Something like this could be added in the intro of 5.11. It is somewhat 
> similar in intend to the text proposed by Philip Hands.

I'm not sure that it is so similar to Philip's proposal.

I have integrated your proposal in the questions at the beginning of
5.11.1, and added Philip's at the end of 5.11.1. (both are modified a
bit, but I think that the general meaning is not changed)

> NMUs should remain a fallback if maintainers really fail to respond to 
> issues.
> Maintainers should also continue to be allowed to set priorities for their 
> packages. NMUs force maintainers to change their priorities as they will 
> *have* to deal with the NMU (either reject it or incorporate it) before 
> they can resume work on other issues.

I also stressed that in the intro, and removed the second paragraph of the
intro, which didn't really add any value.

Here is the diff. Feel free to propose further improvements (I still
have to discuss those changes with Bas, too):
--- 5.11.1.orig 2008-05-31 22:48:35.0 +0200
+++ 5.11.1  2008-05-31 22:50:25.0 +0200
@@ -1,19 +1,14 @@
 Proposed section 5.11: Non-Maintainer Uploads (NMUs)
 
 Every package has one or more maintainers. Normally, these are the
 people who work on and upload new versions of the package. In some
 situations, it is useful that other developers can upload a new
 version as well, for example if they want to fix a bug in a package
-they don't maintain. Such uploads are called Non-Maintainer Uploads
-(NMU).
-
-NMUs can happen for various reasons, the most usual one being to
-fix bugs. There are some rules to follow when doing an NMU. These
-are explained below. An NMU is allowed for any reason, as long as
-those rules are followed.
+they don't maintain, when the maintainer fails to respond to issues.
+Such uploads are called Non-Maintainer Uploads (NMU).
 
 5.11.1 When and how to do an NMU
 
 Before doing an NMU, consider the following questions:
 
 * Do you really fix bugs in your NMU? Fixing cosmetic issues, or
@@ -31,12 +26,17 @@
   seek advice from others. Remember that if you break something in
   your NMU, many people will be very unhappy about it.
 * Have you clearly expressed your intention to NMU, at least on the
   BTS? Has the maintainer been notified of it? It is also a good
   idea to try to contact the maintainer by other means (private
   email, IRC)
+* If the maintainer is usually active and responsive, have you
+  tried to contact him? In general it should be considered preferable
+  that a maintainer takes care of an issue himself and that he is
+  given the chance to review and correct your patch, because he can
+  be expected to be more aware of things that an NMUer might miss.
 
 When doing an NMU, you must first make sure that your intention to NMU
 is really clear.  Then, you must send a patch with the differences
 between the current package and your proposed NMU to the BTS.
 
 Unless you have an excellent reason not to do so, you must then give some
@@ -59,6 +59,13 @@
 especially if the patch wasn't available on the BTS before, or if you
 know that the maintainer is generally active.
 
 After you upload an NMU, you are responsible for the possible problems
 that you might have introduced. You must keep an eye on the package
 (subscribing to the package on the PTS is a good idea).
+
+This is not a license to perform NMUs thoughtlessly.  If you NMU when
+it is clear that the maintainers are active and would have acknowledged
+a patch in a more timely manner, or if you ignore the recommendations of
+this document, be warned, there is no protection for you here.  You should
+always be prepared to defend the wisdom of any NMU you perform on its
+own merits.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: DEP1: how to do an NMU

[Lucas Nussbaum]

On 31/05/08 at 21:33 +0200, Frans Pop wrote:
> On Saturday 31 May 2008, Lucas Nussbaum wrote:
> > So far, you (in <[EMAIL PROTECTED]> and
> > <[EMAIL PROTECTED]>) and Charles Plessy
> > (<[EMAIL PROTECTED]>,
> > <[EMAIL PROTECTED]>) raised that concern.
> 
> Sure, but Steve Langasek, Manoj and Frank Küster have been voicing what 
> are basically the same concerns.

One problem with such discussions is that it's easy to misread people's
mails, and attribute to them opinions that they don't have.  The only
mail from Frank Küster is
<[EMAIL PROTECTED]>, and he doesn't really
say anything about that topic. Same with Manoj and Steve: they raised
concerns, but not about excluding team-maintained or actively-maintained
packages.  (I might have missed a mail while rescanning the thread, of
course)

> > On the other hand, Bas Wijnen
> > (<[EMAIL PROTECTED]>) and I disagreed
> > that a special consideration was needed. We can't just blindly add
> > every suggestion that people propose, because that would make other
> > people unhappy.
> 
> Problem is you did not at the same time acknowledge that the concerns 
> themselves could be valid and that you were willing to discuss them 
> further and thus come to a different solution. This mail does do that.

Every concern is worth listening to, and we made several changes to the
DEP since the beginning of this discussion because of concerns that were
raised. But it's not black and white, especially with a topic where
different people might have had totally different experiences.

> [...]
> 
> > If you started to propose wordings that would suit you, instead of
> > waiting for us to propose stuff by mind-reading, that would be a lot
> > easier to listen to you.
> 
> The thing is that I basically agreed with suggestions (or at least with 
> the intentions behind them) from others which were  waved away. That is 
> not very motivating for writing other proposals.
> IMO you first have to reach agreement on the principle you want to put 
> into words when there is such a clear difference; proposing variations on 
> the same text is only going to lead to frustration. That is why I started 
> presenting use cases in which I feel NMUs to be less appropriate (and 
> explaining my reasons in more detail).

Discussing ideas and principles is a lot harder than discussing concrete
proposals. Also, when listing use cases, it's difficult for an outsider
to understand the underlying problem, and to generalize, which is
necessary before something can be put into dev-ref.

> From my perspective its your (plural) job as proposers/editors of the DEP 
> to put things together though.

Sure. I'm not asking for perfect patches. But the "I'd like to see
something like that in the DEP:" emails are a lot easier to answer than
those discussing ideas and principles, where it's difficult to determine
what the poster would exactly want to see changed.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: DEP1: how to do an NMU

[Lucas Nussbaum]

On 31/05/08 at 20:41 +0200, Frans Pop wrote:
> On Saturday 31 May 2008, Lucas Nussbaum wrote:
> > * Have you clearly expressed your intention to NMU, at least on the
> >   BTS? Has the maintainer been notified of it? It is also a good
> >   idea to try to contact the maintainer by other means (private
> >   email, IRC)
> 
> IMO private mail is the wrong way to do this if the intention to NMU has 
> already been registered in the BTS. Maintainers can be expected to read 
> BTS mails for their packages [1]. Sending a private mail is not something 
> I would ever do I think.

I agree with you, but several people mentioned that it would be nice to
try to contact the maintainer directly. This change was a "I don't really
care, let's make those people happy"-change.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: The "giving some time to the maintainer" rule

[Steve Langasek]

On Sat, May 31, 2008 at 08:55:37AM +0200, Lucas Nussbaum wrote:
> On 30/05/08 at 18:24 -0700, Steve Langasek wrote:
> > On Fri, May 30, 2008 at 11:49:14AM +0200, Lucas Nussbaum wrote:
> > > Now, what we don't agree on:
> > >  - I think that giving some time should only be very strongly
> > >recommended, but not mandatory.
> > >  - You think that giving some time should be mandatory.

> > > I think that our opinions are basically the same. The difference is that
> > > you want to write something in stone, while I prefer not to impose rules
> > > where it's not necessary, because:

> > This is begging the question.  Experience tells me that the sort of rules
> > under discussion *are* necessary.

> You are still talking about the rule "The maintainer *MUST* give some
> time to react before uploading the NMU", right?

And rules about when this should not be required.

> > And, so?  That's what we have today.  What's the problem with this that
> > you're trying to fix?

> No, that's not what we have today. What we have today is the release
> team deciding that it has authority to change the NMU rules, to allow
> 0-day NMUs for bugs older than 7 days old.
> - Does the RT really have authority ?
> - 0-day means "no need to give some time to the maintainer".

So you want to replace it with "people who can edit the developers-reference
deciding that they have the authority to change the NMU rules"?

The developer's reference is non-normative.  It lacks either a
constitutional charter for the change process, or constitutionally-delegated
stewards.  And it contains lots of recommendations that are one person's
idea about how things should work.

The current devref NMU policy is IMHO one of the better recommendations in
that document.  But I also believe it carries weight more because it
encodes the community tradition than because the devref itself has power to
determine such policies.

As for the release team setting policies, Anthony Towns pointed out a couple
of years ago, in a message I can't now put my finger on, that ultimately
it's the ftp masters who decide who's able to upload packages to the archive
or not, NMUs or otherwise.  Given that this was in a discussion about 0-day
NMUs, I think that also amounts to tacit approval by the ftpmasters of the
RM-endorsed NMU policies.

> You uploaded a lot of such NMUs yourself, sometimes on packages with an
> active maintainer, without even providing a patch on the BTS previously.

Er, barring mailer errors, in all cases my NMUs included a patch and
declaration of intent-to-NMU sent to the BTS before my NMUs were uploaded.
In the case of NMUs fixing only RC bugs, sometimes the time between the two
events was < 5 minutes, but in all cases it was intended to be consistent
with the NMU policies (including 0-day NMU policies) in force at the time.

> You realize that this discussion about the "NMUers must give some time
> to the maintainer"-rule also affects the current 0-day NMU policy?

... only if you accept the premise that all NMUs should be covered by a
single rule without exception, which I do not?

> One of the goals of the DEP is to make the 0-day NMU policy useless, by
> generalizing it to all bugs (with "delay" > 0 and "delay" a function of
> the severity of bugs being fixed).

Right; I think this is a false generalization because of the negative
side-effects.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DEP1: how to do an NMU

[Frans Pop]

On Saturday 31 May 2008, Lucas Nussbaum wrote:
> So far, you (in <[EMAIL PROTECTED]> and
> <[EMAIL PROTECTED]>) and Charles Plessy
> (<[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]>) raised that concern.

Sure, but Steve Langasek, Manoj and Frank Küster have been voicing what 
are basically the same concerns.

> On the other hand, Bas Wijnen
> (<[EMAIL PROTECTED]>) and I disagreed
> that a special consideration was needed. We can't just blindly add
> every suggestion that people propose, because that would make other
> people unhappy.

Problem is you did not at the same time acknowledge that the concerns 
themselves could be valid and that you were willing to discuss them 
further and thus come to a different solution. This mail does do that.

> I am opposed to forbidding NMUs, or requiring prior ack from
> the maintainer, for some categories of maintainers. If we start listing
> such categories, we will end up with something like:
>  - teams with at least one very active/responsive member, or two
>active/resposnive members
>  - very active/responsive DDs, unless they are in VAC for more than n
> days That will be totally a PITA to check, and very error-prone. (how
> do you measure activity and responsiveness?)

Fine. I'm only providing examples of cases where I feel NMUs are in 
general not appropriate. A more general rule would be fine with me, as 
long as it does cover the particular case in some way.

> Instead, I'm totally open to emphasizing the fact that if the package
> is maintained by a team or by a known-active DD, the NMUer should
> really try harder to contact the maintainers before proceeding with the
> NMU.

Cool.

> Phil Hands proposed something in <[EMAIL PROTECTED]>:
> > Clearly there are cases where NMUs are inappropriate.  The DEP is
> > currently missing language to make that point clear (at least in my
> > reading of it) perhaps it needs a final clause along the lines of:
> >
> >   This is not a license to perform NMUs thoughtlessly.  If you NMU
> > when it is clear that the maintainers are active and would have
> > acknowledged a patch in a more timely manner, or if you ignore the
> > recommendations of this DEP, or if you do something else that assumes
> > that this is an NMUers charter and that a lawyerly interpretation of
> > some subclause can be used to justify some abusive action, be warned,
> > there is no protection for you here.  You should always be prepared
> > to defend the wisdom of any NMU you perform on its own merits.
>
> Frans, would adding that paragraph solve your concerns, or can you
> suggest a patch to this paragraph that would solve them?

I think that mentioning in some way that you should be prepared to defend 
a decision to NMU would be very good. The "lawyerly interpretation of 
some subclause" phrase is probably a bit too much :-)

See my second reply to Luk for a more concrete proposal, but I'd be happy 
to see the "be prepared to defend" bit added to that in some way.

> If you started to propose wordings that would suit you, instead of
> waiting for us to propose stuff by mind-reading, that would be a lot
> easier to listen to you.

The thing is that I basically agreed with suggestions (or at least with 
the intentions behind them) from others which were  waved away. That is 
not very motivating for writing other proposals.
IMO you first have to reach agreement on the principle you want to put 
into words when there is such a clear difference; proposing variations on 
the same text is only going to lead to frustration. That is why I started 
presenting use cases in which I feel NMUs to be less appropriate (and 
explaining my reasons in more detail).

Anyway, my reply to Luk contains a fairly concrete proposed text.

From my perspective its your (plural) job as proposers/editors of the DEP 
to put things together though.

Cheers,
FJP


signature.asc
Description: This is a digitally signed message part.

Re: DEP1: how to do an NMU

[Frans Pop]

On Saturday 31 May 2008, Luk Claes wrote:
> Ok, though I'd rather have a (strong) recommendation to prod
> maintainers (in a team or not), then to special case teams...

Sure. For me it is not necessarily about "teams", but more about "active": 
likely to respond and take care of urgent issues him/her/themselves when 
prodded, thus making an NMU unnecessary.

Basically I and several others have been asking to add something that 
effectively (and more explicitly than in the current proposal) says:

   Please consider before you NMU if just contacting the maintainer isn't
   likely to more effective than doing an NMU.

   In general it should be considered preferable that a maintainer
   takes care of an issue himself and that he is given the chance to
   review and correct your patch, because he can be expected to be more
   aware of corner cases and complex interactions, things that an NMUer
   might miss.

Something like this could be added in the intro of 5.11. It is somewhat 
similar in intend to the text proposed by Philip Hands.

Teams is for me just a case where you can reasonably expect NMUers to 
seriously consider that option, a bit more so than with solo maintainers 
(generally speaking).

IMO people who do NMUs are mostly also people who _are_ aware of who 
(individual and teams) is active/responsive and who is not, so I would be 
very surprised if this is not the actual practice with people who already 
are active doing more than just an occasional NMU.

NMUs should remain a fallback if maintainers really fail to respond to 
issues.
Maintainers should also continue to be allowed to set priorities for their 
packages. NMUs force maintainers to change their priorities as they will 
*have* to deal with the NMU (either reject it or incorporate it) before 
they can resume work on other issues.

I am not against NMUs, and also not against the DEP, but I would like to 
have made clear that there are cases where NMUs are just not the 
appropriate way to fix a pet issue, especially not for anything below RC.

Categories for which I _do_ believe NMUs are appropriate:
- really urgent, or important and obviously safe issues (see example acked
  by Frank Küster in <[EMAIL PROTECTED]>)
- changes needed for larger transitions or release goals where maintainers
  are failing to respond to repeated signals to do something
- RC issues that affect users (excluding e.g. licence issues); I have no
  problems with the current practice for those
- and possibly a few more

The DEP should not be a licence to avoid entering into a discussion with 
the maintainer of a package, or to pre-empt him.

Cheers,
FJP


signature.asc
Description: This is a digitally signed message part.

Re: DEP1: how to do an NMU

[Frans Pop]

On Saturday 31 May 2008, Lucas Nussbaum wrote:
> * Have you clearly expressed your intention to NMU, at least on the
>   BTS? Has the maintainer been notified of it? It is also a good
>   idea to try to contact the maintainer by other means (private
>   email, IRC)

IMO private mail is the wrong way to do this if the intention to NMU has 
already been registered in the BTS. Maintainers can be expected to read 
BTS mails for their packages [1]. Sending a private mail is not something 
I would ever do I think.

A final attempt to ping on IRC can be appropriate in some cases.

Cheers,
FJP

[1] With one exception: mails with large attachments may be accepted by 
the BTS, but not reach the maintainer. For example, lists.d.o has a size 
limit, while bugs.d.o does not (#475682).


signature.asc
Description: This is a digitally signed message part.

Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)

[Manoj Srivastava]

On Sat, 31 May 2008 09:13:43 +0200, Lucas Nussbaum
<[EMAIL PROTECTED]> said:  

> On 30/05/08 at 17:28 -0500, Manoj Srivastava wrote:

>> For the record, I don't think that we should remove the language
>> about informing the maintainer with a mail message; and no, I don't
>> think we quite have a consensus on this yet.

> The DEP currently addresses communication like that:

>   When doing an NMU, you must always send a patch with the differences
>   between the current package and your NMU to the BTS.  If the bug you
>   are fixing isn't reported yet, you must do that as well.

> I have several questions about the requirement for communication that
> you want to add:
> - Do you want to require two-way communication?

There should be some time for a response to come in, but I don't
 think I want the NMU to have to wait on the maintainer. But apart from
 the patch, there should be a clear indication of an intent to NMU.

> - If the maintainer doesn't answer, how much time should the NMUer
>   wait for the maintainer, in your opinion?

 I think the maintainer should be given a "reasonable" time to respond,
 for some value of "reasonable". All this also depends on whether the
 maintainer is active or MIA, and how sever the bug is, and how complex
 the fix would be.

You are aiming for not lower the enthusiasm of the NMU'er by
 adding delays, but I think we should also be looking at quality of
 NMU's, and consulting and cooperating with the maintainer, who probably
 has more experience with the package, rather than just getting the NMU
 in.

Perhaps my experience is soured by a recent pointless
 *sponsored* NMU to one of my packages (admittedly for a RC bug), with
 no mail, no patch to the BTS, and one which failed to fix the problem
 (so there was no testing done, faugh).


> - Are the delays that are strongly recommended in the DEP really too
>   short, in your opinion?

I think so. When I have NMU'd a package, it has been with a lot
 of thought, consulting with the maintainer, offering to help, and then
 it still took a week or so to familiarize myself with the package to do
 a goods job of testing. And then I was fully subscribed to the package,
 and felt responsible for any bug opened until the next upload.

I think that is the right option; hurrying changes into the
 archive for "enthusiasm" does not feel right.

The activity level of the maintainer, th degree of familiarity
 with the package by the NMUer. the  complexity of the bug/solution,
 should also be factored in.  Even if we can not give a numerical value
 to the effect these have, we can add language that says that the NMUer
 should take those factors in consideration before deciding to pitch
 right in or not.

> The current wording requires a notification (by sending a mail to the
> BTS). I don't think that it's a good idea to additionally require that
> this mail should be sent to the maintainer's private email address,
> because that doesn't work well with co-maintainance.

A mail with an intent-NMU made clear would work, I think. Not
 just a patch; 

> The current wording doesn't require the NMUer to wait for an
> acknowledgement. Instead, it strongly recommends to give some time to
> the maintainer, which doesn't make a big difference ...

I think I would state it that the maintainer must be given time
 to respond, but there can be extenuating circumstances (security fixes,
 etc), and the severity of the bug and the simplicity of the fix can
 have the window slide shorter or wider.

The bottom line, of course, is the quality of the distribution;
 and the trade off between getting fixes in, versus getting the fixes in
 vetted by someone experienced with the package -- and weighing in
 whether the NMUer has experience with the are or not. (joeyh can NMU my
 packages any time, with or without any notice; the people who NMU'd my
 package recently should refrain from touching my packages  until they
 get a response from me).

manoj
 Not everything is Black or White
-- 
A child miseducated is a child lost.  -- John F. Kennedy
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DEP1: how to do an NMU

[Manoj Srivastava]

On Sat, 31 May 2008 12:20:55 +0200, Lucas Nussbaum
<[EMAIL PROTECTED]> said:  

> Steve, Manoj, Charles, Richard, does this address your concerns?  If
> not, can you propose some additional changes?

This new version does sound a lot better.

manoj
-- 
If voting could really change things, it would be illegal. Revolution
Books.  New York, New York.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DEP1: how to do an NMU

[Luk Claes]

Frans Pop wrote:
> On Saturday 31 May 2008, Luk Claes wrote:
>>> "All members of a team becoming unresponsive" is possible, agreed.
>>> But it is a hell of a lot less likely than "at least one member of
>>> the team being able to respond to urgently needed changes if
>>> appropriately notified".
>> So, why should there be any special treatment as they are more likely
>> to respond early anyway? Or are you questioning normal NMU intents,
>> RC/RG bugs and d-d-a announcements as appropriate notifications?
> 
> Because bugs may also have been (or seem to have been overlooked). The 
> risk here is that the person doing the NMU thinks "oh, that's an old 
> issue and the fix seems so simple" and goes ahead and NMUs it, while 
> there may be very valid reasons for not fixing it (or at least not with 
> _that_ fix).
> 
> A follow-up to the bug report with just "hey, this issue seems to be 
> forgotten, could someone please take another look as it seems important" 
> would then be a lot more appropriate and take a lot less time all around 
> then preparing the patch, uploading it to delayed and then getting to 
> hear "sorry, this is not good, please remove your NMU from the queue".
> 
> Large teams also often have large numbers of issues to deal with. Which 
> does mean that (unfortunately) issues may be missed or forgotten about.
> Or maybe it is something that is normally taken care of by one particular 
> team member and other team members ignored the issue for that reason but 
> are capable of picking it up if prompted to do so.
> 
> There is just no reason to bypass the maintainers if they are otherwise 
> active. In such cases just talking to the maintainers (through the BTS or 
> otherwise) is just a lot more appropriate and effective, at least as a 
> first step, than going straight to an NMU - even with the safeguards 
> incorporated in the DEP.

Ok, though I'd rather have a (strong) recommendation to prod maintainers
(in a team or not), then to special case teams...

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DEP1: how to do an NMU

[Lucas Nussbaum]

On 31/05/08 at 18:44 +0200, Frans Pop wrote:
> On Saturday 31 May 2008, Lucas Nussbaum wrote:
> > > I propose to add "NMUs are usually not appropriate for
> > > team-maintained packages. Consider sending a patch to the BTS
> > > instead." to the bullet list.
> >
> > It really depends on the team. There are small teams where all members
> > might become unresponsive at the same time. I don't think that we
> > should special-case this.
> 
> Yes, it probably does depend on the team. But several people have raised 
> this point now, which probably means that it _is_ a real concern.

So far, you (in <[EMAIL PROTECTED]> and
<[EMAIL PROTECTED]>) and Charles Plessy
(<[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]>) raised that concern. On the
other hand, Bas Wijnen
(<[EMAIL PROTECTED]>) and I disagreed
that a special consideration was needed. We can't just blindly add
every suggestion that people propose, because that would make other
people unhappy.

I am opposed to forbidding NMUs, or requiring prior ack from
the maintainer, for some categories of maintainers. If we start listing
such categories, we will end up with something like:
 - teams with at least one very active/responsive member, or two
   active/resposnive members
 - very active/responsive DDs, unless they are in VAC for more than n days
That will be totally a PITA to check, and very error-prone. (how do you
measure activity and responsiveness?)

Instead, I'm totally open to emphasizing the fact that if the package is
maintained by a team or by a known-active DD, the NMUer should really try
harder to contact the maintainers before proceeding with the NMU.

Phil Hands proposed something in <[EMAIL PROTECTED]>:
> Clearly there are cases where NMUs are inappropriate.  The DEP is currently
> missing language to make that point clear (at least in my reading of it)
> perhaps it needs a final clause along the lines of:
> 
>   This is not a license to perform NMUs thoughtlessly.  If you NMU when
>   it is clear that the maintainers are active and would have acknowledged
>   a patch in a more timely manner, or if you ignore the recommendations
>   of this DEP, or if you do something else that assumes that this is an
>   NMUers charter and that a lawyerly interpretation of some subclause
>   can be used to justify some abusive action, be warned, there is no
>   protection for you here.  You should always be prepared to defend the
>   wisdom of any NMU you perform on its own merits.

Frans, would adding that paragraph solve your concerns, or can you
suggest a patch to this paragraph that would solve them?

> are you (the proposers of this DEP) going to start listening to your 
> peers instead of dismissing their concerns?

If you started to propose wordings that would suit you, instead of
waiting for us to propose stuff by mind-reading, that would be a lot
easier to listen to you.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: DEP1: how to do an NMU

[Frans Pop]

On Saturday 31 May 2008, Luk Claes wrote:
> > "All members of a team becoming unresponsive" is possible, agreed.
> > But it is a hell of a lot less likely than "at least one member of
> > the team being able to respond to urgently needed changes if
> > appropriately notified".
>
> So, why should there be any special treatment as they are more likely
> to respond early anyway? Or are you questioning normal NMU intents,
> RC/RG bugs and d-d-a announcements as appropriate notifications?

Because bugs may also have been (or seem to have been overlooked). The 
risk here is that the person doing the NMU thinks "oh, that's an old 
issue and the fix seems so simple" and goes ahead and NMUs it, while 
there may be very valid reasons for not fixing it (or at least not with 
_that_ fix).

A follow-up to the bug report with just "hey, this issue seems to be 
forgotten, could someone please take another look as it seems important" 
would then be a lot more appropriate and take a lot less time all around 
then preparing the patch, uploading it to delayed and then getting to 
hear "sorry, this is not good, please remove your NMU from the queue".

Large teams also often have large numbers of issues to deal with. Which 
does mean that (unfortunately) issues may be missed or forgotten about.
Or maybe it is something that is normally taken care of by one particular 
team member and other team members ignored the issue for that reason but 
are capable of picking it up if prompted to do so.

There is just no reason to bypass the maintainers if they are otherwise 
active. In such cases just talking to the maintainers (through the BTS or 
otherwise) is just a lot more appropriate and effective, at least as a 
first step, than going straight to an NMU - even with the safeguards 
incorporated in the DEP.


signature.asc
Description: This is a digitally signed message part.

Re: DEP1: how to do an NMU

[Luk Claes]

Frans Pop wrote:
> On Saturday 31 May 2008, Lucas Nussbaum wrote:
>>> I propose to add "NMUs are usually not appropriate for
>>> team-maintained packages. Consider sending a patch to the BTS
>>> instead." to the bullet list.
>> It really depends on the team. There are small teams where all members
>> might become unresponsive at the same time. I don't think that we
>> should special-case this.
> 
> Yes, it probably does depend on the team. But several people have raised 
> this point now, which probably means that it _is_ a real concern. When 
> are you (the proposers of this DEP) going to start listening to your 
> peers instead of dismissing their concerns?
> 
> A lot of packages are team-maintained not only because it is more fun to 
> work together, but also because those packages (or groups of packages) 
> are more complex, or have interactions that may not be obvious at first 
> glance. Which means that there may well be a bigger likelyhood that an 
> NMU will break things.
> 
> "All members of a team becoming unresponsive" is possible, agreed.
> But it is a hell of a lot less likely than "at least one member of the 
> team being able to respond to urgently needed changes if appropriately 
> notified".

So, why should there be any special treatment as they are more likely to
respond early anyway? Or are you questioning normal NMU intents, RC/RG
bugs and d-d-a announcements as appropriate notifications?

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DEP1: how to do an NMU

[Frans Pop]

On Saturday 31 May 2008, Lucas Nussbaum wrote:
> > I propose to add "NMUs are usually not appropriate for
> > team-maintained packages. Consider sending a patch to the BTS
> > instead." to the bullet list.
>
> It really depends on the team. There are small teams where all members
> might become unresponsive at the same time. I don't think that we
> should special-case this.

Yes, it probably does depend on the team. But several people have raised 
this point now, which probably means that it _is_ a real concern. When 
are you (the proposers of this DEP) going to start listening to your 
peers instead of dismissing their concerns?

A lot of packages are team-maintained not only because it is more fun to 
work together, but also because those packages (or groups of packages) 
are more complex, or have interactions that may not be obvious at first 
glance. Which means that there may well be a bigger likelyhood that an 
NMU will break things.

"All members of a team becoming unresponsive" is possible, agreed.
But it is a hell of a lot less likely than "at least one member of the 
team being able to respond to urgently needed changes if appropriately 
notified".

Cheers,
FJP


signature.asc
Description: This is a digitally signed message part.

Re: DEP1: how to do an NMU

[Lucas Nussbaum]

On 01/06/08 at 00:22 +0900, Charles Plessy wrote:
> Le Sat, May 31, 2008 at 12:20:55PM +0200, Lucas Nussbaum a écrit :
> > 
> > Unless you have an excellent reason not to do so, you must then give some
> > time to the maintainer to react
> 
> Hi Lucas,
> 
> excellence is definitely what we should aim for :)
> 
> Thank you for your efforts. Here are my last comments on the DEP:
> 
> 
> 5.11.1 When and how to do an NMU
> 
> I propose to add "NMUs are usually not appropriate for team-maintained
> packages. Consider sending a patch to the BTS instead." to the bullet
> list.

It really depends on the team. There are small teams where all members
might become unresponsive at the same time. I don't think that we should
special-case this.

> 5.11.1.2 Using the DELAYED/ queue
> 
> I propose to ask a paragraph saying:
> 
> "If you do not make your NMU to DELAYED/, you must document your reasons
> in the BTS."
> 
> I and others had NMUs on non-RC bugs on team-maintained packages while
> being active and we are still left to wonder what in our packaging
> practice was so wrong that it had to be fixed in emergency. Having the
> reason written in the BTS would help us to improve ourselves.

Can you give a specific example where this happened? Did you raise the
subject on [EMAIL PROTECTED] Have you asked the NMUer why he did that?

I think that the DEP should reduce this risk. Actually, with the 0-day
NMU policy on RC and RG > 7 days old, it's currently perfectly allowed
to NMU a team-maintained package for an RG bug without prior contact
with the maintainer. I don't think that it's a good policy in many cases
(like the one you describe), and it's one of my motivations for this
DEP.

Even if this DEP is accepted, it doesn't mean that we can't come back to
this discussion in a few months, and reconsider some things. I would
prefer to keep the current wording for now, and re-discuss this later,
if this proves to be an issue with the current wording.

> 5.11.2 NMUs, from the maintainer's point of view
> 
> The last two sentences, "Make sure to include the NMU's changelog entry (not
> just the line describing the changes) in your own changelog. This is
> important to allow the ¥BTS version tracking to work.", are misleading
> on how the BTS work, as they suggest that the version tracking depends
> on the changelog. Maybe they could be changed to:

Well, that's the case, see
http://lists.debian.org/debian-project/2008/05/msg00074.html

> "Make sure to include the NMU's changelog entry (not
> just the line describing the changes) in your own changelog if you want
> to take advantage of the automatic BTS version tracking."

I'll change that to:
  Make sure to include the NMU's changelog entry (not just the line
  describing the changes) in your own changelog, to allow the automatic
  BTS version tracking to work.

> I think that both sides made enough efforts, so please do not take this
> mail as a list of requirements, alhtough of course I would prefer my
> points being taken into account.
> 
> I am moving into a place where internet is not yet set up, so do not
> expect timely answers. Please go ahead :)

Have fun :)
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DEP1: how to do an NMU

[Charles Plessy]

Le Sat, May 31, 2008 at 12:20:55PM +0200, Lucas Nussbaum a écrit :
> 
> Unless you have an excellent reason not to do so, you must then give some
> time to the maintainer to react

Hi Lucas,

excellence is definitely what we should aim for :)

Thank you for your efforts. Here are my last comments on the DEP:


5.11.1 When and how to do an NMU

I propose to add "NMUs are usually not appropriate for team-maintained
packages. Consider sending a patch to the BTS instead." to the bullet
list.


5.11.1.2 Using the DELAYED/ queue

I propose to ask a paragraph saying:

"If you do not make your NMU to DELAYED/, you must document your reasons
in the BTS."

I and others had NMUs on non-RC bugs on team-maintained packages while
being active and we are still left to wonder what in our packaging
practice was so wrong that it had to be fixed in emergency. Having the
reason written in the BTS would help us to improve ourselves.


5.11.2 NMUs, from the maintainer's point of view

The last two sentences, "Make sure to include the NMU's changelog entry (not
just the line describing the changes) in your own changelog. This is
important to allow the ¥BTS version tracking to work.", are misleading
on how the BTS work, as they suggest that the version tracking depends
on the changelog. Maybe they could be changed to:

"Make sure to include the NMU's changelog entry (not
just the line describing the changes) in your own changelog if you want
to take advantage of the automatic BTS version tracking."



I think that both sides made enough efforts, so please do not take this
mail as a list of requirements, alhtough of course I would prefer my
points being taken into account.

I am moving into a place where internet is not yet set up, so do not
expect timely answers. Please go ahead :)

Have a nice week-end,

-- 
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan
(for the last day !)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: The "giving some time to the maintainer" rule

[Luk Claes]

Lucas Nussbaum wrote:
> On 30/05/08 at 18:24 -0700, Steve Langasek wrote:
>> On Fri, May 30, 2008 at 11:49:14AM +0200, Lucas Nussbaum wrote:
>>> Now, what we don't agree on:
>>>  - I think that giving some time should only be very strongly
>>>recommended, but not mandatory.
>>>  - You think that giving some time should be mandatory.
>>> I think that our opinions are basically the same. The difference is that
>>> you want to write something in stone, while I prefer not to impose rules
>>> where it's not necessary, because:
>> This is begging the question.  Experience tells me that the sort of rules
>> under discussion *are* necessary.
> 
> You are still talking about the rule "The maintainer *MUST* give some
> time to react before uploading the NMU", right?
> 
>>> - If you make it mandatory, then you have to provide a workaround for
>>>   cases where it's just not possible to wait. And you also have to list
>>>   those cases.
>> And, so?  That's what we have today.  What's the problem with this that
>> you're trying to fix?
> 
> No, that's not what we have today. What we have today is the release
> team deciding that it has authority to change the NMU rules, to allow
> 0-day NMUs for bugs older than 7 days old.
> - Does the RT really have authority ?

According to the Developer's Reference at least the release manager has...

> - 0-day means "no need to give some time to the maintainer".

Wrong: 0-day means "no need to give the maintainer *extra* time"

> You uploaded a lot of such NMUs yourself, sometimes on packages with an
> active maintainer, without even providing a patch on the BTS previously.

Only where the maintainer didn't react yet in the time (mostly about 7
days) given...

> You realize that this discussion about the "NMUers must give some time
> to the maintainer"-rule also affects the current 0-day NMU policy?

It does already...

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)

[Lucas Nussbaum]

On 31/05/08 at 04:25 -0700, Richard Hecker wrote:
> Lucas Nussbaum wrote:
>> Please, everybody, let's try to discuss patches to the DEP, rather than
>> general stuff about communication. (unless you want to reject the whole
>> DEP, but only Richard Hecker seems to want that)
>>
>>   
> In spite of my intention to not comment any further, I just cannot
> let this claim go unchallenged. You should reread everything I
> have posted (including my October 2008 emails) before you attempt
> to put words in my mouth. Again I point out that reality can be
> different from what you claim. I do not think consensus exists
> despite all your claims that it does.

I am sorry if I misinterpreted your mails, but your lack of willingness to
propose improvements to the proposal, and you constant rejections, led me
to thinking that you wanted to reject it as a whole. I am happy to be
wrong about that.

Now, if we could stop the personal attacks and work on improving the
proposal to reach consensus, that would be a lot more useful.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)

[Richard Hecker]

Lucas Nussbaum wrote:

Please, everybody, let's try to discuss patches to the DEP, rather than
general stuff about communication. (unless you want to reject the whole
DEP, but only Richard Hecker seems to want that)

  

In spite of my intention to not comment any further, I just cannot
let this claim go unchallenged. You should reread everything I
have posted (including my October 2008 emails) before you attempt
to put words in my mouth. Again I point out that reality can be
different from what you claim. I do not think consensus exists
despite all your claims that it does.


Richard


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DEP1: Clarifying policies and workflows for Non Maintainer?Uploads (NMUs)

[Philip Hands]

On Fri, May 30, 2008 at 05:17:57PM +0200, Frans Pop wrote:
> On Friday 30 May 2008, Bas Wijnen wrote:
> > But in the situation you mention above, I don't think there's anything
> > wrong with actually preparing an NMU (except that you may be wasting
> > time, but that's your own problem).  So no reasons are needed for it.
> 
> I find your argumentation rather weak, but to be honest I also don't really 
> care enough about this whole subject to discuss it further.
> 
> If anybody is ever going to NMU D-I components to DELAYED, I expect he will 
> get a direct reply with a request to remove his upload from the queue, but 
> we'll deal with that when it happens. The point of my mail was: D-I has a 
> sufficiently actively team, there should be no need ever to NMU any of its 
> packages. Doing so is indeed a waste of time.

Clearly there are cases where NMUs are inappropriate.  The DEP is currently
missing language to make that point clear (at least in my reading of it)
perhaps it needs a final clause along the lines of:

  This is not a license to perform NMUs thoughtlessly.  If you NMU when
  it is clear that the maintainers are active and would have acknowledged
  a patch in a more timely manner, or if you ignore the recommendations
  of this DEP, or if you do something else that assumes that this is an
  NMUers charter and that a lawyerly interpretation of some subclause
  can be used to justify some abusive action, be warned, there is no
  protection for you here.  You should always be prepared to defend the
  wisdom of any NMU you perform on its own merits.

Cheers, Phil.


signature.asc
Description: Digital signature

DEP1: how to do an NMU

[Lucas Nussbaum]

Hi,

In an effort to move the discussion forward, here is a new version of
the proposed section 5.11.1. (Bas Wijnen didn't have a chance to have a
look at this yet)

It tries to address the comments about communication with the maintainer
prior to the NMU, and about giving some time to the maintainer to react.

Steve, Manoj, Charles, Richard, does this address your concerns?
If not, can you propose some additional changes?
-
5.11.1 When and how to do an NMU

Before doing an NMU, consider the following questions:

* Do you really fix bugs in your NMU? Fixing cosmetic issues, or
  changing the packaging style in NMUs is discouraged, unless it
  is required to fix bugs.
* Did you give enough time to the maintainer? When was the bug
  reported to the BTS? Being busy for a week or two isn't unusual.
  Is the bug so severe that it needs to be fixed right now, or
  can it wait a few more days?
* How confident are you about your changes? Please remember the
  Hippocratic Oath: "Above all, do no harm." It is better to leave
  a package with an open grave bug than applying a non-functional
  patch, or one that hides the bug instead of resolving it. If you
  are not 100% sure of what you did, it might be a good idea to
  seek advice from others. Remember that if you break something in
  your NMU, many people will be very unhappy about it. 
* Have you clearly expressed your intention to NMU, at least on the
  BTS? Has the maintainer been notified of it? It is also a good
  idea to try to contact the maintainer by other means (private
  email, IRC)

When doing an NMU, you must first make sure that your intention to NMU
is really clear.  Then, you must send a patch with the differences
between the current package and your proposed NMU to the BTS. 

Unless you have an excellent reason not to do so, you must then give some
time to the maintainer to react (for example, by uploading to the DELAYED
queue). Here are some delays that you could use as default values:

* Upload fixing only release-critical bugs older than 7 days: 2 days
* Upload fixing only release-critical and important bugs: 5 days
* Other NMUs: 10 days 

Those delays are only examples. In some cases (uploads fixing security
issues, trivial bugfixes blocking a transition, ...), it is desirable
that the fixed package reaches unstable sooner.

Sometimes, release managers decide to allow NMUs with shorter delays for
a subset a bugs (e.g release critical bugs older than 7 days). Also, some
maintainers listed themselves in the Low Threshold NMU list, and accept
that NMUs are uploaded without delay. But even in those cases, it's still
a good idea to give the maintainer a few days to react before you upload,
especially if the patch wasn't available on the BTS before, or if you
know that the maintainer is generally active.

After you upload an NMU, you are responsible for the possible problems
that you might have introduced. You must keep an eye on the package
(subscribing to the package on the PTS is a good idea).
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)

[Frank Küster]

Lucas Nussbaum <[EMAIL PROTECTED]> wrote:

> The DEP currently addresses communication like that:
>
>   When doing an NMU, you must always send a patch with the differences
>   between the current package and your NMU to the BTS.  If the bug you
>   are fixing isn't reported yet, you must do that as well.
>
> I have several questions about the requirement for communication that
> you want to add:
> - Do you want to require two-way communication?
> - If the maintainer doesn't answer, how much time should the NMUer wait
>   for the maintainer, in your opinion?

That has to be decided by common sense, on a case-by-case basis. I
remember when once I screwed up the postrm script of tetex-base or
-bin, and it meant that every attempt of a buildd to build a package
which build-depended on teTeX would lead to a screwed buildd which
needed manual intervention.

The package was NMUed without asking, and I think that was correct. I
was upset at the time, partly because I sort the ACCEPTED messages
differently than BTS e-mail, and read the upload notification before I
even knew about the bug, and partly because there was no patch or NMU
announcement in the BTS.

But except for the missing patch: Doing the upload ASAP was the right
thing to do, given the simpleness of the fix (a trivial bash syntax
error).




But the DEP *should* definitely require an explicit "I want to NMU" or,
in the teTeX case, "I have done the NMU".

> The current wording requires a notification (by sending a mail to the
> BTS). I don't think that it's a good idea to additionally require that
> this mail should be sent to the maintainer's private email address,
> because that doesn't work well with co-maintainance.

Agreed.

Regards, Frank
-- 
Frank Küster
Debian Developer (teTeX/TeXLive)


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

The "giving some time to the maintainer" rule

[Lucas Nussbaum]

On 30/05/08 at 18:24 -0700, Steve Langasek wrote:
> On Fri, May 30, 2008 at 11:49:14AM +0200, Lucas Nussbaum wrote:
> > Now, what we don't agree on:
> >  - I think that giving some time should only be very strongly
> >recommended, but not mandatory.
> >  - You think that giving some time should be mandatory.
> 
> > I think that our opinions are basically the same. The difference is that
> > you want to write something in stone, while I prefer not to impose rules
> > where it's not necessary, because:
> 
> This is begging the question.  Experience tells me that the sort of rules
> under discussion *are* necessary.

You are still talking about the rule "The maintainer *MUST* give some
time to react before uploading the NMU", right?

> > - If you make it mandatory, then you have to provide a workaround for
> >   cases where it's just not possible to wait. And you also have to list
> >   those cases.
> 
> And, so?  That's what we have today.  What's the problem with this that
> you're trying to fix?

No, that's not what we have today. What we have today is the release
team deciding that it has authority to change the NMU rules, to allow
0-day NMUs for bugs older than 7 days old.
- Does the RT really have authority ?
- 0-day means "no need to give some time to the maintainer".

You uploaded a lot of such NMUs yourself, sometimes on packages with an
active maintainer, without even providing a patch on the BTS previously.

You realize that this discussion about the "NMUers must give some time
to the maintainer"-rule also affects the current 0-day NMU policy?

One of the goals of the DEP is to make the 0-day NMU policy useless, by
generalizing it to all bugs (with "delay" > 0 and "delay" a function of
the severity of bugs being fixed).

Now, there are two patches to the DEP that try to address the current
wording. See <[EMAIL PROTECTED]> and
<[EMAIL PROTECTED]>. I would really appreciate
comments on those patches. That would be a lot more useful than general
discussions about rules.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)

[Lucas Nussbaum]

Please, everybody, let's try to discuss patches to the DEP, rather than
general stuff about communication. (unless you want to reject the whole
DEP, but only Richard Hecker seems to want that)

On 30/05/08 at 17:28 -0500, Manoj Srivastava wrote:
> On Fri, 30 May 2008 08:25:34 +0200, Lucas Nussbaum
> <[EMAIL PROTECTED]> said:  
> 
> > On 29/05/08 at 17:47 -0700, Richard Hecker wrote:
> 
> > The goal of the DEP is precisely to replace this section 5.11, and
> > change the usual NMU rules. That's why it's submitted as a DEP (to
> > allow broad discussion), not as an obscure patch to devref :-)
> 
> I think that not communicating with the maintainer is not a
>  desirable change to the document.
> 
> >> Some people will prepare a NMU without even sending an email to the
> >> maintainer. They will claim that this was 'done by the book.'
> 
> > As long as the NMUer sends all the information to the BTS, I'm
> > perfectly fine with the NMUer not sending a private email to the
> > maintainer. (and I think that there's consensus about that)
> 
> For the record, I don't think that we should remove the language
>  about informing the maintainer with a mail message; and no, I don't
>  think we quite have a consensus on this yet.

The DEP currently addresses communication like that:

  When doing an NMU, you must always send a patch with the differences
  between the current package and your NMU to the BTS.  If the bug you
  are fixing isn't reported yet, you must do that as well.

I have several questions about the requirement for communication that
you want to add:
- Do you want to require two-way communication?
- If the maintainer doesn't answer, how much time should the NMUer wait
  for the maintainer, in your opinion?
- Are the delays that are strongly recommended in the DEP really too
  short, in your opinion?

The current wording requires a notification (by sending a mail to the
BTS). I don't think that it's a good idea to additionally require that
this mail should be sent to the maintainer's private email address,
because that doesn't work well with co-maintainance.

The current wording doesn't require the NMUer to wait for an
acknowledgement. Instead, it strongly recommends to give some time to
the maintainer, which doesn't make a big difference ...
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]