On Thu, 11 Dec 2008 12:43:03 +0100 "Sandro Tosi" <morph@debian.org> wrote: > Hello Neil, > > On Thu, Dec 11, 2008 at 11:08, Neil Williams <codehelp@debian.org> > wrote: > > Unstable is also "closed" so that other packages can migrate more > > easily. Uploads not related to Lenny should go into experimental. > > New > > can you point to ufficial documentation stating this? (ok, it's a > joke, I know there's none) While it's a wise suggestions, it's not a > law and it's not strictly to be followed. The way you expressed it > seems like "do not ever upload to unstable while we are in freeze" > which is, of course, not true. I did put "should" instead of "must" but I do believe that unstable should be off-limits to the majority of uploads from mentors during this very late stage of the freeze. Refs to guidance in the other mail. I should have started a new thread really, I wasn't referring to this specific package just that the subject came up in this thread. > > with this upload then upload to experimental, not unstable (or don't > > upload until after Lenny is released). > > so are you saying that it was time wasted? I don't think so, and I > think this upload can go into unstable without problems. An upload to experimental is not a waste - I haven't looked at this particular package but, as I said, I have lots of uploads that I simply will not make until Lenny is released and a couple that I will be making to experimental soon. > > It's a bit more complicated than that - 'testing-proposed-updates' > > is for times when unstable already has a newer version of the > > package that will not migrate and an RC bug is found in the older > > version in testing. The preferred method to fix RC bugs is to be > > able to upload to unstable and migrate with permission from the > > release team. Uploading other cruft to unstable gets in the way of > > that process. > > Cruft? so doing a QA upload trying to get the package in a good shape > is "cruft" for you? nice judgment :) Cruft as in unrelated to the task of actually releasing Lenny. It wouldn't be cruft if it went into experimental. It wouldn't be cruft if the same upload was made after the Lenny release. During the freeze and targeted at unstable, it's cruft. > Of course, while we are trying to "stabilize" the distribution in > testing, we should try to fix RC bugs opened (avoiding to introduce > new, ok) but that doesn't mean we have to stop all other activities > waiting for lenny to be released. It would make things easier to release Lenny if all (or very nearly all) activities in unstable that were unrelated to the release *were* actually stopped. Lenny is my priority and it saddens me that other maintainers and DD's don't seem to feel the same way. "Release when it's ready" is not an excuse to let issues go unfixed ad infinitum. We do need to release eventually and the last 60 bugs are always the hardest to fix, so need the most attention from the highest number of people. (People not spending time debating crufty packages that have nothing to do with the release.) > Consider the situation where a guy > want help but doesn't have the skill to fix the opened RC bugs: is he > not "allowed" to package new tools, do qa uploads or update his own > pkgs? experimental - why is that such a bad thing? Why do people react so badly to a recommendation to upload to experimental? It's just a name, a label. It doesn't have to mean that the package is experimental, it simply means that it isn't suitable for what is currently happening in unstable (which, in case anyone is still in doubt, is the final preparations for the Lenny release). Everyone has to take account of transitions and blocks in unstable between releases, the release freeze itself is just another issue to consider with regard to unstable. Unstable isn't 100% available every single day between freezes, there are constant issues that mean that uploads need to be delayed or put into experimental. That's why we have experimental. > > The more differences there are between unstable and testing at this > > time, the harder it can be to actually fix the bugs which then means > > that the entire freeze goes on for longer. Ignoring this problem > > doesn't make it go away - uploading random junk to unstable actually > > prolongs the problem for everyone else. Stop it, please. > > Please stop be so rude to newcomer maintainers. It won't help you nor > the guy willing to help: after such a reply I'll think twice the next > time I want to help Debian. and we do not want this! Some see it as rude, I do not intend to come across as rude but I don't hide from the truth either. There is a lot of rubbish in mentors and it doesn't hurt to be honest about the lack of quality in RFS emails and packages in general across mentors. People complain that their packages are not being sponsored and then complain when the reasons are explained - that the RFS is crass or the package is just borked. Not telling someone the real problem in an effort "just to be nice to people" is selling them short. As for whether we want it or not, I'm quite confident that Debian does not actually want a proportion of what is available via mentors. It can be hard to sift the wheat from the chaff. Some maintainers give me the impression that they think they are doing Debian a favour and that mentors is just a rubber-stamping operation. What Debian does need is more people fixing bugs - packaging can assist in acquiring the knowledge to fix bugs but, as in my sponsoring requirements, I'm not interested in maintainers who do not want to join Debian. I'm not an upload-robot for upstream developers who want a package in Debian as a "badge of honour". The average quality of RFS emails and packages in mentors does need to be raised but, IMHO, some of the packages will never make the grade. It doesn't do anyone any favours to pretend otherwise. Mentors is not a mere queue, it is a review process and sometimes (quite a lot of the time it seems), the request fails the review and simply has to be dropped. Yes, maybe that has been a waste of time but it's better than adding a crufty package to Debian and wasting even more time during the next release freeze. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpBAHfApIFZN.pgp
Description: PGP signature