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

[Bas Wijnen]

On Thu, May 29, 2008 at 05:47:45PM -0700, Richard Hecker wrote:
> I see the same weakness that Henrique listed above. Some people will
> prepare a NMU without even sending an email to the maintainer.

Posting the patch in the BTS does actually send mail to the maintainer.
And it's nicely "in time", because with the DELAYED queue, the upload to
ftp-master doesn't happen before some days.

DELAYED is just a way to automate the "wait a while, then upload to
ftp-master" part.  This DEP makes this explicit.  A bug in the BTS is a
good way to contact a maintainter IMO.  Using the DELAYED queue has an
added benefit that it is completely clear that an NMU will be done, and
when.

> I still want to stress that we should strive to improve communication
> when we can.

Yes, communication is good.  We have several media for it, the two most
important ones being mailing lists and the BTS (IMO).  This DEP proposes
to use the BTS for communication about NMUs.  It was that way already
AFAIK, although some people seem to think private mail was needed as
well.  To avoid any confusion, we should make it explicit in any case.
If many people think private mail is needed before uploading to DELAYED,
please speak up and we'll require that.  To me, that would pretty much
disable all usability of DELAYED, but that may be just me...

> You did not find consensus to adopt your view back then, and I hope
> you will not use DEP1 to establish your preference now.

If we wanted to force ideas on people, we wouldn't have used a DEP.  The
whole system is explicitly about building consensus, so there's no risk
that people sneak things in.  At least that's the idea AIUI, we're still
in the testing phase, so if you feel that it does happen, please point
at it and yell. :-)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

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

[Charles Plessy]

Le Fri, May 30, 2008 at 09:45:57AM +0200, Bas Wijnen a écrit :
> 
> Yes, communication is good.  We have several media for it, the two most
> important ones being mailing lists and the BTS (IMO).  This DEP proposes
> to use the BTS for communication about NMUs.  It was that way already
> AFAIK, although some people seem to think private mail was needed as
> well.  To avoid any confusion, we should make it explicit in any case.
> If many people think private mail is needed before uploading to DELAYED,
> please speak up and we'll require that.  To me, that would pretty much
> disable all usability of DELAYED, but that may be just me...

Hi Bas, Richard, Lucas,

the DEP says:

 - must use BTS,
 - usage of DELAYED is recommended.

This means that people can opt out using DELAYED, but must post something
in the BTS. I think that the problem is not whether the communication is
public in the BTS or private, it is that "something the BTS" does not
imply communication. One can send a patch to the BTS and upload a NMU
without ever asking if it is welcome. Therefore I would much prefer that
the DEP clarifies this by writing that the use of DELAYED is mandatory
if the NMUer does not ask if the upload is welcome.

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


-- 
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:

On 29/05/08 at 17:47 -0700, Richard Hecker wrote:
  


..


The DEP's content is different from what was discussed back then (have
you read it?). And I think that there's consensus that the NMU rules
  

Yes, I have read it. That is one reason why I stated that I have
the same concern expressed last year.

proposed in the DEP are reasonable, implement what is already done by
some NMUers, and will make life of NMUers easier, allowing NMUs to be
done in a more efficient manner.

  

While this may be true, I question how a "more efficient"
NMU process will be better than working to improve
communication. If the goal is to improve section 5.11 of
the Developer's Reference, I think it would be beneficial
to strengthen the gains that already have been made. The
current language highlights the importance of communication
by admonishing a person to contact the maintainer first and
act later.


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)
  

You failed to find consensus in the thread I referenced in the
previous message. I am all ears if you want to explain where
this new "consensus" comes from. The behaviour that Charles
Plessy described today might be very efficient at helping others
with NMUs. I suspect his comment may be based upon the
practice of some NMUers. If your consensus deals with this
prospect, the communication improvements should be obvious.

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)

[Sune Vuorela]

On 2008-05-30, Charles Plessy <[EMAIL PROTECTED]> wrote:
> Le Fri, May 30, 2008 at 09:45:57AM +0200, Bas Wijnen a écrit :
>> 
>> Yes, communication is good.  We have several media for it, the two most
>> important ones being mailing lists and the BTS (IMO).  This DEP proposes
>> to use the BTS for communication about NMUs.  It was that way already
>> AFAIK, although some people seem to think private mail was needed as
>> well.  To avoid any confusion, we should make it explicit in any case.
>> If many people think private mail is needed before uploading to DELAYED,
>> please speak up and we'll require that.  To me, that would pretty much
>> disable all usability of DELAYED, but that may be just me...
>
> Hi Bas, Richard, Lucas,
>
> the DEP says:
>
>  - must use BTS,
>  - usage of DELAYED is recommended.
>
> This means that people can opt out using DELAYED, but must post something
> in the BTS. I think that the problem is not whether the communication is
> public in the BTS or private, it is that "something the BTS" does not
> imply communication. One can send a patch to the BTS and upload a NMU
> without ever asking if it is welcome. Therefore I would much prefer that
> the DEP clarifies this by writing that the use of DELAYED is mandatory
> if the NMUer does not ask if the upload is welcome.

