On Thu, 2 Jun 2005, Eric Rostetter wrote:
Something needs to
start happening. Ideas?
People who have an interest in having packages released need to start
doing QA (and/or other work for the group).
We've been calling out for that for months, but that has typically
resulted in minor surges only, nothing major enough to go on with.
If one distribution version of a package has one VERIFY vote, all the
versions will automatically be released after a timeout of XX (where
I suggest XX is 2 weeks) from the first VERIFY -- except if someone
identifies issues which require discussion or more work.
You might as well just publish them without testing then. One verify vote
isn't significantly different than no verify votes. I'd say any plan
that requires only one verify vote is worthless.
I disagree. Patches are typically very similar across all the
versions. The sanity of the patches has already been checked at
PUBLISH. Checking that the program actually works in one platform is
definitely better than nothing.
I'm not against the timeout, in fact there is supposed to be a timeout
in the process, though I don't remember what it is. Perhaps we need to
revisit the timeout issue, with the goal of putting someone in charge of
watching the packages for timeout conditions.
AFAIK, there is no timeout, at least it isn't documented. You may be
remembering the situation with RHL72/RHL73 and RHL8/RHL9 where I
recall there was something like a timeout but that case no longer
exists.
Right now, no one is AFAIK
watching for such situations, so even if something had multiple verify votes
and has stalled, no one notices and pushes it out. Seems like another
essential job waiting to be filled.
Regardless of the timeout, there exists the case where VERIFY vote has
been given but the fact has not been recorded in the status
whiteboard, so the package is organized in the wrong place in the
issues list.
I've been monitoring these things, to a degree, myself, and I believe
the current issue list is reasonably accurate.
This is a tradeoff between quality, timeliness and actually delivering
the updates.
Your proposal as-is is no trade off. You're simply saying we should release
updates without proper testing. But it does raise a valid issue (we're not
actively watching for stalled issues, and pursuing them correctly).
As said I disagree with this view, but even with this, a project like
fedora legacy is even more worthless if it doesn't produce anything or
doesn't do it in a sufficiently timely manner.
Remember, we aren't cooking those patches ourselves. Almost all of
them are directly copied from an already QA'd source (like RHEL), only
a few of them require more than minor modifications.
Because most of the folks worried about quality of the
updates are not actually doing much of testing, I don't see why we
should be stalling because folks seem to be using updates-testing
instead of updates.
If people are using testing-updates and not reporting their success,
then that is the issue, and that is what needs to be fixed. I'm not
sure if this is the case. If it is, maybe we could make posting a
success report easier (e.g. a web form they fill out?)
Well, as I said half a year ago, all this fuss about PGP signatures
and bugzilla turns people away. Most folks don't want to do
self-introductions, pgp generations, register bugzilla accounts, etc.
But at this point, I doubt there is much more to be done about it.
If something breaks with the update, we'll just
fix it afterwards and say "well, you should have tested the update in
2 weeks and reported the problems".
And they will rightly say, "No, FL legacy released it as tested and
passing QA, so the problem is with FL and not me."
If the users don't want to involve themselves in helping the project,
I don't see how we should be concerned about "complaints" from such
users.
(FWIW, the current "issues" list is:
http://www.netcore.fi/pekkas/buglist.html)
I find posting that list is the thing that gets things rolling. In other
words, very few people even consider testing until an issue list is posted
at which point they check it out and start testing packages. I hate to say
it, but regular posting of the issue list (at least those in updates-testing
needed testing) would probably help greatly.
I am not against posting the URL regularly, but I doubt it'll do much
good. Those that want to know it, already do. Reposting it more than
monthly probably doesn't make any difference.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--
fedora-legacy-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-legacy-list
