Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
* Stefano Zacchiroli | 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? No, they are not. | 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 | ...). This requires a fair bit more state than the queue currently has. I'm not sure I want to do this, at least not without a good and convincing argument for why it's useful. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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)
On Sun, Jun 01, 2008 at 07:01:44PM +0200, Tollef Fog Heen wrote: | 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 | ...). This requires a fair bit more state than the queue currently has. I'm not sure I want to do this, at least not without a good and convincing argument for why it's useful. I think this whole thread should be convincing :) No matter, what will be the procedure we will agree upon, if someone is trying to NMU a package of mine using DELAYED, I want to be notified ASAP even if the NMUer (rightful or not) forgot to inform me. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ I'm still an SGML person,this newfangled /\ All one has to do is hit the XML stuff is so ... simplistic -- Manoj \/ right keys at the right time signature.asc Description: Digital signature
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
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]
Re: DEP1: Clarifying policies and workflows for Non Maintainer?Uploads (NMUs)
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
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
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)
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)
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] http://www.debian.org/~srivasta/ 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)
On 30/05/08 at 09:15 +0900, Charles Plessy wrote:
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.
{+After you upload an NMU, you are responsible for the possible
problems that you might have introduced. You must monitor the package
for a few weeks (subscribing to the package on the PTS is a good
idea).+}
While there are no general rules, it's recommended to upload to the
DELAYED queue with a delay of at least a few days. Here are some
examples that you could use as default values:
I sent two separate emails to two different parts of the thread for a
reason. Now you merged them, and people following only the other
subthread might not read this.
Since the maintainer has the duty of caring of the NMU even if it does
not come at the best timing, can you add the corresponding duty for the
NMUer to try to contact the maintainer? For instance, one could add:
The use of the DELAYED queue is mandatory when no contact was
established with the maintainer before the upload.
I think that the DEP is pretty clear about that, and doesn't need to be
improved for that (it emphasizes the need to use the BTS to notify the
maintainer). Can you point to a specific part that should be improved?
--
| 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)
On 29/05/08 at 17:47 -0700, Richard Hecker wrote:
Lucas Nussbaum wrote:
On 26/05/08 at 09:55 -0300, Henrique de Moraes Holschuh wrote:
I miss one thing in these guidelines: they sort of give you the idea you
can NMU someone's packages off as long as you go by the book, and that
you have the RIGHT to do it no matter what.
I made the following change to the DEP to address this: (wdiff format)
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.
{+After you upload an NMU, you are responsible for the possible
problems that you might have introduced. You must monitor the package
for a few weeks (subscribing to the package on the PTS is a good
idea).+}
While there are no general rules, it's recommended to upload to the
DELAYED queue with a delay of at least a few days. Here are some
examples that you could use as default values:
I have the same concern about this language as I did when I explained
in October (http://lists.debian.org/debian-mentors/2007/10/msg00229.html)
that a person should follow the usual NMU rules. It may be a case where
agree to disagree, but our developers reference clearly states in section
5.11.1 (http://www.debian.org/doc/developers-reference) to contact the
developer first, and act later.
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 see the same weakness that Henrique listed above. Some people will
prepare a NMU without even sending an email to the maintainer. They
will claim that this was 'done by the book.' I am not oblivious to what
you (http://lists.debian.org/debian-devel/2007/10/msg00547.html) may
find painful but, I still want to stress that we should strive to improve
communication when we can. You did not find consensus to adopt your
view back then, and I hope you will not use DEP1 to establish your
preference now.
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
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.
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)
--
| 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)
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)
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)
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)
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 maintainer: 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)
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)
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)
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: DEP1: Clarifying policies and workflows for Non Maintainer?Uploads (NMUs)
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)
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)
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: DEP1: Clarifying policies and workflows for Non Maintainer?Uploads (NMUs)
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: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEP1: Clarifying policies and workflows for Non Maintainer?Uploads (NMUs)
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)
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)
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)
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)
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: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
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)
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)
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)
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)
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)
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] http://www.debian.org/~srivasta/ 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)
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]
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
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]
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
On 25/05/08 at 09:12 +0200, Simon Josefsson wrote: Bas Wijnen [EMAIL PROTECTED] writes: Hi, This is the second call for comments (long overdue) on DEP1. Hi! Please specify the license for the DEP1 text. Is it DFSG free? I suggested earlier [1] that DEP0 should say that all DEP's should be licensed under a DFSG-compatible license. I recall positive comments regarding that, but it doesn't seem DEP0 itself has changed. I think that this should be adressed in DEP0, not specifically in DEP1 (i.e DEP0 should recommend something, and we will follow it in DEP1). Zack, Dato, Lars, could you do something about 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: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
On 27/05/08 at 20:28 +0200, Bas Wijnen wrote:
Quoting Charles: “In order to acknowledge the NMU, it would be necessary
to revert the current work, apply the NMU patch, merge the reverted work
and resolve the conflicts.”
I think I wrote about the 3rd paragraph of 5.11.2, maybe I should have
quoted it as well: “When a package has been NMUed, the maintainer should
acknowledge it in the next upload. This makes clear that the changes
were accepted in the maintainer's packaging, and that they aren't lost
again. For this, you MUST first incorporate the changes into your
packaging, by applying the patch that was sent. Make sure to include the
NMU's changelog entry in your own changelog. This is important to allow
the BTS version tracking to work.”
[Emphasis on “must” added on purpose, that was meant to be my point.]
Right. I agree that must is too strong there, but I'd fix it by adding
something like as far as you want to keep them. You must indeed keep
the changelog entry, and it's good that this is emphasized IMO.
I made the following change to the DEP: (wdiff format)
When a package has been NMUed, the maintainer should acknowledge it in
the next upload. This makes clear that the changes were accepted in
the maintainer's packaging, and that they aren't lost again. For
this, you must first incorporate the changes into your [-packaging, by
applying the patch that was sent.-] {+package, as far as you want to
keep them.+} 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.
--
| Lucas Nussbaum
| [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |
signature.asc
Description: Digital signature
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
On 26/05/08 at 09:55 -0300, Henrique de Moraes Holschuh wrote:
On Sun, 25 May 2008, Bas Wijnen wrote:
3. NMUs are often received with angry comments from maintainers.
[...]
This Debian Enhancement Proposal has two goals:
3. We try to encourage a responsible approach for NMUs,
instead of an approach based on strict rules
[...]
I miss one thing in these guidelines: they sort of give you the idea you
can NMU someone's packages off as long as you go by the book, and that
you have the RIGHT to do it no matter what.
I made the following change to the DEP to address this: (wdiff format)
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.
{+After you upload an NMU, you are responsible for the possible
problems that you might have introduced. You must monitor the package
for a few weeks (subscribing to the package on the PTS is a good
idea).+}
While there are no general rules, it's recommended to upload to the
DELAYED queue with a delay of at least a few days. Here are some
examples that you could use as default values:
--
| 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)
Hi Lucas, hi all,
Le Thu, May 29, 2008 at 11:27:49PM +0200, Lucas Nussbaum a écrit :
When a package has been NMUed, the maintainer should acknowledge it in
the next upload. This makes clear that the changes were accepted in
the maintainer's packaging, and that they aren't lost again. For
this, you must first incorporate the changes into your [-packaging, by
applying the patch that was sent.-] {+package, as far as you want to
keep them.+} 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 you sure that the BTS can not operate without the changelogs? Can't
we do this using the email interface? In this case, the sentence could
be reformulated like The preferred way to interact with the BTS for
NMUs is through the changelog. (If this is the intent).
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.
{+After you upload an NMU, you are responsible for the possible
problems that you might have introduced. You must monitor the package
for a few weeks (subscribing to the package on the PTS is a good
idea).+}
While there are no general rules, it's recommended to upload to the
DELAYED queue with a delay of at least a few days. Here are some
examples that you could use as default values:
Since the maintainer has the duty of caring of the NMU even if it does
not come at the best timing, can you add the corresponding duty for the
NMUer to try to contact the maintainer? For instance, one could add:
The use of the DELAYED queue is mandatory when no contact was
established with the maintainer before the upload.
(To mitigate the I'm so busy helping you that I can't talk to you.'
behaviours.)
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)
On Fri, 30 May 2008, Charles Plessy wrote: Are you sure that the BTS can not operate without the changelogs? The BTS needs the changelogs in order to know that the next version is a descendant of the NMU, instead of a descendant of the previous non-NMU, so you either need to include the NMU changelog, or you need to separately close the bugs in your changelog if you don't include it. Don Armstrong -- Clothes make the man. Naked people have little or no influence on society. -- Mark Twain http://www.donarmstrong.com http://rzlab.ucr.edu -- 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 wrote:
On 26/05/08 at 09:55 -0300, Henrique de Moraes Holschuh wrote:
...snip...
I miss one thing in these guidelines: they sort of give you the idea you
can NMU someone's packages off as long as you go by the book, and that
you have the RIGHT to do it no matter what.
I made the following change to the DEP to address this: (wdiff format)
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.
{+After you upload an NMU, you are responsible for the possible
problems that you might have introduced. You must monitor the package
for a few weeks (subscribing to the package on the PTS is a good
idea).+}
While there are no general rules, it's recommended to upload to the
DELAYED queue with a delay of at least a few days. Here are some
examples that you could use as default values:
I have the same concern about this language as I did when I explained
in October (http://lists.debian.org/debian-mentors/2007/10/msg00229.html)
that a person should follow the usual NMU rules. It may be a case where
agree to disagree, but our developers reference clearly states in section
5.11.1 (http://www.debian.org/doc/developers-reference) to contact the
developer first, and act later.
I see the same weakness that Henrique listed above. Some people will
prepare a NMU without even sending an email to the maintainer. They
will claim that this was 'done by the book.' I am not oblivious to what
you (http://lists.debian.org/debian-devel/2007/10/msg00547.html) may
find painful but, I still want to stress that we should strive to improve
communication when we can. You did not find consensus to adopt your
view back then, and I hope you will not use DEP1 to establish your
preference now.
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)
On Mon, May 26, 2008 at 11:56:12AM +0200, Cyril Brulebois wrote: On 26/05/2008, Charles Plessy wrote: It depends on how important are the VCS and package histories for the maintainer and Debian. In order to acknowledge the NMU, it would be necessary to revert the current work, apply the NMU patch, merge the reverted work and resolve the conflicts. It looks to me like the wording of the 3rd paragraph of 5.11.2 is a bit (too) strong: one must include the patch. It might be relaxed a bit so that the maintainer is still allowed to implement the changes the way s/he intends, rather than having to include the very patch sent to the BTS. The proposal is to use the DELAYED queue as the default way to do an NMU. This means in particular that the code is already finished when the mail about the NMU is sent to the BTS. So there is no reason to allow changes to the patch after this mail; if you need them, cancel the NMU and upload an other one instead (sending the new patch to the BTS). Also note that because of the do what you think is right, these are only guidelines-approach, it may be acceptable to cancel an NMU and upload a new one with a very short delay. IMO you shouldn't do that in most cases, but it can happen. Especially if the new patch is almost identical to the previous one. 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)
On Sun, May 25, 2008 at 01:00:55PM +0200, Luk Claes wrote: Bas Wijnen wrote: === nmudiff improvements Can you please just file a bug against devscripts and leave this out of the DEP? No, because: = the nmudiff patch is not controversial. Why include it in the DEP? * If the DEP isn't agreed upon, the patch has no reason to be included in devscripts. It also has no reason to not be included AFAICS. It has. This DEP changes the default way to handle an NMU from announce that you are going to do it, wait, do it to use the DELAYED queue. The new wording depends on the DELAYED queue being used. If the DEP is rejected, using this template doesn't make sense. I agree that even then an improvement should be made, but it should be different from what we propose here. * It gives the opportunity to discuss the formulation at the same time as the rest of the DEP. * DEPs are supposed to allow changes in several parts of Debian at the same time. That's a good test case :-) Ok, though I didn't see much discussion about it... We just started. This is already the third e-mail about it in this thread. ;-) = Is that really the best place to discuss stable, security and QA uploads, and binNMUs? Yes, though the versioning of security uploads will probably be used and decided by the Security Teams and the versioning of stable uploads will probably be used and decided by the Stable Release Team anyway... Though I won't oppose guidelines for the versioning. They're only guidelines, and if those teams don't follow them, well, what can we do? :-) But there are technical reasons for using this scheme (sorting of versions is currently not always right, this is fixed with the proposal), so I'd highly recommend the teams to follow the guidelines. 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)
On 27/05/2008, Bas Wijnen wrote: The proposal is to use the DELAYED queue as the default way to do an NMU. This means in particular that the code is already finished when the mail about the NMU is sent to the BTS. So there is no reason to allow changes to the patch after this mail; if you need them, cancel the NMU and upload an other one instead (sending the new patch to the BTS). I'm talking about ACK'ing a previously-uploaded-and-accepted NMU in a future upload. Quoting Charles: “In order to acknowledge the NMU, it would be necessary to revert the current work, apply the NMU patch, merge the reverted work and resolve the conflicts.” I think I wrote about the 3rd paragraph of 5.11.2, maybe I should have quoted it as well: “When a package has been NMUed, the maintainer should acknowledge it in the next upload. This makes clear that the changes were accepted in the maintainer's packaging, and that they aren't lost again. For this, you MUST first incorporate the changes into your packaging, by applying the patch that was sent. Make sure to include the NMU's changelog entry in your own changelog. This is important to allow the BTS version tracking to work.” [Emphasis on “must” added on purpose, that was meant to be my point.] Mraw, KiBi. pgpeKzf2Qz9vA.pgp Description: PGP signature
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
On Tue, May 27, 2008 at 08:01:27PM +0200, Cyril Brulebois wrote: On 27/05/2008, Bas Wijnen wrote: The proposal is to use the DELAYED queue as the default way to do an NMU. This means in particular that the code is already finished when the mail about the NMU is sent to the BTS. So there is no reason to allow changes to the patch after this mail; if you need them, cancel the NMU and upload an other one instead (sending the new patch to the BTS). I'm talking about ACK'ing a previously-uploaded-and-accepted NMU in a future upload. Oh, sorry, I didn't look up your reference and thought you were talking about including the patch in the BTS. Quoting Charles: “In order to acknowledge the NMU, it would be necessary to revert the current work, apply the NMU patch, merge the reverted work and resolve the conflicts.” I think I wrote about the 3rd paragraph of 5.11.2, maybe I should have quoted it as well: “When a package has been NMUed, the maintainer should acknowledge it in the next upload. This makes clear that the changes were accepted in the maintainer's packaging, and that they aren't lost again. For this, you MUST first incorporate the changes into your packaging, by applying the patch that was sent. Make sure to include the NMU's changelog entry in your own changelog. This is important to allow the BTS version tracking to work.” [Emphasis on “must” added on purpose, that was meant to be my point.] Right. I agree that must is too strong there, but I'd fix it by adding something like as far as you want to keep them. You must indeed keep the changelog entry, and it's good that this is emphasized IMO. 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 [EMAIL PROTECTED] writes: Hi, This is the second call for comments (long overdue) on DEP1. Hi! Please specify the license for the DEP1 text. Is it DFSG free? I suggested earlier [1] that DEP0 should say that all DEP's should be licensed under a DFSG-compatible license. I recall positive comments regarding that, but it doesn't seem DEP0 itself has changed. Thanks, /Simon [1] http://thread.gmane.org/gmane.linux.debian.devel.project/13595/focus=13599 -- 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 | 5.11.1.2 Using the DELAYED/ queue [...] | The DELAYED queue should not be used to put additional pressure on the | maintainer. In particular, it's important that you are available to | cancel or delay the upload before the delay expires (the maintainer | cannot cancel the upload himself). Is there interest in changing this? Currently, each of the N-day/ directories are mode 1777, aka «tfheen and owner of file can remove file». If there's interest in it, I'll be happy to make it so anybody can remove anybody elses uploads. Alternatively, I could have a script that understands dcut commands and only acts if it's signed by the owner of the package (maintainer or uploader). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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 wrote: Hi, Hi === nmudiff improvements Can you please just file a bug against devscripts and leave this out of the DEP? = the nmudiff patch is not controversial. Why include it in the DEP? * If the DEP isn't agreed upon, the patch has no reason to be included in devscripts. It also has no reason to not be included AFAICS. * It gives the opportunity to discuss the formulation at the same time as the rest of the DEP. * DEPs are supposed to allow changes in several parts of Debian at the same time. That's a good test case :-) Ok, though I didn't see much discussion about it... = Is that really the best place to discuss stable, security and QA uploads, and binNMUs? Yes, though the versioning of security uploads will probably be used and decided by the Security Teams and the versioning of stable uploads will probably be used and decided by the Stable Release Team anyway... Though I won't oppose guidelines for the versioning. 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)
On Sun, May 25, 2008 at 11:05:14AM +0200, Tollef Fog Heen wrote: * Bas Wijnen | 5.11.1.2 Using the DELAYED/ queue [...] | The DELAYED queue should not be used to put additional pressure on the | maintainer. In particular, it's important that you are available to | cancel or delay the upload before the delay expires (the maintainer | cannot cancel the upload himself). Is there interest in changing this? Currently, each of the N-day/ directories are mode 1777, aka «tfheen and owner of file can remove file». If there's interest in it, I'll be happy to make it so anybody can remove anybody elses uploads. I think that would be better, indeed. Alternatively, I could have a script that understands dcut commands and only acts if it's signed by the owner of the package (maintainer or uploader). Actually, anybody at all (DD only, that is) is better than owner only IMO. When it's about NMUs, we're in a situation where external help is more than a theoretical possibility. If some other external help wants to fix a problem with an NMU which is still in the queue, this should be possible IMO. Of course all parties (maintainer and previous NMUer) should be informed, but that need not be automatic. If this is changed, we should write a paragraph about how and when to do this in the DEP as well. Thanks, Bas Ps: This e-mail expresses my personal opinion, and is not written with my driver of this DEP hat on. :-) -- 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)
Hi Bas, and Lucas, Le Sun, May 25, 2008 at 08:50:45AM +0200, Bas Wijnen a écrit : In some cases, the maintainer might allow direct commit to the package's VCS repository. We felt that it was not a good idea to include this in the DEP, because: Actually, this leaves open the question whether the diff of the NMU should be done against the current package in the Debian archive or the work in progress in the maintainers VCS repository). One is clearer to the users, and one is more useful for the maintainers. Which one do you recommend? Have a nice day, -- Charles Plessy, Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