Yeah. let us delay bugfixes from reaching the users as long as
possible.

/Sune
(anyone who replies to this mail needs to fix at least 1 rc bug before
doing so)


-- 
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)

[Frans Pop]

On Friday 30 May 2008, Charles Plessy wrote:
> the DEP says:
>  - must use BTS,
>  - usage of DELAYED is recommended.

I would like to see at least two cases where communication with the 
maintainer is required *before* uploading (DELAYED or not) by sending 
an "intend to NMU" (conform current policy basically):
- packages that are clearly actively maintained (can be seen from changelog)
- packages that are maintained by active teams

There should normally be no need to NMU in such cases and just preparing a 
good patch for the BTS should be sufficient.
The intend to NMU could say "I plan to do an NMU to DELAYED X in Y days; 
please reply before then if you'd prefer to do the upload yourself".

Of course asking for permission on IRC ("/ping : I have a patch 
for RC bug #xx, OK if I NMU?") is also communication (at least, as long 
as you wait for a reply: "sure, go ahead, thx"/"no thanks, I'll take care 
of it").

Exceptions to this rule could be allowed for urgent cases, but the NMU'er 
had better be prepared to defend himself if challenged about it (i.e. have 
good reasons for not following the rule).

Cheers,
FJP


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

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

[Matthew Johnson]

On Fri May 30 08:48, Sune Vuorela wrote:
> > This means that people can opt out using DELAYED, but must post something
> > in the BTS. I think that the problem is not whether the communication is
> > public in the BTS or private, it is that "something the BTS" does not
> > imply communication. One can send a patch to the BTS and upload a NMU
> > without ever asking if it is welcome. Therefore I would much prefer that
> > the DEP clarifies this by writing that the use of DELAYED is mandatory
> > if the NMUer does not ask if the upload is welcome.
> 
> Yeah. let us delay bugfixes from reaching the users as long as
> possible.

Debian has a system where packages have a primarily responsible
maintainer, not one which is a free-for-all. You may disagree whether
this is the best solution, but that is a separate discussion.

Given that we have a primary maintainer there must be a balance between
getting fixes/new versions out as soon as possible and respecting the
autonomy of a maintainer. 

Requiring either authorization or notification and a delay is, IMO, the
least that we should do to keep this balance. Authorization may be in
the form of an explicit mail or presence on the LowThresholdNMU list and
notification/delay may be a post to the BTS and upload to DELAYED, which
makes it very simple for an NMUer to do (they should be posting to the
BTS _anyway_ and DELAYED doesn't require a separate upload action) and
in many cases means that they can just upload directly. 

If you think that significant fixes are being delayed by the maintainer
then by all means complain about specific cases, but this does not mean
we should be making NMUs without maintainers having a chance to respond.

In the vast majority of cases these uploads are being made to unstable
and will only be affecting users who have accepted some amount of
breakage and disruption by using pre-release versions. Another couple of
days is not going to cause any harm.

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

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

[Lucas Nussbaum]

On 30/05/08 at 01:44 -0700, Richard Hecker wrote:
> Lucas Nussbaum wrote:
>> On 29/05/08 at 17:47 -0700, Richard Hecker wrote:
>>> 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)
>>   
> You failed to find consensus in the thread I referenced in the
> previous message.

... which led me to thinking of what we could do to improve the current
situation while staying consensual.

Because I didn't find consensus in the thread you referenced, I should
be forbidden to propose anything about NMUs forever?

> I am all ears if you want to explain where this new "consensus" comes
> from.

Re-read this thread and the one from the first call for comments. All
comments except yours and Charles' have been on details, from people
generally agreeing with the principles outlined in this DEP.

> The behaviour that Charles
> Plessy described today might be very efficient at helping others
> with NMUs. I suspect his comment may be based upon the
> practice of some NMUers. If your consensus deals with this
> prospect, the communication improvements should be obvious.

Please stop suspecting things. Please quote real problems in the DEP,
and provide alternatives.

It seems that you are reading this DEP as "the DEP from the guy I
disagreed with about NMUs". That's unfair. There are two drivers listed
at the top of the DEP for a reason. And the DEP already went through a
lot of review, first private, then public (look at the wiki history if
you want).
-- 
| 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]

