On Tue, Apr 29, 2003 at 01:41:00PM -0500, John Lightsey wrote: > (1) Reportbug doesn't seem to have the ability to add tags during a > follow-up. Is there a feature I'm overlooking that allows this or is it > normal to send a follow-up through reportbug and a seperate hand written > message to [EMAIL PROTECTED] > > Bugs #20715 and 49431
The normal approach is to cc the message you send to [EMAIL PROTECTED] with the control commands at the top terminated by 'thanks'. I always use reportbug in conjunction with mutt configured to show me the headers of mail, so I don't run into a limitation here. > (2) When a bug is filed against the wrong package should I in submitting a > follow-up reassign the bug or should I simply point out that the problem lies > in another package and leave it to the package maintainer to reassign the > bug? > > Bugs #187686 and 137135 Depends how confident you are :), and how involved you've been with the bug. I've been known to reassign other people's bugs, but you may annoy maintainers if you're wrong. In particular, try not to get into games of "bug tennis" with bugs that aren't yours. > (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. That said, not being able to track this kind of thing is really a deficiency in the BTS itself, which we're working on. > (4) Related to the last question, what sort of bugs qualify for fixes in > Stable - Proposed Updates? See above. > Does the package maintainer make that decision? No, the stable release manager does. > I can understand that maintainers probably don't want the hassle of > backporting fixes from upstream, but as a user I don't really see how > a fix I will not have access to for a year or more is really a fix. While I understand, at the moment your only option is to build the source package from unstable on stable. > (5) Although I like the idea of fixing bugs as a way of getting to > know the Debian community and ultimately start on the NM process, I'm > wondering if this is a practical way of going about it. In my opinion, yes. > 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. Cheers, -- Colin Watson [EMAIL PROTECTED]
