[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: On Bugs

I'm fixing this bug in the upstream release of findutils first.  I
hope to get an alpha version out in the next few days.  If this
version succeeds without too many bugs being reported against it, then
I will release it as a formal release, after which time it will go
into Debian.

This release fixes a fair number of bugs.  I considered it more
important to attack the upstream GNU release of findutils first,
though I have hit a number of delays along the way.

Anthony Towns <aj@azure.humbug.org.au> writes:

> [1  <text/plain; us-ascii (quoted-printable)>]
> (Kevin: what's the deal with Bug#19563? It seems a good sample of a bug
> that seems like it should be able to be trivially addressed and closed,
> but which hasn't been for almost three years now. It might be helpful
> for QA to have some idea why this might happen)
> 
> On Sat, Sep 30, 2000 at 11:37:39PM +0000, Roland Rosenfeld wrote:
> > Anthony Towns <aj@azure.humbug.org.au> wrote:
> > > important   any other bug which is a severe violation of Debian policy
> > >             (violates a must directive)
> > Bad idea.  How do you define "severe violation"?  
> 
> As a violation of a must (rather than a should) directive. See the latest
> versions of policy.
> 
> > > We've got almost 11,000 open, unique, non-wishlist bugs at the
> > > moment. That's a lot. Probably unacceptably many [0].
> > Some housekeeping (closing old bugs, which are already fixed, either
> > by maintainer or upstream, applying patches, which are provided in the
> > bug reports,...) would reduce this number a lot.  But this is a job,
> > which has to be done by the maintainers (IMHO only the maintainer or
> > the bug submitter should close bug reports)...
> 
> One thing you can do is mark the bug as fixed, if you're fairly sure it has
> been fixed, but you're not the maintainer or the submitter.
> 
> > 11000 bug reports cannot be processed by one single person, but we
> > have to divide this job to _all_ maintainers (especially every
> > maintainer for his packages).
> 
> But you can randomly choose a couple of dozen bugs, or a couple of dozen
> packages, or a couple of dozen maintainers, and help tidy up some of their
> bug pages.
> 
> > > So what would be nice is seeing lots of those fixed. Maybe we should
> > > have some bugsquash months instead of just bugsquash weekends.
> > Does a bugsquash allow to NMU normal or wishlist bugs?  If I remember
> > policy correct, a NMU is only allowed to do minimal changes to the
> > packages to fix RC bugs, but it's quite hard to do the housekeeping
> > job, which would fix tons of bugs with a little bit diligence...
> 
> From the developer's reference:
>      Bug fixes to unstable by non-maintainers are also acceptable, but only
>      as a last resort or with permission.  Try the following steps first,
>      and if they don't work, it is probably OK to do an NMU:
>         * Make sure that the package bug is in the Debian Bug Tracking
>           System (BTS).  If not, submit a bug.
>         * Email the maintainer, and offer to help fix the package bug.
>           Give it a few days.
>         * Go ahead and fix the bug, submitting a patch to the right bug in
>           the BTS.  Build the package and test it as discussed in Section
>           6.2.3, `Checking the package prior to upload'.  Use it locally.
>         * Wait a couple of weeks for a response.
>         * Email the maintainer, asking if it is OK to do an NMU.
>         * Double check that your patch doesn't have any unexpected side
>           effects.  Make sure your patch is as small and as non-disruptive
>           as it can be.
>         * Wait another week for a response.
>         * Go ahead and do the source NMU, as described in Section 7.4, `How
>           to do a source NMU'.
> 
> By my reading, if there's a patch that seems perfectly workable already
> in the BTS, and that's been there for a few weeks, you're pretty well
> authorised to NMU straight away, although it's still polite to contact
> the maintainer first and see what, if anything, is up.
> 
> > > At the very least anyone with some spare time on their hands might
> > > like to help with merging duplicate reports
> > Another point of housekeeping.  Why are there maintainers, who don't
> > merge the bug reports of their packages?  This doesn't take much time
> > for 10-20 packages, but it takes much time for 11000 bugs.
> 
> Why are there users who don't check if a bug already exists, and file
> duplicate bugs? *shrug* We're all volunteers, we're not perfect.
>  
> > > and sending in patches to existing easily fixed bugs.
> > But does it make sense to send in patches, if the maintainer doesn't
> > merge them into the package?  There are many bugs older a year with
> > patches, which are simply ignored by the maintainer.  It's quite
> > frustrating...
> 
> In that case you can probably do an NMU. Of course, there are then
> bugs like 19563 which have had patches, and been NMUed, but which the
> maintainer has then reverted without any comment at all.
> 
> Cheers,
> aj
> 
> -- 
> Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
> I don't speak for anyone save myself. GPG signed mail preferred.
> 
>   ``We reject: kings, presidents, and voting.
>                  We believe in: rough consensus and working code.''
>                                       -- Dave Clark
> [2  <application/pgp-signature>]
Reply to: