Hi, On Wed, Mar 05, 2008 at 01:34:39PM +0000, Neil Williams wrote: > On Wed, 2008-03-05 at 12:37 +0000, Sune Vuorela wrote: > > On 2008-03-05, Neil Williams <codehelp@debian.org> wrote: > > >> of course is changing SONAMEs in a NMU appropriate if it is appropriate. > > > > > > That equates to a hostile hijacking. If the package is orphaned or if > > No it don't. it is just bugfixing. If it requires binary incompatible > > changes to fix it, of course the SONAME should be changed as well. Else > > you introduce new bugs. > > Such intrusive "fixes" should not be done without at least trying to > contact the maintainer. Of course. I didn't understand it otherwise. However, if contacting fails, and the SONAME upgrade is needed to fix a bug, then it may be acceptable to do this in an NMU. Since it's a big change, it would be good to make all delays in the process a bit longer than required, but in the end it may still be acceptable to do a SONAME bump in an NMU. > If this is to fix an RC bug, then yes, a SONAME might need changing but > this should not be done without consensus or without very good cause. Of course. A SONAME change is very intrusive, and it is clear that it must not be done lightly. > At the very least, contact debian-release for advice before changing a > SONAME in an NMU close to a release freeze. That sounds like a very good idea. > Do *not* change a SONAME in an NMU merely on a lintian warning/error. Does a SONAME change ever fix (or hide) a lintian bug? Ah well, as far as I can see we all agree that this is not something to do in an NMU. > > You seem to be living in perfect-world where maintainers are always > > reachable. > > Or just busy. Every NMU must give the maintainer a chance to fix the > problem themselves. The zero-day BSP only applies if the RC bug has > already been open for more than 7 days, specifically to allow time for > the maintainer to fix the problem themselves. Sune mentioned uploading to DELAYED/7. Doing that will give the maintainer 7 days, not only to come up with his own solution, but also to see whether the proposed (at that moment) NMU is acceptable. Of course it is possible to post the patch to the BTS, wait, and after 7 days do a non-DELAYED NMU upload. The DELAYED queue just automates that process. > NMUs should not be rushed or overly intrusive and should not include > changes that are more than "just bugfixing". I agree. In particular, they should not even fix real bugs which aren't in the BTS yet. But when using the DELAYED queue, this is very simple: report the bug, and upload the fix. If nothing more happens, then 7 days later your NMU will automatically be done. If something does happen, the upload can easily be cancelled (by the maintainer or the NMUer), if that turns out to be desirable. In other words, I'm saying that uploading to a DELAYED queue is just a polite means to provide a patch and allow the maintainer to accept it without any action. The maintainer can also reject it without any extra action, by uploading a better solution before the delay is up. And with minimal extra effort, it can even be rejected without uploading a better solution, although of course that leaves the bug open and thus isn't so nice. :-) > > MIA-process && orphaning is too slow for bugfixing. This isn't about > > anything else than bugfixing. > > Not true. These are not your own packages, these are packages under the > care of someone else. Until you know that the maintainer is MIA, you > MUST allow time for the maintainer to supply a fix. The RC BSP states 7 > days for this time, absolute minimum. Before that time, yes, feel free > to comment on the bug report, add info, suggest a patch etc. but an NMU > should not be done, even under zero day BSP release party rules, until > the maintainer has had some time to view the problem. Right. But uploading to a DELAYED queue doesn't count as "doing an NMU". Instead it counts as "notifying the maintainer", plus a public anouncement and automation of doing an NMU if nothing else changes. > I worry that too many requests for sponsors for NMUs here were about > everything *except* bug fixing and that sponsors were asking for NMUs > to make changes that were completely stylistic or solely to shut up > lintian. That is not the purpose of an NMU. I haven't followed the requests, so I wouldn't know, but I agree with you that installing lintian overrides is certainly outside the scope of an NMU. "fixing lintian warnings" in general may be within the scope, but only if the lintian warning is not a false positive, and if the bug is already in the BTS. Also, for sponsored NMUs I think there is no need for a DELAYED upload, because as a non-DD I think it is reasonable to just post your patch to the BTS and wait 7 days before requesting an NMU sponsor. > By all means lets keep NMUs for bug fixing - I like that idea, that is > what people expect from an NMU. Indeed. I think we agree on that. :-) > > >> Sponsors, keep up your good work. If the changes are big, please > > >> consider DELAYED/something though. > > > > > > That's worse! There is a day NMU bug squashing party in effect so > > > there is no point uploading to the delayed queue. Just don't make > > > hostile or intrusive changes in an NMU. Stick to the NMU rules. You misunderstood the parent post, I think. I agree with it, at least, that the DELAYED queue is a good idea for changes which are so big that the maintainer may have a different opinion on how the fix should look. I don't see a problem with uploading a fix to a DELAYED queue before you are allowed to NMU, if the delay is so long that you are allowed to do it when it has expired. In fact, I think this is friendlier than posting a patch without the warning that an upload may be coming, and after 7 days do a direct NMU. This is also allowed, and the maintainer shouldn't get angry about it, but it is certainly less friendly than showing when your NMU will hit the archive if nothing changes. > > fix bugs. Don't make debian the distribution where bugfixing other > > packages is forbidden. We need better packages. don't stop people > > working for this. With delayed/7, you still have 7 days to react. > > That is not how the BSP works. The RC bug must be open for 7 days, then > if the maintainer has not been able to fix it, a zero day NMU can be > done - not before. With DELAYED/7, you don't actually do an NMU before 7 days. This queue is specifically meant to be able to follow exactly the scheme you propose, without the hassle of needing to get back to it (unless the situation changes). > Who knows the package best - you or the regular maintainer? The maintainer of course. That's why he can cancel the upload from the queue. > Yes, fix known bugs but don't delay the RC bugs just to fix less > important ones. That's perverse. I agree. If there are more bugs to fix, they should be fixed in a separate NMU. However, If they are small and likely uncontested, I think it may be acceptable to include them. > In those 7 days, help the maintainer, offer ideas but don't go trampling > over packages until the maintainer has had a chance to fix the issue > themselves. That's exactly what an upload to a delayed queue does: it offers the maintainer a patch for the problem (that certainly counts as "help" and "offer ideas" IMO), and it doesn't actually touch the package at all during those 7 days (that counts as "no trampling"). > If nothing happens after 7 days, don't delay any further, go for a > zero day NMU to close the RC bug. If you do that to my package, I would likely be a bit like "wtf? I delay answering this bug a few days and it gets NMU'd? Why wasn't I notified that this was about to happen?". Sure, I'd get over it, and probably appreciate the help. But I would be much happier if I'd have received a mail from the delayed queue with a timeline of what will happen (if I don't do anything). > If some other bugs can be fixed too, that's fine but don't go after > non-bugs like lintian errors. Don't fix anything that isn't in the BTS. Lintian messages which are not bugs don't belong in the BTS and should thus indeed not be fixed in an NMU. > Can we agree that these tasks should *not* be done in an NMU *unless* > directly related to the RC bug? : > > 1. SONAME changes merely to shut up lintian - i.e. where the RC bug has > no need to change the SONAME. > 2. removing commented out lines in debian/rules > 3. Implementing dpatch or quilt for a package that does not use it > 4. tidying up manpages > 5. Changing the build system to/from CDBS/dpkg/dbs/foo I fully agree with those. > 6. other lintian errors or warnings I only agree with those if the messages aren't actually about real bugs. Well, actually I do agree. The NMU should not try to get rid of the warning (or error), it should fix the bug that it found. 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
Attachment:
signature.asc
Description: Digital signature