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]
The giving some time to the maintainer rule
On 30/05/08 at 18:24 -0700, Steve Langasek wrote: On Fri, May 30, 2008 at 11:49:14AM +0200, Lucas Nussbaum wrote: Now, what we don't agree on: - I think that giving some time should only be very strongly recommended, but not mandatory. - You think that giving some time should be mandatory. I think that our opinions are basically the same. The difference is that you want to write something in stone, while I prefer not to impose rules where it's not necessary, because: This is begging the question. Experience tells me that the sort of rules under discussion *are* necessary. You are still talking about the rule The maintainer *MUST* give some time to react before uploading the NMU, right? - If you make it mandatory, then you have to provide a workaround for cases where it's just not possible to wait. And you also have to list those cases. And, so? That's what we have today. What's the problem with this that you're trying to fix? No, that's not what we have today. What we have today is the release team deciding that it has authority to change the NMU rules, to allow 0-day NMUs for bugs older than 7 days old. - Does the RT really have authority ? - 0-day means no need to give some time to the maintainer. You uploaded a lot of such NMUs yourself, sometimes on packages with an active maintainer, without even providing a patch on the BTS previously. You realize that this discussion about the NMUers must give some time to the maintainer-rule also affects the current 0-day NMU policy? One of the goals of the DEP is to make the 0-day NMU policy useless, by generalizing it to all bugs (with delay 0 and delay a function of the severity of bugs being fixed). Now, there are two patches to the DEP that try to address the current wording. See [EMAIL PROTECTED] and [EMAIL PROTECTED]. I would really appreciate comments on those patches. That would be a lot more useful than general discussions about rules. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEP1: Clarifying policies and workflows for Non Maintainer?Uploads (NMUs)
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: The giving some time to the maintainer rule
Lucas Nussbaum wrote: On 30/05/08 at 18:24 -0700, Steve Langasek wrote: On Fri, May 30, 2008 at 11:49:14AM +0200, Lucas Nussbaum wrote: Now, what we don't agree on: - I think that giving some time should only be very strongly recommended, but not mandatory. - You think that giving some time should be mandatory. I think that our opinions are basically the same. The difference is that you want to write something in stone, while I prefer not to impose rules where it's not necessary, because: This is begging the question. Experience tells me that the sort of rules under discussion *are* necessary. You are still talking about the rule The maintainer *MUST* give some time to react before uploading the NMU, right? - If you make it mandatory, then you have to provide a workaround for cases where it's just not possible to wait. And you also have to list those cases. And, so? That's what we have today. What's the problem with this that you're trying to fix? No, that's not what we have today. What we have today is the release team deciding that it has authority to change the NMU rules, to allow 0-day NMUs for bugs older than 7 days old. - Does the RT really have authority ? According to the Developer's Reference at least the release manager has... - 0-day means no need to give some time to the maintainer. Wrong: 0-day means no need to give the maintainer *extra* time You uploaded a lot of such NMUs yourself, sometimes on packages with an active maintainer, without even providing a patch on the BTS previously. Only where the maintainer didn't react yet in the time (mostly about 7 days) given... You realize that this discussion about the NMUers must give some time to the maintainer-rule also affects the current 0-day NMU policy? It does already... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEP1: how to do an NMU
Le Sat, May 31, 2008 at 12:20:55PM +0200, Lucas Nussbaum a écrit : Unless you have an excellent reason not to do so, you must then give some time to the maintainer to react Hi Lucas, excellence is definitely what we should aim for :) Thank you for your efforts. Here are my last comments on the DEP: 5.11.1 When and how to do an NMU I propose to add NMUs are usually not appropriate for team-maintained packages. Consider sending a patch to the BTS instead. to the bullet list. 5.11.1.2 Using the DELAYED/ queue I propose to ask a paragraph saying: If you do not make your NMU to DELAYED/, you must document your reasons in the BTS. I and others had NMUs on non-RC bugs on team-maintained packages while being active and we are still left to wonder what in our packaging practice was so wrong that it had to be fixed in emergency. Having the reason written in the BTS would help us to improve ourselves. 5.11.2 NMUs, from the maintainer's point of view The last two sentences, Make sure to include the NMU's changelog entry (not just the line describing the changes) in your own changelog. This is important to allow the ¥BTS version tracking to work., are misleading on how the BTS work, as they suggest that the version tracking depends on the changelog. Maybe they could be changed to: Make sure to include the NMU's changelog entry (not just the line describing the changes) in your own changelog if you want to take advantage of the automatic BTS version tracking. I think that both sides made enough efforts, so please do not take this mail as a list of requirements, alhtough of course I would prefer my points being taken into account. I am moving into a place where internet is not yet set up, so do not expect timely answers. Please go ahead :) Have a nice week-end, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan (for the last day !) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEP1: how to do an NMU
On 01/06/08 at 00:22 +0900, Charles Plessy wrote: Le Sat, May 31, 2008 at 12:20:55PM +0200, Lucas Nussbaum a écrit : Unless you have an excellent reason not to do so, you must then give some time to the maintainer to react Hi Lucas, excellence is definitely what we should aim for :) Thank you for your efforts. Here are my last comments on the DEP: 5.11.1 When and how to do an NMU I propose to add NMUs are usually not appropriate for team-maintained packages. Consider sending a patch to the BTS instead. to the bullet list. It really depends on the team. There are small teams where all members might become unresponsive at the same time. I don't think that we should special-case this. 5.11.1.2 Using the DELAYED/ queue I propose to ask a paragraph saying: If you do not make your NMU to DELAYED/, you must document your reasons in the BTS. I and others had NMUs on non-RC bugs on team-maintained packages while being active and we are still left to wonder what in our packaging practice was so wrong that it had to be fixed in emergency. Having the reason written in the BTS would help us to improve ourselves. Can you give a specific example where this happened? Did you raise the subject on [EMAIL PROTECTED] Have you asked the NMUer why he did that? I think that the DEP should reduce this risk. Actually, with the 0-day NMU policy on RC and RG 7 days old, it's currently perfectly allowed to NMU a team-maintained package for an RG bug without prior contact with the maintainer. I don't think that it's a good policy in many cases (like the one you describe), and it's one of my motivations for this DEP. Even if this DEP is accepted, it doesn't mean that we can't come back to this discussion in a few months, and reconsider some things. I would prefer to keep the current wording for now, and re-discuss this later, if this proves to be an issue with the current wording. 5.11.2 NMUs, from the maintainer's point of view The last two sentences, Make sure to include the NMU's changelog entry (not just the line describing the changes) in your own changelog. This is important to allow the ¥BTS version tracking to work., are misleading on how the BTS work, as they suggest that the version tracking depends on the changelog. Maybe they could be changed to: Well, that's the case, see http://lists.debian.org/debian-project/2008/05/msg00074.html Make sure to include the NMU's changelog entry (not just the line describing the changes) in your own changelog if you want to take advantage of the automatic BTS version tracking. I'll change that to: Make sure to include the NMU's changelog entry (not just the line describing the changes) in your own changelog, to allow the automatic BTS version tracking to work. I think that both sides made enough efforts, so please do not take this mail as a list of requirements, alhtough of course I would prefer my points being taken into account. I am moving into a place where internet is not yet set up, so do not expect timely answers. Please go ahead :) Have fun :) -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEP1: how to do an NMU
On Saturday 31 May 2008, Lucas Nussbaum wrote: I propose to add NMUs are usually not appropriate for team-maintained packages. Consider sending a patch to the BTS instead. to the bullet list. It really depends on the team. There are small teams where all members might become unresponsive at the same time. I don't think that we should special-case this. Yes, it probably does depend on the team. But several people have raised this point now, which probably means that it _is_ a real concern. When are you (the proposers of this DEP) going to start listening to your peers instead of dismissing their concerns? A lot of packages are team-maintained not only because it is more fun to work together, but also because those packages (or groups of packages) are more complex, or have interactions that may not be obvious at first glance. Which means that there may well be a bigger likelyhood that an NMU will break things. All members of a team becoming unresponsive is possible, agreed. But it is a hell of a lot less likely than at least one member of the team being able to respond to urgently needed changes if appropriately notified. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: DEP1: how to do an NMU
Frans Pop wrote: On Saturday 31 May 2008, Lucas Nussbaum wrote: I propose to add NMUs are usually not appropriate for team-maintained packages. Consider sending a patch to the BTS instead. to the bullet list. It really depends on the team. There are small teams where all members might become unresponsive at the same time. I don't think that we should special-case this. Yes, it probably does depend on the team. But several people have raised this point now, which probably means that it _is_ a real concern. When are you (the proposers of this DEP) going to start listening to your peers instead of dismissing their concerns? A lot of packages are team-maintained not only because it is more fun to work together, but also because those packages (or groups of packages) are more complex, or have interactions that may not be obvious at first glance. Which means that there may well be a bigger likelyhood that an NMU will break things. All members of a team becoming unresponsive is possible, agreed. But it is a hell of a lot less likely than at least one member of the team being able to respond to urgently needed changes if appropriately notified. So, why should there be any special treatment as they are more likely to respond early anyway? Or are you questioning normal NMU intents, RC/RG bugs and d-d-a announcements as appropriate notifications? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEP1: how to do an NMU
On Saturday 31 May 2008, Luk Claes wrote: All members of a team becoming unresponsive is possible, agreed. But it is a hell of a lot less likely than at least one member of the team being able to respond to urgently needed changes if appropriately notified. So, why should there be any special treatment as they are more likely to respond early anyway? Or are you questioning normal NMU intents, RC/RG bugs and d-d-a announcements as appropriate notifications? Because bugs may also have been (or seem to have been overlooked). The risk here is that the person doing the NMU thinks oh, that's an old issue and the fix seems so simple and goes ahead and NMUs it, while there may be very valid reasons for not fixing it (or at least not with _that_ fix). A follow-up to the bug report with just hey, this issue seems to be forgotten, could someone please take another look as it seems important would then be a lot more appropriate and take a lot less time all around then preparing the patch, uploading it to delayed and then getting to hear sorry, this is not good, please remove your NMU from the queue. Large teams also often have large numbers of issues to deal with. Which does mean that (unfortunately) issues may be missed or forgotten about. Or maybe it is something that is normally taken care of by one particular team member and other team members ignored the issue for that reason but are capable of picking it up if prompted to do so. There is just no reason to bypass the maintainers if they are otherwise active. In such cases just talking to the maintainers (through the BTS or otherwise) is just a lot more appropriate and effective, at least as a first step, than going straight to an NMU - even with the safeguards incorporated in the DEP. signature.asc Description: This is a digitally signed message part.
Re: DEP1: how to do an NMU
On 31/05/08 at 18:44 +0200, Frans Pop wrote: On Saturday 31 May 2008, Lucas Nussbaum wrote: I propose to add NMUs are usually not appropriate for team-maintained packages. Consider sending a patch to the BTS instead. to the bullet list. It really depends on the team. There are small teams where all members might become unresponsive at the same time. I don't think that we should special-case this. Yes, it probably does depend on the team. But several people have raised this point now, which probably means that it _is_ a real concern. So far, you (in [EMAIL PROTECTED] and [EMAIL PROTECTED]) and Charles Plessy ([EMAIL PROTECTED], [EMAIL PROTECTED]) raised that concern. On the other hand, Bas Wijnen ([EMAIL PROTECTED]) and I disagreed that a special consideration was needed. We can't just blindly add every suggestion that people propose, because that would make other people unhappy. I am opposed to forbidding NMUs, or requiring prior ack from the maintainer, for some categories of maintainers. If we start listing such categories, we will end up with something like: - teams with at least one very active/responsive member, or two active/resposnive members - very active/responsive DDs, unless they are in VAC for more than n days That will be totally a PITA to check, and very error-prone. (how do you measure activity and responsiveness?) Instead, I'm totally open to emphasizing the fact that if the package is maintained by a team or by a known-active DD, the NMUer should really try harder to contact the maintainers before proceeding with the NMU. Phil Hands proposed something in [EMAIL PROTECTED]: Clearly there are cases where NMUs are inappropriate. The DEP is currently missing language to make that point clear (at least in my reading of it) perhaps it needs a final clause along the lines of: This is not a license to perform NMUs thoughtlessly. If you NMU when it is clear that the maintainers are active and would have acknowledged a patch in a more timely manner, or if you ignore the recommendations of this DEP, or if you do something else that assumes that this is an NMUers charter and that a lawyerly interpretation of some subclause can be used to justify some abusive action, be warned, there is no protection for you here. You should always be prepared to defend the wisdom of any NMU you perform on its own merits. Frans, would adding that paragraph solve your concerns, or can you suggest a patch to this paragraph that would solve them? are you (the proposers of this DEP) going to start listening to your peers instead of dismissing their concerns? If you started to propose wordings that would suit you, instead of waiting for us to propose stuff by mind-reading, that would be a lot easier to listen to you. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
Re: DEP1: how to do an NMU
Frans Pop wrote: On Saturday 31 May 2008, Luk Claes wrote: All members of a team becoming unresponsive is possible, agreed. But it is a hell of a lot less likely than at least one member of the team being able to respond to urgently needed changes if appropriately notified. So, why should there be any special treatment as they are more likely to respond early anyway? Or are you questioning normal NMU intents, RC/RG bugs and d-d-a announcements as appropriate notifications? Because bugs may also have been (or seem to have been overlooked). The risk here is that the person doing the NMU thinks oh, that's an old issue and the fix seems so simple and goes ahead and NMUs it, while there may be very valid reasons for not fixing it (or at least not with _that_ fix). A follow-up to the bug report with just hey, this issue seems to be forgotten, could someone please take another look as it seems important would then be a lot more appropriate and take a lot less time all around then preparing the patch, uploading it to delayed and then getting to hear sorry, this is not good, please remove your NMU from the queue. Large teams also often have large numbers of issues to deal with. Which does mean that (unfortunately) issues may be missed or forgotten about. Or maybe it is something that is normally taken care of by one particular team member and other team members ignored the issue for that reason but are capable of picking it up if prompted to do so. There is just no reason to bypass the maintainers if they are otherwise active. In such cases just talking to the maintainers (through the BTS or otherwise) is just a lot more appropriate and effective, at least as a first step, than going straight to an NMU - even with the safeguards incorporated in the DEP. Ok, though I'd rather have a (strong) recommendation to prod maintainers (in a team or not), then to special case teams... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEP1: how to do an NMU
On Sat, 31 May 2008 12:20:55 +0200, Lucas Nussbaum [EMAIL PROTECTED] said: Steve, Manoj, Charles, Richard, does this address your concerns? If not, can you propose some additional changes? This new version does sound a lot better. manoj -- If voting could really change things, it would be illegal. Revolution Books. New York, New York. Manoj Srivastava [EMAIL PROTECTED] 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 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: how to do an NMU
On Saturday 31 May 2008, Lucas Nussbaum wrote: * Have you clearly expressed your intention to NMU, at least on the BTS? Has the maintainer been notified of it? It is also a good idea to try to contact the maintainer by other means (private email, IRC) IMO private mail is the wrong way to do this if the intention to NMU has already been registered in the BTS. Maintainers can be expected to read BTS mails for their packages [1]. Sending a private mail is not something I would ever do I think. A final attempt to ping on IRC can be appropriate in some cases. Cheers, FJP [1] With one exception: mails with large attachments may be accepted by the BTS, but not reach the maintainer. For example, lists.d.o has a size limit, while bugs.d.o does not (#475682). signature.asc Description: This is a digitally signed message part.
Re: DEP1: how to do an NMU
On Saturday 31 May 2008, Luk Claes wrote: Ok, though I'd rather have a (strong) recommendation to prod maintainers (in a team or not), then to special case teams... Sure. For me it is not necessarily about teams, but more about active: likely to respond and take care of urgent issues him/her/themselves when prodded, thus making an NMU unnecessary. Basically I and several others have been asking to add something that effectively (and more explicitly than in the current proposal) says: Please consider before you NMU if just contacting the maintainer isn't likely to more effective than doing an NMU. In general it should be considered preferable that a maintainer takes care of an issue himself and that he is given the chance to review and correct your patch, because he can be expected to be more aware of corner cases and complex interactions, things that an NMUer might miss. Something like this could be added in the intro of 5.11. It is somewhat similar in intend to the text proposed by Philip Hands. Teams is for me just a case where you can reasonably expect NMUers to seriously consider that option, a bit more so than with solo maintainers (generally speaking). IMO people who do NMUs are mostly also people who _are_ aware of who (individual and teams) is active/responsive and who is not, so I would be very surprised if this is not the actual practice with people who already are active doing more than just an occasional NMU. NMUs should remain a fallback if maintainers really fail to respond to issues. Maintainers should also continue to be allowed to set priorities for their packages. NMUs force maintainers to change their priorities as they will *have* to deal with the NMU (either reject it or incorporate it) before they can resume work on other issues. I am not against NMUs, and also not against the DEP, but I would like to have made clear that there are cases where NMUs are just not the appropriate way to fix a pet issue, especially not for anything below RC. Categories for which I _do_ believe NMUs are appropriate: - really urgent, or important and obviously safe issues (see example acked by Frank Küster in [EMAIL PROTECTED]) - changes needed for larger transitions or release goals where maintainers are failing to respond to repeated signals to do something - RC issues that affect users (excluding e.g. licence issues); I have no problems with the current practice for those - and possibly a few more The DEP should not be a licence to avoid entering into a discussion with the maintainer of a package, or to pre-empt him. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: DEP1: how to do an NMU
On Saturday 31 May 2008, Lucas Nussbaum wrote: So far, you (in [EMAIL PROTECTED] and [EMAIL PROTECTED]) and Charles Plessy ([EMAIL PROTECTED], [EMAIL PROTECTED]) raised that concern. Sure, but Steve Langasek, Manoj and Frank Küster have been voicing what are basically the same concerns. On the other hand, Bas Wijnen ([EMAIL PROTECTED]) and I disagreed that a special consideration was needed. We can't just blindly add every suggestion that people propose, because that would make other people unhappy. Problem is you did not at the same time acknowledge that the concerns themselves could be valid and that you were willing to discuss them further and thus come to a different solution. This mail does do that. I am opposed to forbidding NMUs, or requiring prior ack from the maintainer, for some categories of maintainers. If we start listing such categories, we will end up with something like: - teams with at least one very active/responsive member, or two active/resposnive members - very active/responsive DDs, unless they are in VAC for more than n days That will be totally a PITA to check, and very error-prone. (how do you measure activity and responsiveness?) Fine. I'm only providing examples of cases where I feel NMUs are in general not appropriate. A more general rule would be fine with me, as long as it does cover the particular case in some way. Instead, I'm totally open to emphasizing the fact that if the package is maintained by a team or by a known-active DD, the NMUer should really try harder to contact the maintainers before proceeding with the NMU. Cool. Phil Hands proposed something in [EMAIL PROTECTED]: Clearly there are cases where NMUs are inappropriate. The DEP is currently missing language to make that point clear (at least in my reading of it) perhaps it needs a final clause along the lines of: This is not a license to perform NMUs thoughtlessly. If you NMU when it is clear that the maintainers are active and would have acknowledged a patch in a more timely manner, or if you ignore the recommendations of this DEP, or if you do something else that assumes that this is an NMUers charter and that a lawyerly interpretation of some subclause can be used to justify some abusive action, be warned, there is no protection for you here. You should always be prepared to defend the wisdom of any NMU you perform on its own merits. Frans, would adding that paragraph solve your concerns, or can you suggest a patch to this paragraph that would solve them? I think that mentioning in some way that you should be prepared to defend a decision to NMU would be very good. The lawyerly interpretation of some subclause phrase is probably a bit too much :-) See my second reply to Luk for a more concrete proposal, but I'd be happy to see the be prepared to defend bit added to that in some way. If you started to propose wordings that would suit you, instead of waiting for us to propose stuff by mind-reading, that would be a lot easier to listen to you. The thing is that I basically agreed with suggestions (or at least with the intentions behind them) from others which were waved away. That is not very motivating for writing other proposals. IMO you first have to reach agreement on the principle you want to put into words when there is such a clear difference; proposing variations on the same text is only going to lead to frustration. That is why I started presenting use cases in which I feel NMUs to be less appropriate (and explaining my reasons in more detail). Anyway, my reply to Luk contains a fairly concrete proposed text. From my perspective its your (plural) job as proposers/editors of the DEP to put things together though. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: The giving some time to the maintainer rule
On Sat, May 31, 2008 at 08:55:37AM +0200, Lucas Nussbaum wrote: On 30/05/08 at 18:24 -0700, Steve Langasek wrote: On Fri, May 30, 2008 at 11:49:14AM +0200, Lucas Nussbaum wrote: Now, what we don't agree on: - I think that giving some time should only be very strongly recommended, but not mandatory. - You think that giving some time should be mandatory. I think that our opinions are basically the same. The difference is that you want to write something in stone, while I prefer not to impose rules where it's not necessary, because: This is begging the question. Experience tells me that the sort of rules under discussion *are* necessary. You are still talking about the rule The maintainer *MUST* give some time to react before uploading the NMU, right? And rules about when this should not be required. And, so? That's what we have today. What's the problem with this that you're trying to fix? No, that's not what we have today. What we have today is the release team deciding that it has authority to change the NMU rules, to allow 0-day NMUs for bugs older than 7 days old. - Does the RT really have authority ? - 0-day means no need to give some time to the maintainer. So you want to replace it with people who can edit the developers-reference deciding that they have the authority to change the NMU rules? The developer's reference is non-normative. It lacks either a constitutional charter for the change process, or constitutionally-delegated stewards. And it contains lots of recommendations that are one person's idea about how things should work. The current devref NMU policy is IMHO one of the better recommendations in that document. But I also believe it carries weight more because it encodes the community tradition than because the devref itself has power to determine such policies. As for the release team setting policies, Anthony Towns pointed out a couple of years ago, in a message I can't now put my finger on, that ultimately it's the ftp masters who decide who's able to upload packages to the archive or not, NMUs or otherwise. Given that this was in a discussion about 0-day NMUs, I think that also amounts to tacit approval by the ftpmasters of the RM-endorsed NMU policies. You uploaded a lot of such NMUs yourself, sometimes on packages with an active maintainer, without even providing a patch on the BTS previously. Er, barring mailer errors, in all cases my NMUs included a patch and declaration of intent-to-NMU sent to the BTS before my NMUs were uploaded. In the case of NMUs fixing only RC bugs, sometimes the time between the two events was 5 minutes, but in all cases it was intended to be consistent with the NMU policies (including 0-day NMU policies) in force at the time. You realize that this discussion about the NMUers must give some time to the maintainer-rule also affects the current 0-day NMU policy? ... only if you accept the premise that all NMUs should be covered by a single rule without exception, which I do not? One of the goals of the DEP is to make the 0-day NMU policy useless, by generalizing it to all bugs (with delay 0 and delay a function of the severity of bugs being fixed). Right; I think this is a false generalization because of the negative side-effects. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEP1: how to do an NMU
On 31/05/08 at 20:41 +0200, Frans Pop wrote: On Saturday 31 May 2008, Lucas Nussbaum wrote: * Have you clearly expressed your intention to NMU, at least on the BTS? Has the maintainer been notified of it? It is also a good idea to try to contact the maintainer by other means (private email, IRC) IMO private mail is the wrong way to do this if the intention to NMU has already been registered in the BTS. Maintainers can be expected to read BTS mails for their packages [1]. Sending a private mail is not something I would ever do I think. I agree with you, but several people mentioned that it would be nice to try to contact the maintainer directly. This change was a I don't really care, let's make those people happy-change. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEP1: how to do an NMU
On 31/05/08 at 21:33 +0200, Frans Pop wrote: On Saturday 31 May 2008, Lucas Nussbaum wrote: So far, you (in [EMAIL PROTECTED] and [EMAIL PROTECTED]) and Charles Plessy ([EMAIL PROTECTED], [EMAIL PROTECTED]) raised that concern. Sure, but Steve Langasek, Manoj and Frank Küster have been voicing what are basically the same concerns. One problem with such discussions is that it's easy to misread people's mails, and attribute to them opinions that they don't have. The only mail from Frank Küster is [EMAIL PROTECTED], and he doesn't really say anything about that topic. Same with Manoj and Steve: they raised concerns, but not about excluding team-maintained or actively-maintained packages. (I might have missed a mail while rescanning the thread, of course) On the other hand, Bas Wijnen ([EMAIL PROTECTED]) and I disagreed that a special consideration was needed. We can't just blindly add every suggestion that people propose, because that would make other people unhappy. Problem is you did not at the same time acknowledge that the concerns themselves could be valid and that you were willing to discuss them further and thus come to a different solution. This mail does do that. Every concern is worth listening to, and we made several changes to the DEP since the beginning of this discussion because of concerns that were raised. But it's not black and white, especially with a topic where different people might have had totally different experiences. [...] If you started to propose wordings that would suit you, instead of waiting for us to propose stuff by mind-reading, that would be a lot easier to listen to you. The thing is that I basically agreed with suggestions (or at least with the intentions behind them) from others which were waved away. That is not very motivating for writing other proposals. IMO you first have to reach agreement on the principle you want to put into words when there is such a clear difference; proposing variations on the same text is only going to lead to frustration. That is why I started presenting use cases in which I feel NMUs to be less appropriate (and explaining my reasons in more detail). Discussing ideas and principles is a lot harder than discussing concrete proposals. Also, when listing use cases, it's difficult for an outsider to understand the underlying problem, and to generalize, which is necessary before something can be put into dev-ref. From my perspective its your (plural) job as proposers/editors of the DEP to put things together though. Sure. I'm not asking for perfect patches. But the I'd like to see something like that in the DEP: emails are a lot easier to answer than those discussing ideas and principles, where it's difficult to determine what the poster would exactly want to see changed. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
Re: DEP1: how to do an NMU
On 31/05/08 at 21:02 +0200, Frans Pop wrote: On Saturday 31 May 2008, Luk Claes wrote: Ok, though I'd rather have a (strong) recommendation to prod maintainers (in a team or not), then to special case teams... Sure. For me it is not necessarily about teams, but more about active: likely to respond and take care of urgent issues him/her/themselves when prodded, thus making an NMU unnecessary. Basically I and several others have been asking to add something that effectively (and more explicitly than in the current proposal) says: Please consider before you NMU if just contacting the maintainer isn't likely to more effective than doing an NMU. In general it should be considered preferable that a maintainer takes care of an issue himself and that he is given the chance to review and correct your patch, because he can be expected to be more aware of corner cases and complex interactions, things that an NMUer might miss. Something like this could be added in the intro of 5.11. It is somewhat similar in intend to the text proposed by Philip Hands. I'm not sure that it is so similar to Philip's proposal. I have integrated your proposal in the questions at the beginning of 5.11.1, and added Philip's at the end of 5.11.1. (both are modified a bit, but I think that the general meaning is not changed) NMUs should remain a fallback if maintainers really fail to respond to issues. Maintainers should also continue to be allowed to set priorities for their packages. NMUs force maintainers to change their priorities as they will *have* to deal with the NMU (either reject it or incorporate it) before they can resume work on other issues. I also stressed that in the intro, and removed the second paragraph of the intro, which didn't really add any value. Here is the diff. Feel free to propose further improvements (I still have to discuss those changes with Bas, too): --- 5.11.1.orig 2008-05-31 22:48:35.0 +0200 +++ 5.11.1 2008-05-31 22:50:25.0 +0200 @@ -1,19 +1,14 @@ Proposed section 5.11: Non-Maintainer Uploads (NMUs) Every package has one or more maintainers. Normally, these are the people who work on and upload new versions of the package. In some situations, it is useful that other developers can upload a new version as well, for example if they want to fix a bug in a package -they don't maintain. Such uploads are called Non-Maintainer Uploads -(NMU). - -NMUs can happen for various reasons, the most usual one being to -fix bugs. There are some rules to follow when doing an NMU. These -are explained below. An NMU is allowed for any reason, as long as -those rules are followed. +they don't maintain, when the maintainer fails to respond to issues. +Such uploads are called Non-Maintainer Uploads (NMU). 5.11.1 When and how to do an NMU Before doing an NMU, consider the following questions: * Do you really fix bugs in your NMU? Fixing cosmetic issues, or @@ -31,12 +26,17 @@ seek advice from others. Remember that if you break something in your NMU, many people will be very unhappy about it. * Have you clearly expressed your intention to NMU, at least on the BTS? Has the maintainer been notified of it? It is also a good idea to try to contact the maintainer by other means (private email, IRC) +* If the maintainer is usually active and responsive, have you + tried to contact him? In general it should be considered preferable + that a maintainer takes care of an issue himself and that he is + given the chance to review and correct your patch, because he can + be expected to be more aware of things that an NMUer might miss. When doing an NMU, you must first make sure that your intention to NMU is really clear. Then, you must send a patch with the differences between the current package and your proposed NMU to the BTS. Unless you have an excellent reason not to do so, you must then give some @@ -59,6 +59,13 @@ especially if the patch wasn't available on the BTS before, or if you know that the maintainer is generally active. After you upload an NMU, you are responsible for the possible problems that you might have introduced. You must keep an eye on the package (subscribing to the package on the PTS is a good idea). + +This is not a license to perform NMUs thoughtlessly. If you NMU when +it is clear that the maintainers are active and would have acknowledged +a patch in a more timely manner, or if you ignore the recommendations of +this document, be warned, there is no protection for you here. You should +always be prepared to defend the wisdom of any NMU you perform on its +own merits. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
Re: DEP1: how to do an NMU
On Saturday 31 May 2008, Lucas Nussbaum wrote: I also stressed that in the intro, and removed the second paragraph of the intro, which didn't really add any value. Agreed. + * If the maintainer is usually active and responsive, have you + tried to contact him? In general it should be considered preferable + that a maintainer takes care of an issue himself and that he is + given the chance to review and correct your patch, because he can + be expected to be more aware of things that an NMUer might miss. things is a bit vague: s/things that an NMUer might miss/potential issues which an NMUer might miss/ +This is not a license to perform NMUs thoughtlessly. If you NMU when +it is clear that the maintainers are active and would have acknowledged +a patch in a more timely manner, or if you ignore the recommendations of +this document, be warned, there is no protection for you here. You should +always be prepared to defend the wisdom of any NMU you perform on its +own merits. s/more timely/timely/ The more does not really refer back to anything. Thanks. For me this is a definite improvement. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Misc development news (#8)
Mail-Followup-To: [EMAIL PROTECTED] (Heh, eew) On Fri, May 30, 2008 at 08:52:02PM +0200, Raphael Hertzog wrote: The news are collected on http://wiki.debian.org/DeveloperNews Feel free to contribute. ~/.ssh/authorized_keys will remain disabled by default -- Peter Palfrader announced on debian-infrastructure-announce[1] that DSA will not reenable the usage of ~/.ssh/authorized_keys. One should use the official LDAP infrastructure[2] to setup key-based SSH connection to debian.org machines. There's an exception however, quoting Peter: Should you need keys only on specific hosts for automated tasks like updating stuff or syncing files between project machines or similar we can enable a user editable authorized_keys file for specific users on specific hosts. Usually we would expect those keys to be limited to use only from certain hosts (using from=xyz) and limited to allow execution of only certain commands (using command=foobar). Contact DSA if you have such a case. I think this is a great example of why announcements like this should be sent to debian-devel-announce in the first place, instead of being relegated to the debian-infrastructure-announce list that most developers aren't subscribed to. - it's going to end up on d-d-a anyway because it's of sufficiently general concern that someone will forward it there - d-d-a is the list that all developers are supposed to be subscribed to, which means that's the list where announcements of general interest *should* go. Peter, please don't fragment our news feeds in this manner. At least provide this kind of information on *both* announcement lists, instead of hiding it only on the infrastructure-announce list among other messages that don't generally affect developers. This is information that does need to go to /all/ developers, not just to the infrastructure-announce list, because it's not just a maintenance notification - it's a policy change that affects how all developers interact with the project resources. Also, could someone please elaborate on what: The use of ~user/.ssh/authorized_keys files has been disabled since DSA1571 was announced. While our initial plan was to allow them again eventually some bad experience with DDs' key handling has led us to reconsider that intent. ... that means? What bad key handling was seen that warrants such a policy change? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DEP1: how to do an NMU
On Sat, May 31, 2008 at 07:18:14PM +0200, Frans Pop wrote: Because bugs may also have been (or seem to have been overlooked). The risk here is that the person doing the NMU thinks oh, that's an old issue and the fix seems so simple and goes ahead and NMUs it, while there may be very valid reasons for not fixing it (or at least not with _that_ fix). Then they should have been mentioned in the bug log, shouldn't they? ... and IME they usually *are* for active teams, so I'm not sure I can buy your argument. I rather conclude that active teams won't risk anything with the procedure which is being proposed, while not active teams will see NMUs, as they should. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: Misc development news (#8)
[EMAIL PROTECTED] dropped] On Sat, 31 May 2008, Steve Langasek wrote: I think this is a great example of why announcements like this should be sent to debian-devel-announce in the first place, instead of being relegated to the debian-infrastructure-announce list that most developers aren't subscribed to. - d-d-a is the list that all developers are supposed to be subscribed to, which means that's the list where announcements of general interest *should* go. It's not development related tho. And most people really don't need to know it. I suppose etc/motd will eventually be updated to point to it also. This is information that does need to go to /all/ developers, not just to the infrastructure-announce list Well, you can't please all of them. Frankly, I think most of the posts to d-d-a have no place on that list in the first place. If it's the list DD are required to subscribe to we should try to also send stuff there that they *read*. I hardly read all of the posts sent there. What's the number of affected DDs here? 10? 20? I think dia was the appropriate for that mail. The pointer in buxy's mail was also fine, tho I wouldn't have placed it quite as prominently. The use of ~user/.ssh/authorized_keys files has been disabled since DSA1571 was announced. While our initial plan was to allow them again eventually some bad experience with DDs' key handling has led us to reconsider that intent. ... that means? What bad key handling was seen that warrants such a policy change? People submitting known bad keys to ldap and stuffing those in their authorized_keys files also. What else did you think it meant? -- weasel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
