John Summerfield said the following on 03/10/2008 11:40 PM Pacific Time:
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.
What would you propose instead?
If someone cannot re-confirm the existence of a problem it is better to
close the bug and move on. In my experience if the problem occurs in a
later version it will get reported again and if it is important enough
it will get fixed. I would agree this is not the most efficient or
ideal scenario, but neither is trying to search and fix 20,000 open
bugs... the result if we stay on our present course.
And this brings us to another realization and expectation we need to
somehow set with our users. There is no way to conceivably fix every
single bug reported for every release. This is not a problem unique to
Fedora--it is the nature of software in general.
How do we strike a balance and not alienate our users and bug reporters?
Can we do it by setting clearer expectations with our users? Do we
need more package maintainers? Do we ________ ?
Our current situation (> 12,000 open bugs) will not naturally fix itself.
You have provided a lot of "that is a bad idea" comments (the easy part)
here and elsewhere, but very few constructive alternatives (the hard
part). Given the choice between what is presently happening vs. what
I've proposed, naturally I'd vote for what I've proposed because seeks
to change and improve the situation :)
I'm open to alternatives as long as they don't include "do nothing" or I
am willing to consider if someone can provide a compelling argument for
doing nothing. :)
== 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.
This is for the bug triage team, not general users. What would you
propose instead?
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.
Because..... ?
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.
Except.... how much overlap is there really today between when FC6 was
cut for RHEL5.0 and what RHEL5.2 will be when next released? That would
be an interesting comparison of packages--I don't know how close or far
away it would be.
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.
To my knowledge Red Hat understands that FC6 is EOL and is not heavily
relying on it for feedback on RHEL5 today--potentially given my reason
above (I do not speak for RHEL).
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.
Red Hat supports and maintains RHEL via the subscription model. With
finite resources and time, the focus of Fedora can only focus on so many
releases at a time. That is the decision Fedora has made--two releases
+ the release under development.
John
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
