changes are needed, we need keep moving

[Pekka Savola]

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