= Proposal topic = Older releases need a different approach for updates / karma
= Overview =
A more detailed overview of the proposal
= Problem space = We have almost no proventesters for older releases, in this case F14. This results in very long delays until packages get pushed into -updates, some packages never make it into the release. This also applies to security updates. It would make for some quite bad press if there were a major security problem and they find out that we had a fix sitting in -updates-testing without pushing it. Here's a discussion about this issue: [http://lists.fedoraproject.org/pipermail/test/2011-September/102493.html]
= Solution Overview =
I can think of severaly possible solutions, but feel free to add your own:
weekly IRC meetings of proven testers where all unpushed security updates get discussed. Sometimes an update was already at least sanity tested but the tester didn't care to give karma.
automatic pushes after lets say 2 weeks if at least one proventester has tested this package and found no regressions. This should also apply to critical path updates.
FWIW I'd support #2, as I've mentioned a few times on -devel. Lower standards for older releases makes no sense from a theoretical viewpoint, but from a practical one - especially for security issues - it does.
But is the option 2 really an improvement? Aren't those delayed updates actually waiting on proventesters vote?
It is an improvement for critical path packages where you need karma from a provenpackager AND rel-eng/QA Afaik for all other packages the packager can decide by himself if he wants to mark the package as stable even if the package didn't receive enough karma.
adding meeting keyword.
We are going to revisit this next week. In the mean time:
nirik is going to try and start some proventester meetings
adamw is going to talk with QA about drumming up more testers.
dledford is going to look at a proposal to split up critpath into functional subparts.
This ticket is very similar to #667 Request to fix CRITPATH update process. It was decided to close it as duplicate on FESCo meeting 2011-09-19.
Login to comment on this ticket.