On 16 May 2018 at 13:14, Kevin Fenzi <kevin@xxxxxxxxx> wrote:
> There's been a ton of talk about this over the years, but thanks a lot
> to Smooge for making a more formal proposal we can look at and adjust
> and see if we can get something we actually want to do. :)
>
>
> On 05/15/2018 12:06 PM, Stephen John Smoogen wrote:
>> EPIC Planning Document
>> __________________________________________________________________
>>
>> History / Background
> ...snip...
>> Proposed Solution
>>
>> EPIC will match the Enterprise Linux major/minor numbers for
>> releases. This means that a set of packages will be built
>> for say EL5 subrelease 11 (aka 5.11). Those packages would
>> populate for each supported architecture a release, updates
>> and updates-testing directory. This will allow for a set of
>> packages to be composed when the subrelease occurs and then
>> stay until the release is ended.
>>
>> /pub/epic/releases/5/5.11/{x86_64,source,i386,aarch64,arm,ppc64}/
>> /pub/epic/updates/5/5.11/{x86_64,source,i386,aarch64,arm,ppc64}/
>> /pub/epic/updates/testing/5/5.11/{x86_64,source,i386,aarch64,arm,ppc64}/
>>
>> Once a minor release is done, the old tree will be hard linked to
>> an appropriate archive directory.
>
> When is a minor release considered done? When the next minor release is
> released?
>
I would expect it would be set by policy but dictated when the next
minor release is released. In the case of the 'last' like 5.11 we may
need to have some additional policy for say 6.20 (making this up)
where packages are put in which EOL the package in the repo.
[something like xmms-3.10.2-9eol-unmaintained.i386.rpm] it would
basically be a rebuild of the last package in the repo with some
blanket file saying "This package is no longer maintained by the EPEL
project. It is recommended that you either remove this package or find
a different repository which still maintains it. You are on your own."
> ...snip....
>
>> Proposed Solution
>>
>> The main EPIC releases will be built against specific CentOS
>> releases versus the Continual Release (CR) channel. When the
>> next RHEL minor is announced, the EPIC releng will create
>> new git branch from the current minor version (aka 5.10 →
>> 5.11). Packagers can then make major updates to versions or
>> other needs done. When the CentOS CR is populated with the
>> new rpms, packages will be built in the new tree using those
>> packages. After 2 weeks, the EPIC minor release will be
>> frozen and any new packages or fixes will occur in the
>> updates tree.
>
> So, the branching and build against CR and freezing the release would
> all be done by epel releng, or would it be a opt-in thing by maintainers?
>
I figure it would be done by EPEL releng. I think if it were opt-in
then it would be basically be 'meh' except for that 1 person who can't
stand anyone touching their package.
> ...snip...
>
>> There are several naming patterns which need to be researched:
>> /<package_name>/epic/6/10/
>> /<package_name>/epic/6/11/
>> /<package_name>/epic/7/6/
>> /<package_name>/epic/7/7/
>> /<package_name>/epic-6/6.10/
>> /<package_name>/epic-6/6.11/
>> /<package_name>/epic-7/7.6/
>> /<package_name>/epic-7/7.7/
>> /<package_name>/epic-6.10/
>> /<package_name>/epic-6.11/
>> /<package_name>/epic-7.6/
>> /<package_name>/epic-7.7/
>>
>> Git module patterns will need to match what upstream delivers for any
>> future EL.
>
> This will of course need tooling changes if it's done in Fedora
> Infrastructure, but doable.
>
>> Continous Integration (CI) Gating
>>
>> EPIC-6
>>
>> The EL-6 lifecycle is reaching its final sub releases with more
>> focus and growth in EL-7 and the future. Because of this gating
>> will be turned off EPIC-6. Testing of packages can be done at the
>> packagers discretion but is not required.
>>
>> EPIC-7
>>
>> The EL-7 lifecycle is midstream with 1-2 more minor releases with
>> major API changes. Due to this, it makes sense to research if
>> gating can be put in place for the next minor release. If the time
>> and energy to retrofit tools to the older EL are possible then it
>> can be turned on.
>>
>> EPIC-next
>>
>> Because gating is built into current Fedora releases, there should
>> be no problem with turning it on for a future release. Packages
>> which do not pass testing will be blocked just as they will be in
>> Fedora 29+ releases.
>
> Provided all the people doing that are ok with adding another
> target/more builds/more artifacts, etc. ie, communication would need to
> be made and acks from the various groups.
>
Agreed. From the fact that we have arbitrary branching, anyone can
make a module and a bunch of other things.. I figured adding a couple
of defined targets wasn't too much to ask.
> ...snip...
>
>> The steps for EPIC release engineering will be the following:
>>
>> 1. Branch all current packages from X.Y to X.Y+1
>> 2. Make any bugzilla updates needed
>> 3. Rebuild all branched packages against CR
>> 4. File FTBFS against any packages.
>> 5. Packagers will announce major updates to mailing list
>> 6. Packagers will build updates against CR.
>> 7. 2 weeks in, releng will cull any packages which are still FTBFS
>> 8. 2 weeks in, releng will compose and lock the X.Y+1 release
>> 9. symlinks will point to the new minor release.
>> 10. 4 weeks in, releng will finish archiving off the X.Y release
>
> All very doable, but also a fair bit of work. :)
>
> Basically this is the same process we used for major release bringup in
> epel. It's basically like rawhide at first, all builds go in every day,
> then things that are broken are culled, etc, then finally updates turned
> on. (But in this case epic would have a seperate update repo).
>
>> Between Releases
>>
>> Updates and new packages between releases will be pushed to the
>> appropriate /updates/X.Y/ tree. Packagers will be encouraged to
>> only make minor non-api breaking updates during this time. Major
>> changes are possible, but need to follow this work flow:
>>
>> 1. Announce to the epel list that a change is required and why
>> 2. Open a ticket to EPIC steering committee on this change
>> 3. EPIC steering committee approves/disapproves change
>> 4. If approved change happens but packages are in updates
>> 5. If not approved it can be done next minor release.
>
> Yeah, we kinda have this now with the existing EPEL exception process,
> but the trick is what is a major change? some people don't realize. Its
> hard to have a easy rule...
>
At the moment, I am going to say it will have to be a duck test. Too
much software uses weird 'oh today I felt it should be 4.0 when
yesterday was 1.2' to have a solid test. If we had a robust CI for
every package then it would be 'if the new version breaks the old
tests.. its a major change :)' but I think it will be best to start
with a 'If it smells like a major change, and it feels like a major
change, it is probably one'
>>
>> Build System
>>
>> Build in Fedora
>>
>> Currently EPEL is built in Fedora using the Fedora Build system
>> which integrates koji, bodhi, greenwave, other tools together. This
>> could be still used with EPIC.
>>
>> Build in CentOS
>>
>> EPIC could be built in the CentOS BuildSystem (CBS) which also uses
>> koji and has some integration to the CentOS Jenkins CI system.
>
> I think from a tools/work point of view it would make more sense to just
> add it to the existing Fedora infrastructure, but from a organizational
> point of view it would make more sense to just be in CentOS. If it was
> in Fedora there would need to be a lot of importing of CentOS builds,
> while if it was in CentOS that wouldn't be needed. So, not sure there,
> tradeoffs.
>
>>
>> Build in Cloud
>>
>> Instead of using existing infrastructure, EPIC is built with newly
>> stood up builders in Amazon or similar cloud environments. The
>> reasoning behind this would be to see if other build systems can
>> transition there eventually.
>
> I don't think this is likely a winner: No other arch support, just
> x86_64. Network and logistics problems possible, etc.
>
> Anyhow, I think the proposal is doable, but the epic releng work would
> be substantial. I think we need a dedicated person for all that, or
> enough part time people to make it viable. Also, a few things
> logistically to decide.. and then finally: is there enough interest by
> users in this?
>
> Thanks again for writing this up smooge!
>
> kevin
>
>
> _______________________________________________
> epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
>
--
Stephen J Smoogen.
_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