On 30/05/08 at 17:38 +0900, Charles Plessy wrote:
> Le Fri, May 30, 2008 at 09:45:57AM +0200, Bas Wijnen a écrit :
> > 
> > Yes, communication is good.  We have several media for it, the two most
> > important ones being mailing lists and the BTS (IMO).  This DEP proposes
> > to use the BTS for communication about NMUs.  It was that way already
> > AFAIK, although some people seem to think private mail was needed as
> > well.  To avoid any confusion, we should make it explicit in any case.
> > If many people think private mail is needed before uploading to DELAYED,
> > please speak up and we'll require that.  To me, that would pretty much
> > disable all usability of DELAYED, but that may be just me...
> 
> Hi Bas, Richard, Lucas,
> 
> the DEP says:
> 
>  - must use BTS,
>  - usage of DELAYED is recommended.
> 
> This means that people can opt out using DELAYED, but must post something
> in the BTS. I think that the problem is not whether the communication is
> public in the BTS or private, it is that "something the BTS" does not
> imply communication. One can send a patch to the BTS and upload a NMU
> without ever asking if it is welcome. Therefore I would much prefer that
> the DEP clarifies this by writing that the use of DELAYED is mandatory
> if the NMUer does not ask if the upload is welcome.

Let's state clearly what we agree on (I think):
 - Communicating through the BTS is OK
 - Giving some time to the maintainer to react is recommended.

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:
- Debian developers are generally smart people.
- Debian developers usually do sensible things.
- Debian developers don't try to circumvent recommendations unless
  there's a very good reason to.
- 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.

I really don't think that the fact that it's recommended to give some
time to the maintainer, rather than mandatory, will result in more
cases where the NMUer would not give some time to the maintainer. I
think that we should leave the DEP like that, and reconsider later if we
discover that many people are actually abusing that.
-- 
| 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: DEP licenses

[Simon Josefsson]

Lars Wirzenius <[EMAIL PROTECTED]> writes:

> License
> ---
> 
> The DEP must have a license that is DFSG free.
>
> I've just pushed that to http://bzr.debian.org/dep/dep0/trunk/ (I didn't
> think that needs any discussion; if I was wrong, it's easy enough to
> revert).
>
> I'm not sure if there's a consensus on which license to pick for all
> DEPs. Comments on that are welcome.

The problem with allowing any DFSG free license is that it may mean that
the license for DEPx may be incompatible with DEPy.  If a DEPz wants to
combine, or just re-use portions of, DEPx and DEPy, the license of DEPz
will be quite complex.

I believe it would lead to less problems to require that all DEPs are
licensed under a liberal and widely compatible license, such as the
Expat, X11 or the modified BSD license.

/Simon


-- 
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)

[Bas Wijnen]

Hi,

On Fri, May 30, 2008 at 11:40:53AM +0200, Frans Pop wrote:
> On Friday 30 May 2008, Charles Plessy wrote:
> > the DEP says:
> >  - must use BTS,
> >  - usage of DELAYED is recommended.
> 
> I would like to see at least two cases where communication with the 
> maintainer is required *before* uploading (DELAYED or not)

I see delayed as a way to do "wait some time and then upload".  That is,
uploading to DELAYED should not be considered "uploading a package" IMO.
It's simply a tool to not need to get back at it if things are going as
planned (either the package should be NMUed, or the maintainer uploads a
new version in time).

> by sending an "intend to NMU" (conform current policy basically):
> - packages that are clearly actively maintained (can be seen from changelog)
> - packages that are maintained by active teams

So I don't think any special consideration is needed here.  Of course,
if writing a NMU changelog entry is too much trouble for you, you're
free to upload just a patch.  But uploading an NMU patch to DELAYED and
the BTS at the same time is acceptable even if you don't expect the NMU
to actually reach the archive, IMO.

> There should normally be no need to NMU in such cases and just preparing a 
> good patch for the BTS should be sufficient.

Yes, but there's no harm in preparing an NMU anyway, so there's no need
to forbid it IMO.  I'd just let people decide what method they prefer.

> The intend to NMU could say "I plan to do an NMU to DELAYED X in Y days; 
> please reply before then if you'd prefer to do the upload yourself".

What's wrong with uploading to DELAYED/X+Y ?

> Exceptions to this rule could be allowed for urgent cases, but the NMU'er 
> had better be prepared to defend himself if challenged about it (i.e. have 
> good reasons for not following the rule).

The approach of the DEP is to not make strict rules, but only
recommendations.  Not following them does indeed need a reason.

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.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

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

[Bas Wijnen]

On Fri, May 30, 2008 at 07:03:16PM +0900, Charles Plessy wrote:
> I think that when the mainainer is active, he has to be consulted if a
> NMU is planned. As a compromise with those who disagree, I propose that
> he should be given time to react.

I'm one of the people who "disagrees", but actually I don't. ;-)  When
planning an NMU, you must notify the maintainer, and give him time to
react, and respond to the reaction.  That's basically the same thing as
consulting him IMO, except that "no response" leads to "Ok".  I think
that is good, it's one of the reasons NMUs are possible at all.

