On 4 September 2014 10:13, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Fri, 29 Aug 2014 16:08:34 -0600
Stephen John Smoogen <smooge(a)gmail.com> wrote:
> So in todays (2014-08-29) meeting, we wanted to move the various
> policy discussions to email so that people could take their time to
> reply and also to allow for people who could not attend time to
> respond.
Right.
> Going from the web-page
>
https://fedoraproject.org/wiki/EPEL-faster-repo-ideas the following
> items are listed (with additions I added while writing this email.)
>
> I would like to start with the EpSCO governance to just get that out
> of the way and then move to current rules as we see them. I can act
> as secretary to make sure that changes discussed here are put in
> place on the wiki or other places.
>
> Policy questions
>
> - EpSCO governance.
> - Lifetime of initial committee (9 months?)
> - Replacement of any exiting members (replacement by formal
> vote, etc).
> - Size of committee (4 members? 5 members?)
> - Meeting rules (follow
>
https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee
> )
I'm happy with whatever other people want. I think making things super
formal just causes more problems. I think we agreed on 4 members for
now, we can add by vote of those folks, we should try and meet weekly.
>
> - How many repos? (examples below)
> - epel,
> - epel-test
> - epel-rolling
> - epel-rolling-test ?
> - epel-edge ?
> - epel-edge-test ?
There's some thought from folks about doing a per point release repos.
I added some comments asking for more details on that idea.
If repos we add as fast moving/whatever they may not need/want testing
repos.
So this is my general proposal for per point release.
Problem trying to be solved:
EPEL's original goal around a 5-7 year product has run into issues where
various packages end up having shorter lifetimes than can be maintained in
that period. What happens is that the upstream is changing the code too
massively for any sort of 'back-port' to be possible. Some software can be
'patched' around by making it parallel installable but others (say puppet)
only work if there is only one version not just on the system but
throughout an entire ecosystem of systems (thus if you update one, they all
have to be updated to the same version.) While EPEL has a process of saying
you can announce a major change it is severely frowned on and usually ends
up with various users asking 'can you just keep the older version around a
bit longer...' ad infinitum. Another problem is that it isn't clear how
much notice is needed for a change to be made or what changes are being
made so that users and package owners end up confused and upset with each
other.
Possible solution:
Make it so that updates to these sorts of packages occur at regular
intervals. There are three cycles these could occur: regular date driven
(July 1st of every year for example), the Fedora release cycle (Fedora 22
has been released, you can update now), and the Red Hat Enterprise release
cycle (RHEL-6.6 is out, you can release now). Each of these cycles has
their bonuses and minuses but I think that connecting to the RHEL cycle
will be more in line with what downstream users of EPEL are going to be
more in sync with.
Proposed implementation:
Every Red Hat Enterprise Dot Release has a beta period and then a release
period. After the release period there is a couple of weeks until a CentOS
release is available. Since only the betas and CentOS release are generally
available to any person off the street I am looking at those being 'action
points' where the dot release period would be done. When a RHEL beta dot
release (example RHEL-6.6 beta) is announced, EPEL.dot would say that
packages to be updated in the next release are going to be accepted into
EPEL-dot-testing. Package owners who are needing or wanting to make major
changes in their EPEL package sets would target builds to that channel.
People can test as needed or at least be aware where they could have
tested. Sometime after the next dot release, CentOS releases their latest
'this is the state of CentOS build' which anyone needing to test latest
builds can get. This acts as a marker for when EPEL.dot will 'release' its
next tree which would be 1 month after the CentOS GA. During that time,
everything is rebuilt against the latest RHEL (to find any FTBS or ooops
they dropped libmuffin and I needed it) and at the end of the month
EPEL-6.7 is put out and EPEL-6.6 is set to be sent to archives after an
appropriate time. Like CentOS, EPEL-6 -> EPEL-6.6 and then EPEL-6.7.
In the case of last planned release (RHEL-5.12?), a different mechanism
could be used for when updates occur if there is enough people willing to
do the work. Otherwise packages go into that tree until EPEL ends building
for it.
Note only one tree is being built against. If someone wants to 'keep'
EPEL-6.5 running, they can grab the src.rpms from archives and do it
themselves on their own hardware.. EPEL only deals with RHEL current.
Have I made this clearer or muddier?
--
Stephen J Smoogen.