EPEL/Tasks/LongTerm
From FedoraProject
Contents |
Overview
| Next steps | |||||
| <rowspan=2> Miscellaneous Long Term ideas | EPEL/Tasks/LongTerm,, from="^ | EPEL/Tasks/LongTerm,, from="^ | EPEL/Tasks/LongTerm,, from="^ | EPEL/Tasks/LongTerm,, from="^ | EPEL/Tasks/LongTerm,, from="^ |
| EPEL/Tasks/LongTerm,, from="^ |
Summary
Miscellaneous tasks we should work on in the longer term
Owner
None
Completion Level
standing
Target Date
standing
Last updated
--
Next steps
- can packages that are in RHX be in EPEL?
- implications by using EPEL -- Seems some people are concerned that RH will refuse to support systems on which EPEL gets used. We should have a statement for them.
- EL-Updates for buildsys repos -- We use RHEL5 without any updates currently for building; we should try to get the updates into the repos that are used by the buildsys/mock.
- EL only packages -- mether in #fedora-extras: "the faq on epel says that someone can maintain a package in epel without even having a branch for fedora. Has that been discussed? I would have expected us to mandate that a branch be created be fedora in exchange for using fedora infrastructure". ThorstenLeemhuis-070211: We could have a "EL only packages need to be ACKed by the EPEL Steering Committee rule if we want
- dependency across products -- What happens if a users tries to install a EPEL package on RHEL5 client, if that package depends on another package that is part of the RHEL5 server (or vice versa)?
- define EPEL target userbase -- Will we be answering who the EPEL customers are thought to be to distinguish it from other customer bases; See also https://www.redhat.com/archives/epel-devel-list/2007-May/msg00055.html
- Investigate single RHEL subscription for EPEL maintainers -- quaid is Investigating...
- EPEL release managers -- knurd had the idea to form a "EPEL release managers" group with a handful of trusted contributors that takes care of maintaining the EPEL repo as a whole -- they should get access everywhere and are encouraged to use it for the best of the repo. E.g. fix important bugs or dependency issues quickly in case the the package owner doesn't do it in time. That different from Extras, where we sometimes even for important bugs wait weeks before we touch other peoples packages.
- ExcludeArch TrackerBugs for EPEL?
Details
This page lists miscellaneous small and big tasks that the EPEL SIG should work on sooner or later. Feel free to add stuff here -- best place is likely the "Next steps" section directly, as anything that's written there is integrated on the task front page.
