On Tue, Apr 29, 2003 at 09:48:10PM +0100, Colin Watson wrote: > On Tue, Apr 29, 2003 at 01:41:00PM -0500, John Lightsey wrote: > > (3) If a package maintainer has closed a bug due to a fix in the Unstable > > version is it encouraged to fix, reopen and retag the bug (patch/stable) if > > the problem persists in Woody? I can imagine that reopening bugs would piss > > off quite a few maintainers, but on the flip side I use Stable on my servers > > and primary workstation. A patch only applied to the Unstable version > > doesn't really fix the problem for me. > > > > Bugs #147494 and 143893 (For the second one I sent a patch directly to the > > maintainer which fixes problems his patch missed.) > > If it isn't a release-critical bug (in this context, a security problem > or a package that's completely non-functional), then it's unlikely to be > fixed in stable anyway, so I don't think it makes much sense to make the > maintainer keep it open for months and months until the next stable > release. I'd like to suggest that such bugs be re-opened if new bugreports come in from stable users, so that there's something sitting there obvious to hopefully prevent multiple bugreports that nothing can be done about. And it'd be useful to have to bug in plain view if and when you try to convince the Release Manager that that bug _does_ cause small fires under the correct circumstances. Of course, this is really up to the maintainer. As long as it's tagged correctly, (so that it doesn't hold up transitions in testing or allow incorrect transitions) then it doesn't really matter overall. > That said, not being able to track this kind of thing is really a > deficiency in the BTS itself, which we're working on. > > Finding fixable bugs (fixable in Debian and not by joining the > > upstream development team) seems to be very hit-or-miss. Many of the > > packages with reams of bugs seem to be unfixable without forking from > > the upstream version (or simply waiting on upstream to get around to > > it.) > > You could pick a Debian-specific package, or one where the maintainer is > also upstream, and work on that. Before I became a developer I sent > loads of patches to lintian, and the maintainer was very complimentary > in my new-maintainer report a few months later. > > Also, there are a lot of bugs of the "won't build from source" variety > and similar, and it doesn't usually take an enormous amount of patching > to fix them. Helping with these is very valuable, and the sort of people > who spend their time going through these will very likely notice. I've found, just by using the unstable distro, that there's often plenty of bugs in packages I've come in contact with... And when that slowed down, I went looking for bugs keeping my favorite packages out of testing. :-) The advantage of this is you're already rather familier with the package, which helps a fair bit, IMHO. -- Paul "TBBle" Hampson, Paul.Hampson@Anu.edu.au 6th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office.
Attachment:
pgpqBm5CEOFoW.pgp
Description: PGP signature