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.
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
