On 08/13/2014 09:23 AM, Kevin Fenzi wrote: > On Tue, 12 Aug 2014 21:05:07 +0200 > Stephen John Smoogen <smo...@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 _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel