Initial Proposal for doing Enterprise Extras

[Karanbir Singh]

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 at icq