> > result in more cases where the NMUer would not give some time to the
> > maintainer.
> 
> Exactly, I propose that the maintainer can say "no, thank you" whithout
> it becoming a crisis.

Certainly.  If that wasn't clear, please propose a new wording for that
part of the DEP.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

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

[Charles Plessy]

Hi again,

Le Fri, May 30, 2008 at 11:40:53AM +0200, Frans Pop a écrit :
> - packages that are clearly actively maintained (can be seen from changelog)
> - packages that are maintained by active teams
> 
> There should normally be no need to NMU in such cases and just preparing a 
> good patch for the BTS should be sufficient.


Le Fri, May 30, 2008 at 11:49:14AM +0200, Lucas Nussbaum a écrit :
> On 30/05/08 at 17:38 +0900, Charles Plessy wrote:
> > 
> > "something the BTS" does not
> > imply communication. One can send a patch to the BTS and upload a NMU
> > without ever asking if it is welcome. Therefore I would much prefer that
> > the DEP clarifies this by writing that the use of DELAYED is mandatory
> > if the NMUer does not ask if the upload is welcome.
> 
>  - You think that giving some time should be mandatory.

I think that when the mainainer is active, he has to be consulted if a
NMU is planned. As a compromise with those who disagree, I propose that
he should be given time to react.

The DEP introduces many improvements, so I would be very sorry if they
would be bundled with a section whose possible interpretation is that
sending a patch to the BTS is a good reason to push one's favorite
changes in the archives without asking the person first who has the
primary responsability for the package. Some strong reactions in this
thread suggest that we need to be clear on this.


> result in more cases where the NMUer would not give some time to the
> maintainer.

Exactly, I propose that the maintainer can say "no, thank you" whithout
it becoming a crisis.

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


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

Re: DEP licenses

[Lars Wirzenius]

pe, 2008-05-30 kello 11:42 +0200, Simon Josefsson kirjoitti:
> I believe it would lead to less problems to require that all DEPs are
> licensed under a liberal and widely compatible license, such as the
> Expat, X11 or the modified BSD license.

I agree that that would be more convenient. I don't know if there's
consensus that we should do it. However, if no-one objects within a
couple of weeks, I'll add a suggestion to use the Expat license in a
couple of weeks or so.



-- 
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 30/05/08 at 12:23 +0200, Bas Wijnen wrote:
> On Fri, May 30, 2008 at 07:03:16PM +0900, Charles Plessy wrote:
> > I think that when the mainainer is active, he has to be consulted if a
> > NMU is planned. As a compromise with those who disagree, I propose that
> > he should be given time to react.
> 
> I'm one of the people who "disagrees", but actually I don't. ;-)  When
> planning an NMU, you must notify the maintainer, and give him time to
> react, and respond to the reaction.  That's basically the same thing as
> consulting him IMO, except that "no response" leads to "Ok".  I think
> that is good, it's one of the reasons NMUs are possible at all.
> 
> > > result in more cases where the NMUer would not give some time to the
> > > maintainer.
> > 
> > Exactly, I propose that the maintainer can say "no, thank you" whithout
> > it becoming a crisis.
> 
> Certainly.  If that wasn't clear, please propose a new wording for that
> part of the DEP.

Proposed wdiff: (not applied to the wiki)

== 5.11.1 When and how to do an NMU ==

[...]

  While there are no general rules, it's {+strongly+} recommended to
  [-upload-] {+give some time to the maintainer to react (for example,
  by uploading+} to the DELAYED [-queue with a delay of at least a few
  days.-] {+queue).+} Here are some [-examples-] {+example delays+} that
  you could use as default values:

The new paragraph is: (yes, wdiff is hard to read)

   While there are no general rules, it's strongly recommended to give
   some time to the maintainer to react (for example, by uploading to
   the DELAYED queue). Here are some example delays that you could use
   as default values:

What do you think?
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: DEP licenses

[Stefano Zacchiroli]

On Fri, May 30, 2008 at 01:35:49PM +0300, Lars Wirzenius wrote:
> pe, 2008-05-30 kello 11:42 +0200, Simon Josefsson kirjoitti:
> > I believe it would lead to less problems to require that all DEPs are
> > licensed under a liberal and widely compatible license, such as the
> > Expat, X11 or the modified BSD license.
> I agree that that would be more convenient. I don't know if there's

AOL

> consensus that we should do it. However, if no-one objects within a
> couple of weeks, I'll add a suggestion to use the Expat license in a
> couple of weeks or so.

Please go ahead, just a couple of suggestion:

- please mention why Expat is being suggested, the scenario of packing
  DEPs together should be enough to convince the reader IMO

- please mention the fact that Expat is kinda MIT/X11 with , I feel the "Expat" name can sound weird to a
  lot of non -legal readers

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


-- 
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:

