On Thu, Oct 10, 2002 at 01:08:36PM -0500, Branden Robinson wrote: > On Thu, Oct 10, 2002 at 01:51:52AM -0600, Joel Baker wrote: > > While this does not break things on Linux, it *does* cause breakage on > > NetBSD, due to differences in the script handlers. So far, the number > > of packages isn't terribly high - but it's a couple, in under a hundred > > packages, which (if it holds - no good way to tell) is potentially a few > > hundred packages, before all is said and done. > > Can you come up with some real figures first? Various folks have tools > that run on archive and scan the entire archive for this or that. > Perhaps you could team up with one of them to get this check run. Well, a lintian/linda check was suggested - this would both catch a number of the packages without bugs being filed, and give the ability to scan the archives for it. I'll talk to the maintainers of such. > Once we have concrete figures about how many bugs will need to be filed, > it will be easier to grope towards a consensus about mass bug filing. > > Also, one way to mitigate a glut of bug reports might be to break it up > a little bit. For instance, spread the process out over 5 weeks or so, > re-running the scan each time so you don't file bugs that have already > been fixed: > > week 1) all packages with this bug of "required" priority > week 2) all packages with this bug of "important" priority > week 3) all packages with this bug of "standard" priority > week 4) all packages with this bug of "optional" priority > week 5) all packages with this bug of "extra" priority At the moment, the intent was largely 'as I find them', which is rather slower than this. Granted, the speed probably goes up significantly if we do an archive scan or if I get an autobuilder working for netbsd-i386. (At the moment, the Linux-isms of wanna-build are making me consider writing one that is strictly Perl and works with a minimum of things not found in build-essential, but that may just be frustration talking...) > Of course, these sets aren't all the same size, but that's not exactly > the point of doing it this way; the higher-priority packages are more > important to a bootstrapping environment anyway. Also, it gives the > maintainers of the many likely affected "optional" packages a good three > weeks to notice the coming storm, assuming they update their systems > from time to time and use apt-listchanges, or read d-d-c. If they don't > do either of those things you're unlikely to be able to get their > attention anyway, via any means. You could file a bug today and a year > from now it still wouldn't be fixed. > > The other option is of course just to break up the mass-file into m > groups of approximately n packages each. > > My gut feeling is that "n" should be no more than approximately 25, but > I can't articulate my reasons beyond it just feeling instinctually > "about right". No doubt others will have differing instincts. I'm sure > that for some folks, any 2 bugs against different packages reporting the > same thing counts as "mass-filing". But we can ignore those people. :) Heh. Well, I suspect the total will end up being high enough that, all together, it *is* 'mass'. Just possibly spread out over time. > Anyway, I support your initiative here. Our rules files *should* be > conservative in what they generate, so let's get rid of these stupid > extraneous spaces. > > Vim users might want to put the following into their .vimrc files. > These settings will make you a better person. ;-) > > :set listchars=tab:»,trail:· > :set list As noted in my prior message, I think this will, practically, probably end up being fixed on NetBSD simply because *other* scripts are also likely to break, and it's not being liberal about what it accepts. However, wishlist bugs for conservative in sending (especially if I can convince the lint* tool maintainers to add checks, and give it a while for folks to notice) would probably not be unreasonable. Certainly it isn't a deep and abiding crisis of any sort. -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
Attachment:
pgpAlO_HeRT2e.pgp
Description: PGP signature