Incomplete with no response >30 days

Reinhard Tartler siretart at ubuntu.com
Tue May 27 06:55:45 BST 2008


Wolfger <wolfger at gmail.com> writes:

> On Mon, May 26, 2008 at 11:53 AM, Reinhard Tartler <siretart at ubuntu.com> wrote:
>
>> So a pretty please with sugar on the top: If you don't understand what a
>> bug is about, please do not touch it. This includes all what is recently
>> called a "workflow bug".
>
> This is a pointless request, since it requires the person looking at
> the bug to understand that he doesn't understand. People who think
> they understand (but don't) are far more damaging than people who know
> they don't understand.

I fully agree with your rationale, but not why my request should be
pointless.

>> I'm a bit surprised that the bugsquad team focuses on triaging and
>> editing bugs instead on generating statistics, showing trends and
>> pointing to pointless bug statuses like bugs marked 'in progress'
>> without assignee or bugs assigned to a team.
>
> I am totally confused by what you mean here. You are surprised that
> bugsquad focuses on triaging bugs?

In some ways. I've seen enough cases (and now I'm sorry I didn't make a
list of such bugs) where triagers (at least I think they were triagers)
made bugstatuses that confused me or the report or both.

I'm e.g. still confused that everyone seems to be able to nominate bugs
for release (but that's another story...)

No really, triaging bugs is a real hard thing to do. I tried it out
myself yesterday, and triaged about 8 bugs in the cryptsetup
package. Some of them where rather old, some of them had even patches in
them. It took me about 4 hours to triage these bugs. (this makes it
nearly 30 minutes of thinking, testing and playing with each bug). That
is because:

 - I really had to think what this bug is about. While in some cases I
   was short of setting up a virtual machine with gutsy or hardy to have
   a test setup, I most of the time I could get away without it. (most
   of the)
 - most of the patches don't apply directly. So I had to review them and
   try to apply them to the package. Them re-review the source
   package. You get the idea. Happened e.g.  #95050
 - some of them were just user requests, like #136760
 - some of them were feature requests like #160083 or #126851, but it
   was not obvious that the package was lacking this functionality
   before looking at the source

Granted, cryptsetup may be a challenging package. But from my experience
with working with bugs in debian (and I do maintain a couple of packages
there), I can tell that working on bugs is real hard work. And if you
don't get it right in the first place, reporters will get pretty
angry. For good reason, as I found out (btw. using the hard way).

So yes, I am suprised why you guys decided to work on the hard tasks
first instead of easier one to get experience.

>> Developers don't need a group of people malicously editing their bugs,
>
> Ubuntu does not need people maliciously sowing dissent in the ranks of
> the volunteers who work very hard to help Ubuntu. If you have evidence
> that "a group of people" are "maliciously" editing bugs, then please
> present that evidence so we can deal with these people.

Leaving out the most important sentence of my mail is not going to help
a productive conversation.

>> And do notify developers how you expect interaction to be. Don't
>> expect developers (or anyone) to regularily poll the wiki page.
>
> In so far as the debugging process is documented on the wiki page, I
> *do* expect people (triagers and developers alike) to monitor the wiki
> pages that pertain to them for changes. It's a simple thing to do,
> requiring very little time. 

No, it is not. Please do not expect anyone to monitor a wiki for
changes. If there are changes and developers need to be notified about
something, you definitely need to post it to
'ubuntu-devel-announce at l.u.c', since that is the designated list for
announcements. Developers are required to read it. The wiki changes are
not.

> When a procedure is documented but not followed (or when a procedure
> is changed but the documentation isn't) is when problems like this
> entire thread arise.

I think this thread arose for a couple of reasons:
 - it was not propoerly communicated with the developers (and still is
   not. I don't consider this discussion as communication with the
   developers since it is on the wrong list, not every developer is
   required to read this.
 - Observations that people persumably members of the bugsquad have
   confused developers with changes to bugstatus
 - Big confusion on the developer side (at least it was for me)


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4




More information about the Ubuntu-bugsquad mailing list