On Tue, 2006-02-14 at 12:54 -0600, Eric Rostetter wrote: > > There has been talk the last couple days of doing away with QA to get it > to the updates-testing. This is what I was referencing, not the current > setup. That is something I will not agree to. However the timeout period is, it strikes a balance. If we see too many packages get released w/out QA by the time the timeout hits, then that is very good indication that we can drop that platform. > >> We can't get to the updates testing package phase > >> w/out somebody doing the first level QA which includes making sure the > >> patch uses is a known good patch from at least some other vendor. So > > I don't think this is true in theory; the patch need not come from some > other vendor, or even upstream, in theory, though it perhaps always has > in practice. Plus, the upstream patch is often modified, so there is > always the chance for foul-play. Perhaps we should make it policy that the patch come from or get approval from upstream. Make the practice a policy. This is why we still have humans looking at the step from proposed patch to updates-testing. That will not get a timeout, that has to happen. The good thing about that step is that it doesn't require a whole system to test. > >> the plot to root all Legacy systems is going to have to start further up > >> the food chain. > > I don't think so. And in any case, I was refering to the suggestion on > this list that we don't do QA to move to updates-testing, which would > by-pass this whole issue you try to bring up. Well I won't agree to anything that bypasses the patch check step. QA must still happen before we put a package into updates-testing. Another thing to think about is we are putting in more QA into our updates that Fedora upstream puts into the updates it issues into live releases. Just food for thought. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-legacy-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-legacy-list