On 30/05/08 at 01:44 -0700, Richard Hecker wrote:
  


..


You failed to find consensus in the thread I referenced in the
previous message.



... which led me to thinking of what we could do to improve the current
situation while staying consensual.

Because I didn't find consensus in the thread you referenced, I should
be forbidden to propose anything about NMUs forever?

  

While I admire your desire to improve the current situation, it
looks to me like you still have not found consensus. You can
claim that it exists, but others see value in contacting an active
maintainer before uploading the NMU.

In years past, I would route all email through an employment
account (I basically lived there anyway and it was the best option
to assure timely reception and response ;-). In this environment,
it was common to remind people that vacations could last a week
or two. It was amazing how often people were inclined to push
the panic button because they had waited a few days for a
response.

DEP1 reminds me of those days. If you eliminate the goal of
contacting the maintainer first, you can easily push through the
NMU via one of the DELAYED queues. We are left to rehash all
those old arguments about how long is too long and why
someone needs such a long vacation. Although it may seem
like a dirty word to you, I do suspect that these arguments were
worked out when the developers reference was first put
together. I just do not see the value when some
Johnny-come-lately decides that all the decisions need to
be reworked.

You have already described my comments as an exception.
You can still claim consensus as you explain why this
rewrite is an improvement. Lack of a further response
from me does not indicate that I suddenly agree with you.

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)

[Charles Plessy]

Le Fri, May 30, 2008 at 12:57:21PM +0200, Lucas Nussbaum a écrit :
> 
> The new paragraph is: (yes, wdiff is hard to read)
> 
>While there are no general rules, it's strongly recommended to give
>some time to the maintainer to react (for example, by uploading to
>the DELAYED queue). Here are some example delays that you could use
>as default values:

Hi all,

I have got an idea. How about:

While there are no general rules, it's strongly recommended to give some
time to the maintainer to react (for example, by uploading to the
DELAYED queue). If you go against this recommendation, you must document
your reasons in the BTS. Here are some example delays that you could use
as default values:

Have a nice day,

-- 
Charles


-- 
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)

[Raphael Hertzog]

On Fri, 30 May 2008, Richard Hecker wrote:
> In years past, I would route all email through an employment
> account (I basically lived there anyway and it was the best option
> to assure timely reception and response ;-). In this environment,
> it was common to remind people that vacations could last a week
> or two. It was amazing how often people were inclined to push
> the panic button because they had waited a few days for a
> response.

We do have a process for maintainers so that they can mark themselves as
beeing in vacation. We do also encourage since quite some year
co-maintenance so that if one maintainer is absent, there's still someone
else around.

Please come back in 2008! ;-)

You speak as an "elder" that doesn't want to move forward and you have
failed to explain why mailing the BTS doesn't achieve the same results
than mailing the maintainer.

You could have told that you have different filtering for BTS mails and
direct mails. This is something we can understand, as such we could decide
to put a direct CC to the maintainer to the mail that is sent to the BTS
in order to resolve your concern.

But no, you prefer to not explain your problem... this is no way to
participate in such a discussion. Don't be opposed to something if you
can't come up with a rationale of why it's bad.

> DEP1 reminds me of those days. If you eliminate the goal of
> contacting the maintainer first, you can easily push through the
> NMU via one of the DELAYED queues. We are left to rehash all
> those old arguments about how long is too long and why
> someone needs such a long vacation. Although it may seem
> like a dirty word to you, I do suspect that these arguments were
> worked out when the developers reference was first put
> together.

And times changes... as one of the people who maintained/maintains the
developers-reference, I totally agree that this DEP is welcome
and that we should reword the developers-reference in that regard
because the practice of NMU changed a lot since the release team
created the 0-day NMU and so on. And not all NMU are of equal importance.

> I just do not see the value when some Johnny-come-lately decides that
> all the decisions need to be reworked.

Please stop this pissing contest... I can claim a longer history of
participation than you, but this doesn't bring anything to the discussion.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
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)

[Charles Plessy]

Le Fri, May 30, 2008 at 02:50:28PM +0200, Raphael Hertzog a écrit :
> 
> Please come back in 2008! ;-)
> You speak as an "elder" that doesn't want to move forward
> But no, you prefer to not explain your problem...
> Please stop this pissing contest...

I have read better emails from you, Raphaël.

The difference between "using the BTS" and "asking the maintainer" is
that dropping a patch in the BTS is not asking the maintainer if the NMU
is welcome.

When we give obvious signs of activity, I and others prefer being
consulted before a NMU is performed.

This is my last email in this thread. If NMUers want to do work that may
be unuseful, unwelcome and ignored, I can not stop them.

Have a nice week-end.

-- 
Charles


-- 
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)

[Lars Wirzenius]

pe, 2008-05-30 kello 04:34 -0700, Richard Hecker kirjoitti:
> I just do not see the value when some
> Johnny-come-lately decides that all the decisions need to
> be reworked.

