On 08/13/2014 09:23 AM, Kevin Fenzi wrote:
On Tue, 12 Aug 2014 21:05:07 +0200
Stephen John Smoogen <smooge(a)gmail.com> wrote:
> At FLOCK this year, I did a short workshop on what was labeled
> EPEL.Next. At that we went over a bit of what EPEL has done in the
> past, what its current challenges are, and what could be its future.
> Toshio Kuratomi was great in capturing what was said at the meeting
> and
...snip...
> For CENTOS7: the epel repofile will be shipped directly with centos
> for the first time.
Note that this will be in centos-extras (but thats enabled by default,
so just a nitpick)
...snip...
> Where are we going?
> Pain Points:
> * Inability to yum downgrade because only include one old package in
> the updates tree
Yeah, there were some recent mash patches that might help here.
Allowing us to keep 1 or 2 older ones too.
...snip lots of problems...
> Ideas to deal with Pain
> * Get RHEL licenses for contributors. There is a process but it
> takes a long while because of the tax problems for giving it to
> people. Current procedure is that we get requests, we give the names
> to a person inside of RH and then they eventually get back to us with
> licenses.
We are working to revamp/improve this.
> * Let's create EPIC: separate repo. 3 year lifespan instead of 10
> year, rhel life cycle.
> * Debian Volatile repository and also Debian Backports. These repos
> contain newer versions of packages, even for Debian Stable. Good for
> packages which change all the time.
> * Debian also has protection mechanism that says no major or no
> major.minor version updates in apt (their yum equivalent).
> * Red Hat already releases different lifecycle repositories (layered
> products). Why not replicate what they do.
> * What about implementing EPEL as a set of projects like Fedora
> Playground?
> * Would change the guarantees and expectations of EPEL *quite* a
> bit.
> * Maybe as the way to implement EPIC rather than EPEL.
I think we really do need to look at another repo for things that are
so rapid. It's going to be very hard to change user expectations for
EPEL now, since it's already entrenched.
I don't think these two options are exclusive.
A second repository would certainly help keep original expectations of
epel in place, and is a good idea.
EPEL itself still provides a base for many projects, and could improve
upon existing user expectations.
I guess for my uses the parallel installable stuff works fine. I
know
thats not the case for others though, so a more rapidly moving repo
would be better for them. I wonder if it wouldn't be good to coordinate
with CentOS folks and see where such a repo would make the most sense?
I certainly think we should do this. It would benefit both our SIG
communities as well as other interested users.
The idea of having a release tree was an interesting one. However,
it's
going to be a lot more work. If we are saying "here's EPEL 7.0 release
repo" we would need to make sure it's well tested and has no issues.
ie, we would need to go through much of what Fedora does for a release.
Do we have any QA folks at all? ;)
I believe there's an effort for common QA underway. This would be an
area where we (CentOS and Fedora/EPEL) could coordinate.
I think more practical might be the idea of shipping multiple old
versions in the existing repos.
> * Formalize the governance of EPEL.
> * Written policies of some sort for decision making
> * Elections?
> * Problems to solve:
> * Don't want to just listen to the people who are loudest
> * Don't want to just listen to the people who have been around the
> longest
I'd prefer to avoid voting.... those that do the work should have the
most input. Or perhaps those that show up. ;) There was some talk about
trying to do meetings again. I gave up in dispair last time I tried,
but would happily attend if someone else wants to organize them.
> * Do we want automated testing of EPEL? yes. get it working on
> whatever subset you can and we'll go on from there.
Yeah, I would love some automated testing.
This should be possible in the reasonably near future.
> * Move to CentOS as build system? Gives us additional arches.
Yeah, if they do a 32bit x86 and 32bit arm, that would give us more
arches.
32bit x86 is definitely happening. I'm not certain about 32bit arm,
largely because of the largely varied hardware support requirements and
uboot.
64bit arm(uefi backed) is certainly on our roadmap.
--
Jim Perrin
The CentOS Project |
http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77