DEP1: how to do an NMU
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 | Next > |
 |
DEP1: how to do an NMU
by Lucas Nussbaum
::
Rate this Message:
|
|
|
Re: DEP1: how to do an NMU
by Charles Plessy-12
::
Rate this Message:
|
|
|
Re: DEP1: how to do an NMU
by Lucas Nussbaum
::
Rate this Message:
|
|
|
Re: DEP1: how to do an NMU
by Frans Pop-3
::
Rate this Message:
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 |
|
|
Re: DEP1: how to do an NMU
by Luk Claes
::
Rate this Message:
|
|
|
Re: DEP1: how to do an NMU
by Frans Pop-3
::
Rate this Message:
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. |
|
|
Re: DEP1: how to do an NMU
by Lucas Nussbaum
::
Rate this Message:
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. <200805301718.06394.elendil@...>) and Charles Plessy (<20080530100316.GD4794@...>, <20080531152214.GA8808@...>) raised that concern. On the other hand, Bas Wijnen (<20080530101631.GA15849@...>) 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 <20080531101718.GE17257@...>: > 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. 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 | lucas@... http://www.lucas-nussbaum.net/ | | jabber: lucas@... GPG: 1024D/023B3F4F | |
|
|
Re: DEP1: how to do an NMU
by Luk Claes
::
Rate this Message:
|
|
|
Re: DEP1: how to do an NMU
by Manoj Srivastava
::
Rate this Message:
|
|
|
Re: DEP1: how to do an NMU
by Frans Pop-3
::
Rate this Message:
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). |
|
|
Re: DEP1: how to do an NMU
by Frans Pop-3
::
Rate this Message:
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 <87ej7ide0q.fsf@...>) - 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 |
|
|
Re: DEP1: how to do an NMU
by Frans Pop-3
::
Rate this Message:
On Saturday 31 May 2008, Lucas Nussbaum wrote:
> So far, you (in <200805301141.02910.elendil@...> and > <200805301718.06394.elendil@...>) and Charles Plessy > (<20080530100316.GD4794@...>, > <20080531152214.GA8808@...>) 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 > (<20080530101631.GA15849@...>) 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 <20080531101718.GE17257@...>: > > 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? 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 |
|
|
Re: DEP1: how to do an NMU
by Lucas Nussbaum
::
Rate this Message:
|
|
|
Re: DEP1: how to do an NMU
by Lucas Nussbaum
::
Rate this Message:
On 31/05/08 at 21:33 +0200, Frans Pop wrote:
> On Saturday 31 May 2008, Lucas Nussbaum wrote: > > So far, you (in <200805301141.02910.elendil@...> and > > <200805301718.06394.elendil@...>) and Charles Plessy > > (<20080530100316.GD4794@...>, > > <20080531152214.GA8808@...>) 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 <87ej7ide0q.fsf@...>, 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 > > (<20080530101631.GA15849@...>) 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). 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 | lucas@... http://www.lucas-nussbaum.net/ | | jabber: lucas@... GPG: 1024D/023B3F4F | |
|
|
Re: DEP1: how to do an NMU
by Lucas Nussbaum
::
Rate this Message:
|
signature.asc (196 bytes)