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

Re: Forming a Debian bugsquad team



On Mon, May 27, 2013 at 09:01:40PM +0200, Ondřej Surý wrote:
> 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.
...
> > 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.

I don't see how the purpose of the QA team differs from your proposal.  If you
mean "the QA team can't find enough people to do all the work they would like
to do", then I agree.  But setting up a different team with exactly the same
purpose under a new name isn't going to solve that problem.

> On Mon, May 27, 2013 at 4:21 PM, Bas Wijnen <wijnen@debian.org> wrote:
> > 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.

I don't have them, of course.  My point was that if someone is interested in
helping, they will want to do a simple task to become familiar with the code.
You cannot use the bugs to generate the people, but you can use them to keep
them from running away.

> >  > 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.

Sure.  But instead of saying "ask upstream", you can say forward the report
upstream yourself.  It's probably not more work for you, but it would be more
work for the submitter, because they would have to create an account on the
bugzilla and learn how it works (which is hopefully not hard, but still work).

> 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.

Oh, I understand that.  But we're talking about ideals here (well, at least I
am).  I think a package maintainer _should_ be the proper place to report any
issue with the package (packaging-related or not).  I know that some upstreams
are particularly hostile if you say that you're using a package (Blender for
example).  They say Debian does it all wrong, and people should download and
install directly from them (which is a very bad idea, of course).  For such an
upstream, I don't want to report my bugs there.  I want to report to the
package maintainer who can fight with them.  But I don't know in advance if
upstream will be like that.  And again, a uniform bug reporting interface for
all bugs is a great feature, which I want our users to have.

For this reason, I argue that maintainers should not complain about bug
submitters when the bugs are in upstream's code.  I didn't say (or mean) that
maintainers can't complain.

> 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)

Again, I do not see how this is not 100% the goal of the QA team.

> 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?

Sorry about that, that wasn't the take-home message I intended.

I wasn't trying to say you should work harder even if you see a burnout coming.
It totally acceptable to be unable to fully maintain a package, if you ask for
help (and you do that).  If no help comes, then apparently this is not
important enough for Debian.  That's unfortunate, but don't let it kill you.
The result will be a badly maintained package (possibly with too many open bugs
or late responses to bug submitters).  Of course that's not good, but in some
cases we just can't do better.  If you don't want to take responsibility for
such a package, and there is no way to fix the problem without a burnout
(which, by the way, will not fix it either), then you should orphan the
package.  Your health is more important than what you do for Debian.

So no, I'm not saying you shouldn't complain, and I actually agree with a lot
of what you're saying.  But I do think we should be a bug-reporting station for
any bugs in our system, upstream or not.  That's a feature which is worth a
lot, IMO.  So to be more explicit: if we have fewer packages in Debian because
our maintainers cannot handle more, and that is (partly) due to forwarding bugs
to upstream, then I think that is the best choice for Debian.

Oh, and just to be sure I am not misunderstood: genuine trolls and spammers
should obviously consume as little of our time as possible.

Thanks,
Bas


Reply to: