On Sun, 23 Sep 2007 20:50:04 +0200 Bas Wijnen <wijnen@debian.org> wrote: > On Sun, Sep 23, 2007 at 07:09:34PM +0200, Ricardo Mones wrote: > > I fail to follow your reasoning here, if you don't like the packaging > > you should say so, as you're not the maintainer, just a sponsor, and not > > change it to fit your likings without consent. Not fixing the RC bug on > > time is responsibility of the maintainer for not providing a good > > packaging, not yours. > > 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. > 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. > I would agree with your arguments if this would be about large changes. > But that's not the case. This is about a line which has no effect > whatsoever on the package, but only on the next upload (if it can or > cannot be done by Miriam, although I didn't realize it was about her, > since I wasn't informed about the reason of the line). Not doing this > upload still means nothing changes until the next upload, so the > difference between uploading now without the line and not uploading now > (in both cases with the option of uploading later) is only that the new > package is actually available to the users. And that's something I > want. And I shall not hide behind "it's not my responsibility" to make > it not happen. 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). > I also think I'm by far not the only DD who feels about it like this. > It's not unusual to see on -mentors something along the lines of "I > uploaded the package with those things changed, as the rest was fine". > So if people really want their packages to be uploaded "exactly like > this, or not at all", then I suggest they should write this in every RFS > e-mail they send. I would of course honour such a request, but I will > continue to not make it the default. 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. And before anybody wonders, that doesn't invalidate my first paragraph: if I receive a description fulll off typoss I would sent it back :) > > "power grab", backdoor... is good to be a security paranoid but not to > > the point of not talking before acting. > > The reason of doing the upload wasn't that I am security paranoid, but > that I considered the new package a big improvement, and that I expected > (incorrectly) that it would take some time (a few days) to get enough > responses to consider the discussion "closed". First asking, then > saying "well, this takes too long, I'll upload anyway", would not help > much in getting the improvements to our users fast. And it probably > also wouldn't help in preventing "damage". Agreed, but if you wanted to shot before asking the solution is already explained above, will not bore readers repeating myself. > > I'm pretty sure if you had expressed your fears before uploading you > > would have been granted the permission to remove the flag and nobody's > > feelings would have been hurt. > > You're wrong about that. The fact that that flag was there without any > mention and without any question to me has bothered me. This is also > the reason I may have sounded a bit agressive. I tried to keep it out > of it, but I was pretty annoyed at the situation. Well, that's true, not to mention the addition of the flag is not good, and as you mentioned it should have been noted in changelog. But that doesn't make your decision better. 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. > > Reverting that is not as easy as adding or removing flags, > > unfortunately, and the "fix a RC bug" excuse is not worth the damage, > > IMHO. > > I considered changing details before uploading as completely normal (and > still do), so I didn't need an excuse for that. I would also not have > expected any damage from it. And actually, I think (and certainly hope) > that the damage that was done is limited to triggering a break to > prevent a burn-out. I wouldn't even consider that "damage" at all, I > would consider it a good thing.[1] 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. For sure I agree with you that the final result a good thing, much better than it looked at first. > Thanks, > Bas > > [1] I've also had some personal communication with Miriam, and she isn't > angry with me. From the bit I know, I wouldn't have expected less from her. best regards, -- Ricardo Mones http://people.debian.org/~mones «Communicate! It can't make things any worse.»
Attachment:
signature.asc
Description: PGP signature