[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: changes are needed, we need keep moving



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]