[CentOS-devel] Packaging Office hours at 16:00 UTC today

[Les Mikesell]

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