If we are to form the Debian bugsquad team similar to Ubuntu bugsquad team, the main two questions would be:
1. As a Debian Developer/Maintainer would you be thankful for other people to come and help with bugs in your package. 2. Can we find enough volunteers to form such team? The idea would be to have a team of pasionate people who would constantly try to improve Debian as a whole and they would help the maintainers to triage bugs. The criteria for choosing bugs to help with might be: 1. the 'help' tag 2. the 'moreinfo' tag 3. the age of the bug 4. bugs without an answer 5. special user-tag, f.e. 'bugsq...@lists.alioth.debian.org' -- On Mon, May 27, 2013 at 4:21 PM, Bas Wijnen <wij...@debian.org> wrote: > On Mon, May 27, 2013 at 09:04:53AM +0200, Ondřej Surý wrote: > > On Sat, May 25, 2013 at 8:02 PM, Russ Allbery <r...@debian.org> wrote: > > > He still files all upstream bugs with Debian, but I can't throw stones > > > there; > I think it's ok to fill upstream bugs in Debian BTS, but I almost always reply with "here's the upstream bugzilla, please be so kind and fill the bug there, it will be much more efficient". > > > He files lots and lots of minor/wishlist bugs, but that isn't abuse. > He's > > > one of the few people who regularly files bugs when he finds unclear or > > > confusing documentation, and while that results in a lot of small bugs > > > (and a lot of bugs that are really upstream bugs), I think that's also > a > > > valuable *type* of bug that frequently doesn't get enough attention. > > I agree. On a completely different level, those bugs are also often quite > easy > to fix (taking mostly time, not much skill), and therefore can be used to > attract new developers to a project. Where are these developers you are talking about? Shove them to PHP BTS to triage the bugs. > > The "I see a warning from ucf, let's fill a bug on php5-common" finally > > overflew my cup of patience. > > Especially with simple wishlist bugs, the submitter doesn't want to dig > deep > into the package to see what the problem really is. In a case like this, > the > maintainer should reassign the bug to the package that causes it, just like > they should forward it upstream if appropriate. This is a similar action, > which as I wrote I consider part of the task of a package maintainer. Some packages are easier to maintain, some are much harder. So it might be easier for you to say than f.e. for me with php, rails, bdb and some other packages in my unfortunate portfolio. How many security bugs did you have in your packages in squeeze? Please understand that our perspectives and experiences with Debian package maintenance might wildly differ. > This might be similar to what I have seen in Launchpad – there's a > bugsquad > > team that can handle all bugreports in just any package[1][2]. > > We have a pretty good NMU system, which lets any DD handle bugs in any > package. > There's nothing wrong with preparing an NMU for a wishlist bug. So we > already > have that team. No, we don't have that team. Most if not all people will NMU only for things they care about. I did a lot of NMUs when I planned Berkeley DB transition. > Perhaps the QA team is even closer to what you mean, but they > always say that any DD is in the QA team, so there isn't really a > difference. > No, the QA team is not even close. > But as you write, most people will not fix (or ask for more info on) > wishlist bugs in other people's packages. I am talking about group of people which would help triage the bugs on regular basis, and would help maintainers who cannot find more active maintainers to the team even though the RFH bug is open for more than a year. (And I am thankful for every little contribution I receive) > On Mon, May 27, 2013 at 11:46:05AM +0200, Ondřej Surý wrote: > > > If you think you are distracted by some bug reports, end users > > > are also distracted by debug messages (which are not clearly > > > debug messages) in the terminal. > > And speaking for me personally, even if they are clearly debug messages, I > still consider it a bug that they were enabled for a release. I don't > think > I've ever reported such a thing, but I might do that. It's one of those > things > which is trivial to fix when you're preparing a release anyway, and makes > the > package a tiny bit better if done right. I sent the original email asking on advice how to make my job somehow easier, because sometimes it's too much and I want to prevent my burnout and burntout of some other fellow Debian Developers. Do you understand that your email saying "don't complain, it's your job" isn't very helpful? O. -- Ondřej Surý <ond...@sury.org>