I'd like to add my voice to the choir of people who think the length of
participation in Debian development should not matter. I find that Lucas
has given good justifications to support his view. The fact that he's
only been around Debian for several years now does not mean that his
point of view can be dismissed by someone just because they've been
around a few years more.

Seniority is not irrelevant, but it has no power against valid
arguments.

Complete agreement by everyone is not necessary for consensus. As far as
I can see, there have been few people talking against the changes DEP1
proposes. While the process is still going on, and there's certainly
still plenty of opportunity to come up with reasons why DEP1 should not
go forward, for now it seems there is a rough consensus that it should.



-- 
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)

[Lars Wirzenius]

pe, 2008-05-30 kello 22:01 +0900, Charles Plessy kirjoitti:
> Le Fri, May 30, 2008 at 02:50:28PM +0200, Raphael Hertzog a écrit :
> > 
> > Please come back in 2008! ;-)
> > You speak as an "elder" that doesn't want to move forward
> > But no, you prefer to not explain your problem...
> > Please stop this pissing contest...
> 
> I have read better emails from you, Raphaël.
> 
> The difference between "using the BTS" and "asking the maintainer" is
> that dropping a patch in the BTS is not asking the maintainer if the NMU
> is welcome.

Patch to the BTS plus a DELAYED/n upload (with a sufficiently large n)
is, to me, a way of asking the maintainer. It is, perhaps, less smoothly
diplomatic than e-mailing privately, but I don't really see that it is
rude. One e-mail response from the maintainer should be enough for the
DELAYED upload to be deleted (by the would-be NMUer, of course).



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

Re: DEP licenses

[Ben Finney]

Lars Wirzenius <[EMAIL PROTECTED]> writes:

> I agree that that would be more convenient. I don't know if there's
> consensus that we should do it. However, if no-one objects within a
> couple of weeks, I'll add a suggestion to use the Expat license in a
> couple of weeks or so.

I would prefer to recommend a copyleft such as the GPL, simply to
encourage more free works.

However, if the consensus is to go with Expat for DEPs, I have no
specific objection.

