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?
...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?
...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.
...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...
>
> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
