On Fri, Jan 24, 2014 at 1:24 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
I think that is being optimistic. Think about the number of updates that come in a minor revision update.
Minor versions go under item 5. I'll admit I was not clear enough, but this also applies to minor release versions, 6.0, 6.1, 6.2, 6.3, 6.4, 6.5,.... 7.0, 7.1 ... :
But yum doesn't know any difference about these. Updates are pulled when the appear.
"5. When new distro version is releases, Q&A anyhow tests everything, so you can forget that scenario needing this mechanism. Only packages coming to updates repo would be marked, IF they are of interest to SiG's."
There is enough time in regular Q&A process for SiG's to test their Variants.
Do we have any historical data on how much lag SME/ClearOS etc. have ever had?
Packages get renamed/split/merged and dependencies added in minor-rev updates. Not sure you can count on existing naming.
Please point me to one instance where Red Hat carelessly split packages with simple updates, not counting switch to minor versions 6.1, 6.2, ...
Those revisions have to work without breakage or being held back for everyone too.
- Every change is logged in Change_log, so maybe on-duty SiG
representative can clear package even before actual release to updates folder.
I wouldn't want to restrict SIGs to organizations able to guarantee that.
So only organizations can elect a person to watch out for changes?
I mean only ones with sufficient redundancy to always have an available person if everyone else is going to have to wait for the release. A mechanism where one SIG's problem accommodating an update doesn't affect anyone else would be better.
Another system can be put in place. Every stable repository will have to have testing repository. So newer package could be symlinked/copied automatically to testing repository of SiG/Variant and Variants/SiG's could have a testing VM with enabled testing repository. So as soon as newer package is released, testing VM could pull new packages and checks would be performed, manual or automatic.
I like this, but it depends on the mirror mechanism playing nicely with symlinks - everywhere. In this scenario you could just symlink everything and point the base updates at the SIG, pretending everything was duplicated. And you wouldn't need priorities.
I am guessing such packages needing attention would not occupy more then few hundred megabytes in their peak. Remember that we are not talking about all packages in question, just those freshly updated that haven't been audited yet by SiG's!
At some point, wouldn't the updates that haven't been audited have to be all of them?