-- 
 \"We cannot solve our problems with the same thinking we used |
  `\   when we created them." —Albert Einstein |
_o__)  |
Ben Finney


-- 
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)

[Raphael Hertzog]

On Fri, 30 May 2008, Charles Plessy wrote:
> The difference between "using the BTS" and "asking the maintainer" is
> that dropping a patch in the BTS is not asking the maintainer if the NMU
> is welcome.

In http://wiki.debian.org/NmuDep I see things like "Did you give enough
time to the maintainer? 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?" in the section "When and how to do an NMU".

For me, this clearly means that the time before the maintainer had a
chance to look into the issue is an important factor in the decision
of NMUing or not.

> When we give obvious signs of activity, I and others prefer being
> consulted before a NMU is performed.

You shouldn't consider an upload to DELAYED as a real upload. You are
consulted about the possible NMU, it's just that lack of answer in the
delay means by default "yes please do" instead of the opposite.

Please try to put yourself also in the situation of someone that does
NMUs. Having to mail the maintainer to ask if the NMU is welcome is
pointless when you have gone to the trouble of creating a full patch.

Consider the two scenario where you start with a patch for a bugfix:
Your scenario:
- you send the patch to the BTS to let other people know that you wrote a
  patch (if there's no pre-existing patch)
- you mail the maintainer proposing an NMU
- you write something in your calendar so that in X days you can upload if
  you didn't get an answer
- the delay is here
- you prepare the NMU
- if you get a positive response (or no response), you upload
- if you get a negative response, you do nothing

The DELAYED scenario:
- you prepare the NMU
- you send the NMU patch to the BTS with nmudiff
- you upload to DELAYED
- the delay is here
- if you get a positive response (or no response), you do nothing
- if you get a negative response, you cancel

The second scenario is clearly optimized for the situation where NMUs
are accepted/welcome, as you have nothing to do after the initial work if
your NMU is fine. The first scenario is not because you have to remember
to do the upload once the delay is elapsed.

Given that we also clearly communicate the message to maintainers that
they shouldn't see NMU as hostile and they should be glad someone is
willing to help them (see 5.11.2 "NMUs, from the maintainer's point of
view"), I think it makes much more sense to optimize the workflow for the
case where the NMU is accepted and welcome.

I'm sure you can understand this logic. I can also understand the
desire of the maintainers to be involved in the whole process, and if you
stick to the facts, he clearly is, since he's the recipient of all BTS
mails and can review the work and ask for cancellation of the delayed
upload (or upload another fix by himself).

But, in your opinion, it doesn't seem to be enough. Why?

Maybe the mail sent by nmudiff should make it even more clear that
the maintainer can simply use the patch and upload by himself sooner, or
ask him to cancel the upload if the fix doesn't satisfy him.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
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)

[Stefano Zacchiroli]

On Fri, May 30, 2008 at 10:01:05PM +0900, Charles Plessy wrote:
> I have read better emails from you, Raphaël.

Useless personal attack.

> The difference between "using the BTS" and "asking the maintainer" is
> that dropping a patch in the BTS is not asking the maintainer if the NMU
> is welcome.
> 
> When we give obvious signs of activity, I and others prefer being
> consulted before a NMU is performed.

The whole point of this DEP (as I see it, YMMV) is avoiding delays which
can block the enthusiasm of someone which is working on a problem,
because somebody else is not. Too many times it happens that the diluted
current NMU procedure block problem fixes.

The technique to do so is to let people which are on the enthusiastic
peak of bug fixing work pro-actively and *then* upload to delayed and
mail.  If the maintainer of the affected package is one of the active
ones, by definition it will have time to react if he consider the fix
bogus or whatever else [1].  If the maintainer is not active, the delay
will just expire, the package will be uploaded, and the difference with
the current procedure which require to mail first will be irrelevant.

So, what is the problem you are trying to point out? What has the active
maintainer type of DD to loose?

Cheers.

[1] yes, there are technical issues here, like who can delete stuff from
delayed, and how long the delays should be. AFAIR they have been
discussed in other threads related to DEP1

-- 
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: DEP1: Clarifying policies and workflows for Non Maintainer?Uploads (NMUs)

[Frans Pop]

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.

Patches for open issue are of course most welcome.

Cheers,
FJP


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

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

[Bernhard R. Link]

* Raphael Hertzog <[EMAIL PROTECTED]> [080530 15:46]:
> Please try to put yourself also in the situation of someone that does
> NMUs. Having to mail the maintainer to ask if the NMU is welcome is
> pointless when you have gone to the trouble of creating a full patch.

I think there is an important difference between those two: the amount
of testing needed.

> Consider the two scenario where you start with a patch for a bugfix:
> Your scenario:
> - you send the patch to the BTS to let other people know that you wrote a
>   patch (if there's no pre-existing patch)

For this step you only have to test the patch. Testing totally unrelated
parts is neighter needed nor very useful.

> - you mail the maintainer proposing an NMU
> - you write something in your calendar so that in X days you can upload if
>   you didn't get an answer
> - the delay is here
> - you prepare the NMU

Here you have to test the full package. Some libraries needed might have
changed in subtile ways or the scripts and commands you call at build
time.

> - if you get a positive response (or no response), you upload
> - if you get a negative response, you do nothing

Also this results in the package you uploaded and the packages the
autobuilder create have just the normal differences between packages
build by maintainers and auto-build packages in terms of library
versions and so on.

> The DELAYED scenario:
> - you prepare the NMU
> - you send the NMU patch to the BTS with nmudiff
> - you upload to DELAYED

For this you have to already checked the package fully. If you can an
NACK from the Maintainer, having done so much work for nothing is quite
frustrating.

> - the delay is here
> - if you get a positive response (or no response), you do nothing
> - if you get a negative response, you cancel

This also means everything you use has about a full week to change
between the time you build the package and the autobuilder.
I also hope you do not do "nothing", but check the buildd logs if you
broke anything. It sometimes need a bit between an FTBS and the bugs
being sent.

Hochachtungsvoll,
Bernhard R. Link


-- 
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)

[Steve Langasek]

On Fri, May 30, 2008 at 04:08:39PM +0300, Lars Wirzenius wrote:
> pe, 2008-05-30 kello 22:01 +0900, Charles Plessy kirjoitti:
> > Le Fri, May 30, 2008 at 02:50:28PM +0200, Raphael Hertzog a écrit :

> > > Please come back in 2008! ;-)
> > > You speak as an "elder" that doesn't want to move forward
> > > But no, you prefer to not explain your problem...
> > > Please stop this pissing contest...

> > I have read better emails from you, Raphaël.

> > The difference between "using the BTS" and "asking the maintainer" is
> > that dropping a patch in the BTS is not asking the maintainer if the NMU
> > is welcome.

> Patch to the BTS plus a DELAYED/n upload (with a sufficiently large n)
> is, to me, a way of asking the maintainer. It is, perhaps, less smoothly
> diplomatic than e-mailing privately, but I don't really see that it is
> rude.

Patch to the BTS is not a statement that the maintainer has a deadline to
reply before the patcher screws up the package in the archive with a wrong
patch.

Sending a patch to the BTS is not sufficient - the mail to the BTS must also
clearly state the intent to NMU, so the maintainer knows the mail must be
handled with a high priority.

-- 
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: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)

[Lars Wirzenius]

pe, 2008-05-30 kello 09:49 -0700, Steve Langasek kirjoitti:
> Sending a patch to the BTS is not sufficient - the mail to the BTS must also
> clearly state the intent to NMU, so the maintainer knows the mail must be
> handled with a high priority.

I agree with that, of course.



-- 
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)

[Stefano Zacchiroli]

On Fri, May 30, 2008 at 09:49:55AM -0700, Steve Langasek wrote:
> Sending a patch to the BTS is not sufficient - the mail to the BTS must also
> clearly state the intent to NMU, so the maintainer knows the mail must be
> handled with a high priority.

Not that I am against requiring the specific NMU mention in the mail
(especially considering how cheap it as a requirement), but isn't the
package maintainer going to receive some upload notification for the
entrance in DELAYED? Out of memory indeed it is not, but probably it
should (of course only the first time the package enters DELAYED, not
each passing day ...).

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: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)

[Manoj Srivastava]

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.

manoj
-- 
If you waste your time cooking, you'll miss the next meal.
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: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)

[Steve Langasek]

On Fri, May 30, 2008 at 11:23:25PM +0200, Stefano Zacchiroli wrote:
> On Fri, May 30, 2008 at 09:49:55AM -0700, Steve Langasek wrote:
> > Sending a patch to the BTS is not sufficient - the mail to the BTS must also
> > clearly state the intent to NMU, so the maintainer knows the mail must be
> > handled with a high priority.

> Not that I am against requiring the specific NMU mention in the mail
> (especially considering how cheap it as a requirement), but isn't the
> package maintainer going to receive some upload notification for the
> entrance in DELAYED?

To my knowledge, it is not.  But even if it is, I believe this would still
be the wrong workflow to encourage.  NMU patches should be made available to
maintainers as early as possible in the process, so that maintainers can
point out possible issues with them, and this is true even if the intent is
to upload the NMU immediately after emailing to the BTS.

-- 
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]

Updated Debian Maintainers Keyring

[Anibal Monsalve Salazar]

With the upload of debian-maintainers version 1.35, the following
changes to the keyring have been made:

dm:[EMAIL PROTECTED]
Full name: Anuradha Weeraman
Added key: F190A93A75D2BF6B2B3C1C3E7C64D4A494D68544

A summary of all the changes in this upload follows.

Debian distribution maintenance software,
on behalf of,
Anibal Monsalve Salazar <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 31 May 2008 10:43:57 +1000
Source: debian-maintainers
Binary: debian-maintainers
Architecture: source all
Version: 1.35
Distribution: unstable
Urgency: medium
Maintainer: Debian Maintainer Keyring Team <[EMAIL PROTECTED]>
Changed-By: Anibal Monsalve Salazar <[EMAIL PROTECTED]>
Description: 
 debian-maintainers - GPG keys of Debian maintainers
Closes: 482477
Changes: 
 debian-maintainers (1.35) unstable; urgency=medium
 .
   * Added Debian maintainer Anuradha Weeraman. Closes: #482477
Files: 
 296cbdb072672ebc52a495348f643419 1091 misc extra debian-maintainers_1.35.dsc
 d0dbf493ac5fd96e106a9d6b31e75599 2995593 misc extra 
debian-maintainers_1.35.tar.gz
 c1798724388a3cdd79727ebe3bb90d36 382038 misc extra 
debian-maintainers_1.35_all.deb
 3c24904f5fa87f4baee57a46e35acece 464280 raw-keyring - 
debian-maintainers_1.35_all.gpg

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIQKBGgY5NIXPNpFURAsXEAKC3aBSfJX81SqxDjl7YgUouWQFILACePptq
N+/iMXclXf8tI0bvWdD8jFQ=
=X711
-END PGP SIGNATURE-


-- 
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)

[Steve Langasek]

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.

> - Debian developers are generally smart people.
> - Debian developers usually do sensible things.

"generally" and "usually" aren't very persuasive.  What percentage of the
developer population should be not-smart people who do insensible things,
before we should start spelling out rules?

Unless we're going to do away with the concept of package maintainers
altogether, eliminating rules on NMU practices will only serve to breed
conflict when developers disagree about where the line should be.  The NMU
rules exist to provide *social* guidelines on how we should behave in order
to function effectively as a community.

> - Debian developers don't try to circumvent recommendations unless
>   there's a very good reason to.

Oh, well, that's just patently false, of course.

> - 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?

If you *don't* make it mandatory, then you have developers doing half-assed
NMUs.

Actually, even though it *is* mandatory, you still have developers doing
half-assed NMUs.  Such as the developer who NMUed a package I comaintain,
applying a patch for a bug he himself filed, on two days notice, without
receiving confirmation of any sort from the maintainers wrt this bug.  I
don't think a "be groovy to each other" NMU policy is at all acceptable.
when that kind of thing happens with the /current/ NMU guidelines.

-- 
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]