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

[Ljubomir Ljubojevic]

On 01/24/2014 07:38 PM, Les Mikesell wrote:
> On Fri, Jan 24, 2014 at 5:56 AM, Ljubomir Ljubojevic <centos at plnet.rs> wrote:
>>
>>> But won't that require duplicating the packages into all of the
>>> higher-priority repos?  Is there some magic with symlinks that would
>>> work to make it look like they were duplicated?
>>>
>>
>> Not to ALL higher repositories. Remember they would be hierarchically
>> structured, so you only need to put older package in repository ONE
>> HIGHER then repository you are putting newer package into.
>>
>> Links are very much possible, and are applied where ever possible. I do
>> it on my own repository. I personally have a cron script that runs
>> before mrepo and symlinks packages from several repos/directories to
>> one. Physical solutions are many, depending on what is available.
>
> Sure you could do this yourself, and it might be a solution for my
> long-standing complaint about needing frozen repository mirrors in
> states of every update you might want to repeat.   But, will it be
> supported across all the existing mirror infrastructure?
>
>> But there are circumstances making it easier:
>> 1. packages coming to updates are not many, and SiG's will test them
>> fast, so symlinks or packages can be removed in matter of days and only
>> newly one created will be in line for testing.
>
> 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 ... :

"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.

>
>> 2. SiG's will mark packages they are dependent of. There is no need that
>> Xen SiG has to watch "named" package, so only those SiG's depending on
>> functional "named" package (just a simple example) will mark it, will be
>> informed of new version (as soon as it hit's git.centos.org or when it's
>> srpm appears on CentOS of even RHEL file servers), and will get a
>> copy/symlink of older package.
>
> 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, ...

>
>> 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?

>
>> 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!

-- 
Ljubomir Ljubojevic
(Love is in the Air)
PL Computers
Serbia, Europe

StarOS, Mikrotik and CentOS/RHEL/Linux consultant