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

NM's to fix bugs? (Was: Asking for an advocate (gURLChecker))



> unless they can give some demonstration that they're into more than just
> making packages.  Fixing bugs, for instance.

This advice is quite usual on this list. I think there are a few reasons why 
it's not as common thing for non-DDs to do as it maybe could be:

 + There are so many packages and so many bugs that it's really hard to
   say where to start.

   There should be some way to priorize the packages as well as bugs:
   it's clear that fixing grave bugs is more valuable than whishlist
   items but should I pick "axyftp-doc" or "mhc-utils"? It's clear that
   most bugs will be fixed by package's maintainer but if the goal is a
   solid release, wouldn't it be a good idea to direct "extra pairs of
   hands" to the most important tasks?

 + The bug tracking system is a less clear and more difficult to use
   than in many other open projects.

   I, for instance, find it a lot easier to work with KDE's or even
   OOo's bug trackers than Debian's. Being email based (an thus not
   quite realtime) plays a big role in this inconvenience of use, IMO.
   I've been playing around with an idea of making a nice local
   frontend for BTS by adding a procmail filter that would intercept
   incoming mail. But: I'm not sure which one would be wiser, making
   such layers on top of current system or taking bugzilla or something
   and customizing it for Debian.

 + You often get cranky response for suggesting fixes.

   The classics are "RTF-doc-behind-the-door-with-beware-of-the-leopard-sign",
   "do you really think we haven't considered this already?" and the synthesis
   of those two, the "this was already discussed a month an a half ago in 
   #importantstuffnotforusers-italian". No good suggestions here - I'm afraid
   it's human nature to be annoyed by ignorance. :-/
   However: an NM is a *New* M - please remember to cut us some slack..

- Jarno



Reply to: