I think we mostly agree, so we can close this discussion. On Mon, Sep 24, 2007 at 12:59:51AM +0200, Ricardo Mones wrote: > > I'm sorry, but that's not how I see things. IMO I help the maintainer > > get the package in good shape. The result is a package which has a bit > > of me and a lot of the maintainer. Doing an extra iteration for some > > last details is just not worth the time. The package was good, and I > > felt it important that it got uploaded soon. I don't feel about it as > > "so what if the bug is fixed later, that's not my responsibility". > > Doing extra iterations is how people learns not to make mistakes. If you > solve things before uploading the maintainer will not make the effort and > will keep providing you defective packages. That's a waste of time on the > long run, doesn't help to make better maintainers and, in lesser degree, > makes them depending on the sponsor. Oh yes, of course I do iterations. It's just the "extra" part that I didn't consider necessary in this case. > > Debian is all about creating the best OS possible. Every DD should try > > to help to reach that goal. Leaving an RC bug unfixed is not good, and > > every DD should consider it a problem. I happen to be a DD who can > > actually do something about it. So I do. > > Not really, is about creating the best free OS, and, even it is not written > in the SC, I think that target is not to be reached at any price. The bug > was only to remain unfixed for a few hours, nothing dramatic. Looking back at it, you were right. I expected it to take a few days. For a few hours I would have sent it back, indeed. > There was still the possibility of uploading without removal the line, if > the responses of its presence would have been unsatisfactory you can always > re-upload with it removed. You don't hide, the bug is fixed, users have the > package and this thread wouldn't had happened (at least not that way). That's just too much against my feeling for security. It's "open a hole, even though I think it's wrong, then later (try to) close it if I was right." The hole is in this case very small, but the reasoning is so alien to me, that it didn't even occur to me that it was possible. Closing security holes can usually not be done properly (for certain, the hole may have been abused and others may have opened through it). This is not very relevant here, of course. It's just an explanation of why I didn't even think of doing it that way. Also, the reason I saw this is that the flag was not set in the previous version. So while "keeping it unset" is a minor thing, "setting the flag" is quite a big thing IMO. That also means that with the flag set, the package was IMO not fit for uploading, because it was missing information in the changelog. > Well, I agree that single typos don't deserve re-iterate, I myself have > solved some and sent back the patch to the maintainer, but that was not the > case here. On that we disagree, I suppose. :-) > Not documenting changes in the changelog is a mistake one can expect > from a non-DD, and that's a serious thing which deserves another > iteration of the package, IMO. Yes, that is true. Well, I did that, really, except that I skipped the "you need to remove the line; Jens uploads a new version with the line removed" part. I did send Jens an e-mail saying that this was a problem for me, that I fixed it, and that I would discuss it on the list (which is how this thread started). For very minor things, where the fix is obvious, that is acceptable IMO. (I know you don't consider removing the line minor, but I do (when it wasn't there in the previous released version).) > Well, what a detail is varies a lot from people to people. IMO that wasn't > a detail. IYO it was. That's fine with me. But I still think there was a > better way to do the upload, and just wanted to make you know it. Ok. Thanks for sharing your opinion, 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