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

...<snip>...

>> 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 debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Charles Plessy-12]

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 debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Hertzog-3]

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 debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Charles Plessy-12]

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 debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lars Wirzenius-5]

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 debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lars Wirzenius-5]

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 debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ben Finney-2]

Lars Wirzenius <liw@...> 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 debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Hertzog-3]

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 debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[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?
zack@{upsilon.cc,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

[Frans Pop-3]

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

[Bernhard R. Link-2]

* Raphael Hertzog <hertzog@...> [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 debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[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 Developer                                    http://www.debian.org/
slangasek@...                                     vorlon@...


--
To UNSUBSCRIBE, email to debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lars Wirzenius-5]

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 debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[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?
zack@{upsilon.cc,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

[Manoj Srivastava]

On Fri, 30 May 2008 08:25:34 +0200, Lucas Nussbaum
<lucas@...> 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 <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[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 Developer                                    http://www.debian.org/
slangasek@...                                     vorlon@...


--
To UNSUBSCRIBE, email to debian-project-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[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* man