Hi Everyone,
There have already been some really good suggestions to this thread! its
nice to see some activity and interest for the ExterpriseExtras
potential project.
Some of my comments....
1) There are 4 channels per {Scientific/Centos} Enterprise Linux
extras
extras-devel
extras-testing
extras-updates
[proposed naming convention: extras-2el, extras-3el, extras-4el, extras-5el]
The idea is nice, but I think this is going to be much to complicated.
I agree, we'll need to stay with a form of continuous release for each
package.
Also, i see a major functional overlap in the 'extras' and
'extras-updates' repo, surely since no one is supporting the 'base'
there needs to be an effort to ensure that people install and use only
the latest released packages.
Secondly, extras-devel and extras-testing seem to have a very large
overlap as well,
2) Extras are produced/updated on a 6 month basis.
That might be a nice to have.
I dont think Fedora Extras has either the packaging discipline nor the
QA support to provide a proper Release System. We're going to save
everyone a lot of work and provide the users with a better experience
sticking to the idea of continuous release.
4) Extras-testing is where fixes to the current locked down version is
completed before being pushed to extras/extras-updates
We IMHO need some kind of extras-testing in the long term.
I would argue that the extras-testing repo comes up first, and based on
a set of defined high-water-marks or a pre-defined specification match,
packages be moved from extras-testing to extras-stable.[1]
[...]
But as I said: I thinks it's to complicated. So I put up the following
up for discussion - it's just and idea, I'm not really sure it it doable
(or worth realizing):
Two devel repos for now:
* el-devel
* el-devel-1 (after RHEL5)
* el4
* el5
el-devel -> Rolling release scheme for the current version of
{RHEL|CentOS}, repo depends on el{current}. Repo gets into a feature
freeze round about two weeks before each next {RHEL|CentOS} dot release
update (4.4 -> 4.5 or 5.0 -> 5.1) and packages get copied over to the
stable repo when that dot release get's published
because the 'rolling' devel version isnt developed in the wide-open
spaces, we have no target. Hence, the latest Fedora Release == 'rolling'
EL devel tree. We dont need to build anything for that under the
EnterpriseExtras scope. At beta time, its just another release, so
should inherit a DistTag, and everything go into extras-testing.
el-devel-1 -> Rolling release scheme for the ((current RHEL version)-1)
-- that would be RHEL3 currently (no, we probably don't start building
for RHEL3, it's just to explain the scheme) and will be RHEL4 soon. Same
handling as el-devel. And no, there shouldn't be any el-devel-2 (fixme:
where to test updates later when RHEL6 is out?).
Here is an alternative plan :
EL3/{stable,testing}/{arch}/
EL4{stable,testing}/{arch}/
would that be nicer/cleaner/function(er?) ?
el5 and el4 -> contain the packages for {RHEL|CentOS}{45}. Packages are
locked down there and only get updated for security reasons (after they
were tested or in devel for two (?) days) and on each dot release synced
from devel.
I am not sure how this 'locked down' approach will work, Are you
proposing that someone does a one time snapshot of FE{x} and only
packages that get included in that snapshot be allowed updates ?
- KB
[1] I looked but was unable to find any QA process or QA guideline for
each package release, within the FE scope of things. Could someone point
me to this, if it exists ? if not, we're going to need to start writing
this up. Well before packages actually start building.
--
Karanbir Singh : http://www.karan.org/ : 2522219@icq
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
