EPEL Notes from .next discussion.

[Kevin Fenzi]

On Tue, 12 Aug 2014 21:05:07 +0200
Stephen John Smoogen <smooge at 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 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? 

> * Policy change that allows for regular major changes in EPEL.
>   * Can't update at any times.
>   * Can make incompatible changes on the next point release of
> RHEL->CentOS.
>   * Example: When RHEL7.1 comes out we have a 30 day window to get
> packages updated and new packages in that make incompatible changes.

The problem with that is that it's different than what we have always
done before. I suspect many people will be burned by incompatible
changes at that window. 

>     * Archive 7.0.  The toplevel 7 tree is a symlink to whatever point
> release is latest.

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

> * 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. 
 
kevin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/epel-devel/attachments/20140813/f647e6dd/attachment.sig>