epel task force?

[Thorsten Leemhuis]

On 13.02.2008 20:57, Stephen John Smoogen wrote:
> [...]
> It was the above that got me thinking about a 'Rawhide/Chewbone'
> repository. The Fedora owner will want an easy way to know if their
> package is building or not. Having an 'automated' build process that
> doesn't 'pollute' testing with un-tested packages would be better for
> them to know that their package can or cannot be done without
> problems. The EPEL helper would work on finding which versions are
> best to go into testing/production so that those areas are fairly to
> very stable. But my idea has a lot of holes in it... I would probably
> not call the 'test-tree' anything to do with EPEL more like
> monkey-poo.

I'd say a "rawhide tree" has some benefits, but it only makes sense in
the early days of RHEL. E.g. during a RHEL beta and (maybe) the initial
days of a RHEL release.

Take for example this precise moment. FC6 (which RHEL5 is based on) is
EOL (and thus FE6 as well) -- rebuilding those packages doesn't make
much sense. Building F8 or rawhide packages for RHEL5 in a EPEL rawhide
could work, but lots of packages were renamed (thus the BRs would need
to be adjusted), organized in different ways (package splits), useless
(fuse, hunspell) or depend on libs or apps newer than the ones in RHEL5.

IOW: that would mean much work to fix all those small details while
keeping the repo in a sane state. That works if the maintainers of the
packages in question want to see the package in EPEL, but without that
base I tend to say it's to much work for EPEL right now and not worth
the trouble. There are bigger problems we need to solve (we need bodhi
and koji, as a lot of the newer Fedora contributers don't want to deal
with/learn plague).

An EPEL task force with a rawhide like tree during RHEL6 beta on the
other hand could get a whole lot of packages into EPEL6 -- that's IMHO a
solid grow path for EPEL where we can maintain a proper quality of our
packages/our repo. Sure, getting more packages quickly into EPEL5 would
be nice, but doing it to fast will only hurt. I'd say we will get more
packages into EPEL5 (and maybe even EPEL4) as a side effect of the EPEL
task force work, even if they might focus on EPEL6 initially (which they
IMHO should as soon as RHEL6 beta is out, as that is the best moment to
fill the EPEL6 repos).

CU
knurd