On Fri, Apr 30, 2004 at 02:31:23PM +1000, Anthony Towns wrote: > On Thu, Apr 29, 2004 at 11:19:10PM +0200, Jeroen van Wolffelaar wrote: > > Abiding the SC is a duty of the whole project, not just of Release > > Manager. > > So why does the whole project seem shocked and appalled that I'm actually > trying to abide by it? I can't speak for the whole project of course, but nobody would be shocked if you were abiding the SC w.r.t. your own packages, but it seems that quite some people don't think the RM should prioritize other people's responsibilities over his own: trying to get an as good as possible release as timely as possible out of the door. Compliance of packages in Debian with the rules we set ourselves and the rules that are set upon us (respectively, the SC with the DFSG and the laws (copyright, trademark, patent)) is a responsibility of ftp-masters (next to of course the respective maintainers). You are one of the ftp-masters too, and nobody would object if you in the role of ftp-master would do something about this. But Release-Managing involves other tasks, and since you are the RM, I think most people would like you to prioritize your RM tasks over your ftp-master tasks -- other people will take care of the ftp-master tasks, there are some good people on that job. > > Both not fixing a SC-compliance issue in a certain package in > > unstable today and releasing Sarge with such a package is IMHO a > > violation of the Social Contract. It should be fixed by the members of > > the project, but it is not a death-sin if that doesn't happen today. > > Well, that's good, because it's not going to happen today -- it's a lot > of work. > > It's not really a question of whether it's a mortal sin to take the time > to do it, it's a question of whether it's in any way appropriate to put > other priorities -- namely getting other RC bugs fixed, working on d-i, > etc -- above the commitment we're making in the various first point of > our social contract. Do you suggest that I shouldn't fix a wishlist bug in one of the most unimportant packages there is, just because I should have been working on cleaning the whole archive of SC violating packages? Everybody has their own things to fix, the RM has a release to coordinate, I have packages to get in good shape, and I won't stop doing that just because *some other maintainer than myself* doesn't currently fully comply to the SC. It isn't _specifically_ my duty to do so, nor is it specifically one of the RM's tasks. The RM has already a lot of hard things to do. Again, complying with the SC is a responsibility of the whole project, and for the issues at hand specifically for the respective maintainers and the ftp-master team. > > I apologize for suggesting this untrue thing. > > > > About the offensiveness, see above: I don't think it would be abject if > > it were actually the case, we seem to disagree on that. I'm sorry but > > I cannot do much about the fact that you feel offended by being ascribed > > my interpretation of your actions (the interpretation of which I now > > know is false). > > Huh? Of course you can do stuff about the fact I feel offended: you can > apologise for things you say that are untrue, and not say them in future. You quoted me exactly doing that: I apologized for saying an untrue thing. What can I do more? Buy you a box of Dutch drop to thank you for your work as release manager? I'd be glad to do so, because I _do_ think you're working good & hard on the release, please realize that the current fuzz is just about different views on prioritizing certain tasks, despite the huge flames over the subject. If you are willing to accept the offer, please somehow make a postal adress you have access to available to me. It is simply true that I previously interpreted the motivation for your release-policy wrongly. I cannot change that. I haven't presented my former interpretation as a fact (except by accident one time, for which I apologized above), I only noted that wrong interpretation in order to be able to try to explain why there currently is a disagreement. > > [1] Slightly refers to border-line cases here, I would not have found > > it acceptible if the RM knowingly excused the inclusion of f.e. > > ArcView in main > > The general policy is that licenses which have been previously considered > free, but which are then investigated more thoroughly and discovered > to have some problems, continue to get treated as free until we've had > a chance to see if the upstream author was aware of the problem and is > willing to fix it. If the problem is able to be fixed, it gets fixed in > the next update; if it's definitely not able to be fixed, it's moved > to non-free when that's found out. This applies in the case of the > SGI/xfree86 copyright issues, eg. > > I believe that's the appropriate way of ensuring main stays 100% free; Hm, that's true, and I withdraw the statement in the footnote quoted above. Also, after thinking stuff a bit more over, I wasn't even referring to the RM specifically in this case, but to the whole project in general. But I still withdraw it, so just ignore that footnote :). Sorry about the confusion, it was a last-minute addition to that mail I didn't think over well enough. Kind regards, --Jeroen -- Jeroen van Wolffelaar Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Attachment:
pgpyMgx9eBQYF.pgp
Description: PGP signature