On Fri, Jan 24, 2014 at 1:24 PM, Ljubomir Ljubojevic <centos at 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. >>> 4. 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? -- Les Mikesell lesmikesell at gmail.com