Backlog proposals, now and future - Special Bug Triage meeting, 2008-03-12 17:00UTC

[John Summerfield]

Jon Stanley wrote:
Jon Stanley wrote:
 > Hear ye, hear ye!  There will be a special meeting of the Fedora
 > BugZappers in our usual meeting slot, Wednesday 2008-03-12 17:00UTC in
 > #fedora-meeting on freenode.
 >
 > The purpose of this meeting is to solicit input on proposals for
 > dealing with the current unmanageable backlog of bugs.  In the long
 > term, this backlog will cause Fedora irreparable harm, if it has not
 > already.  Our most valuable asset, the bug reporter, is feeling left
 > out in the cold.  Community triagers feel discouraged by what they see
 > as a insurmountable task, thereby making the problem feed on itself.
 > We have to act, and the time to do it is now.

I can report this _user_ is feeling very lonely atm. I'm trying to sort 
out what I think is a kernel bug - I've reported it and there's been 
little action there, and since it effectively prevents my "testing" of 
f8a, it's something _I_ need fixed.

I'm not a triager, and don't plan on becoming one, but the work I'm 
trying to do falls (in my imagination) between there and that of the 
actual support team.

I've spent tens of hours doing something (see the inserting busybox 
thread) that someone from the kernel team could probably have spent ten 
minutes on and provided some valuable help, probably saving me most of 
that time, and maybe providing hints on where to go now.

I assume that they don't follow the list, and so made a note in the bug 
report that I'd be discussing it here. I hoped that someone might take 
the time.

<snip>

When I talk of a bug, I mean one that has sufficient information for the 
triage team to have reasonable prospects of reproducing it.

As an aside, but one worth keeping in mind, is that marketing folk will 
tell you that bout four percent of people why buy shoddy goods or get 
poor service complain. Many more  will not return if they think they 
have a choice.

I would guess that fewer people report bugs in software, it's more 
trouble an they're conditioned not to (any Windows users here?)


> 
> Also note that the framework of the proposals is there.  The exact
> text to be found in bugs is still yet to be written, however that will
> be written in the next week or so.  The text of both of the proposals
> follows.  I realize that both this introduction and the proposals
> themselves are extremely long, but please read them!  The wiki

I will make my comments here, I've not passed the wiki-hacking exam 
yet:-) Besides, I imagine more people will see it here, and anyone who 
wants to can transcribe what I say to the wiki.





> Historically we have a had a lot of stale open bugs.  In order to
> remain focused as a project it is best to close out bugs we aren't
> going to be able to resolve so that we focus on the bugs we will. And
> if you think this is too aggressive you're welcome to keep your bugs
> alive by continually moving them to the latest version.
> 

Take care with closing out old bugs. I've just discovered I have one 
hanging out from a f6 beta. I was in "NEEDINFO." I don't recall all the 
circumstances, but the nature of the bug requires a new install, and I 
don't normally have the hardware - how many people other than R Day have 
a brace os spare laptops to hand?

Someone with a ks file and vmware could have tested it in a few minutes, 
I did so myself when I had a real machine on which I was installing 
CentOS 5.1. The bug still exists in CentOS 5.1, and it needs to be 
fixed, not discarded.

Assuming a user can test a bug some time later is a mistake. It's often 
not the case.


> 
> == Bugzilla Product Versioning ==
>  * Fedora will track bugs solely based on the version number of the
> release or '''rawhide''': the release under development which has not
> been released.

I've never seen any merit in distinguishing where a program is used. A 
bug in dhcp 4.0 probably exists where ever it's used.







>    * There are no term limits, but we want to flush the page each
> release so it stays current without a lot of work.  We don't think
> asking people to re-add their names once every six months is a big
> deal.


The users might disagree. In fact, I'm sure they will.



>    1. Create/update script ''eol-warning'' script for mass-change of
> all bugs for the oldest supported version which will become ''end of
> life'' (EOL) one month from GA date


If bugfixers are doing their jobs properly:-) this shouldn't ordinarily 
happen. There are many scenarios where I can imagine the original 
reported will not/cannot test a later version. For example
1. Timing is bad. The bug I mentioned above falls into this category, I 
could only test it when installing Linux. Not only that, but (I think) 
it has to be a ks install.
2. Something didn't work, the user reported it and used an alternative 
tool. There is, for example, some choice when it comes to web browsers, 
CD authoring software. A user on dialup is particularly illequipped to 
download a browser just to see whether a bug's been fixed.
3. The user's gone to another distro. Even worse, to WIndows.

Closing bugs when they have to potential to cause more grief won't do 
you much good in the long run.


Closing bugs when they have to potential to cause more grief won't do 
you much good in the long run.


Okay that's about it for that document, the rest deals with automatic 
disposal of bugs. In case you didn't notice, I don't like the idea, and 
in some cases packages in EOL Fedora need ongoing support because they 
are also in RHEL. FC6 and RHEL5 for example.

Most packages in FC6 need support until EOL of RHE5 and that's some 
years ago. I contend the emphasis should be on which packages need to be 
supported (eg the release of dhcp that's in FC6/RHEL5), and then addrss 
the question of _distribution_ of fixes.

If that means the components shared between FC6 and RHEL5 have to be 
supported by RHEL employees. I don't see a problem The F community can 
apply itself to other matters.