[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Initial Proposal for doing Enterprise Extras

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

   [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 :


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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]