plans for long term support releases?

[David Timms]

Jesse Keating wrote:
> On Tuesday 16 January 2007 01:04, Thomas M Steenholdt wrote:
>> Now that Core and Extras are going to be merged and the distro is
>> opening up to become even more (?) community driven, has anyone played
>> with the though of eventually releasing a long term support version of
>> Fedora?
>>
>> It could be a based on a staple snapshot of Fedora 7 + 4 months worth of
>> updates or whatever, at this point I'm more interested in hearing about
>> the idea than the details, which will surely follow, if i'm not the only
>> one who think this could be a good idea. Especially now that we're going
>> to do special server spins etc...
>>
>> Just a thought (hope this was not brought up ages ago and I just missed it)
> 
> There are a few things going against this.
> 
> A) Fedora is about new software.  Even in our released lines, we constantly 
> upgrade to new software to fix bugs, rather than backport.  Would you try to 
> change this philosophy in your extended release?
No. But I guess what you are saying is that without a truly wide range 
of test machines / configurations to test updates on before release, 
then backporting fixes is the safest way to go, yet most time expensive 
to perform ?

For example the external fc5 respin was excellent. since it was released 
maybe 4 months after the fc5 release, and had updates already included. 
It also meant you missed a lot of the early fun in things not quite 
working right, and saved time in getting a machine up2date from the 
moment you began installing.

Perhaps having an official respin perhaps 3/4 months post that only 
incorporates package updates that have been released by the project 
anyway would not be anywhere near as much work as the f 
rawhide->t1->t2->t3 upgrade to new packages ?

I could imagine that marking the respin as such would be suggestive of 
"the dont get vX.0, wait for vX.1 release" situation that you come 
across in other software. I don't remember what people thought of the 
rh7.1/2/3 releases in terms of should I play with .1 or wiat until .2 etc ?

> B) Fedora will now have a lifespan of 13~ months.  Anything more and you're 
> dangerously close to a RHEL like product, or a RHEL spinoff like CentOS.  
> These release every 18~ months, and are supported for 7~ years.  Wouldn't 
> that make a better Long Term Support distribution?  Still based on Fedora...
It may however be workload reasonable to choose specific fedori, which 
were used as a base {3/6} for a RHEL {4/5} etc, and have maintainers 
note the rhel security updates - with the intention of updating packages 
to fix security issues.

By security issues I guess we would include kernel/openssh/openssl as 
key areas. I imagine you would start to generate problems if you 
attempted to bump to a new apache/tomcat php/perl/python etc ? From what 
I have seen, bumping to a new python requires a fifth of the packages in 
fedora to be rebuilt.

> C) Community participation.  We tried this once before with Legacy, folks 
> weren't exactly beating down our doors to help out doing just security 
> updates for say FC3/4.  That's when interest really dwindled.  Lots of people 
> said "Sure, I'd love to get those updates, but I have no time/skill to help 
> out."
Updating kernel packages would be almost impossible IMHO unless you are 
an individual doing it all day. Community co-maintainers using RH 
mentors to verify / give hints for key packages might be a step toward 
solving this. It doesn't matter which software project, there is a 
serious amount of knowledge to be gained before you can do anything 
useful. A mentor {ie experienced with packaging / building that package} 
can offer hints on what to do/not do, on the right track etc.

Is it be possible for a comaintainer to add a {non-trunk?} patch {eg to 
fix hole Z}, and have the build system build the package, and allowing 
the comaintainer to test the build {updates-alpha} before requesting 
wider testing {in updates-testing} ?

> D) Sheer volume.  The size of Core+Extras is staggering.  Trying to track just 
> security issues across the entire thing is a full time job for at least one 
> person.  Actually DOING anything about the security issues is probably 
> another full time job.  Getting anybody to QA things is a joke, nobody wants 
> to run test updates on their stable system.  All the fun QA happens out in 
> rawhide land pre-release.  So you need maybe one or two full time QA folks 
> with access to a multitude of hardware/software configurations.  If you don't 
> do this for all software, surely you'll piss people off by not updating the 
> software THEY care about.  It will happen.
With extras, you are expected as a package contributor / maintainer to 
subscribe to the appropriate mailing lists of the package you sponsor, 
to be informed of releases and security problems, and attempt to solve 
them in a timely manner {3 weeks}. If the workload is shared around in 
to more maintainers, then it would seem to help in not making huge 
workloads for individuals. I imagine this concept will be stretched to 
core packages, and that various original core packages will be able to 
have community maintainers in the future.

I still don't know though how you can guarantee that I packager doesn't 
do bad things {introducing security problems, enabling an external repo 
etc}. I guess ACL's are good, and something could be in place to ensure 
that the generator of a patch can't build and sign and push a package 
without {trusted} people verifying their work {aka lkml signed off by 
x,y,z}, and having eg at least {some number} of users confirm a 
updates-alpha package seems oeprational before wider testing in 
updates-testing, and then not releasing to updates before {some number 
x10} have reported success with the -testing package.

I think the long-term release concept comes from management side who 
remember eg novell file/print servers that never had problems and 
regularly had 6 months or more of uptime, and ran until you filled the 
disk space up. But in the internet connected wider world, perhaps this 
is really no longer possible ?

In terms of selinux and firewalls, would it be a possibility to release 
security ~corks~ for older releases by updating selinux rules or 
firewalls to block each published security {eg CVE} issue, rather than 
actually updating the package ? If such a solution is possible {eg deep 
packet inspection as decent hardware firewalls do}, it must also be 
possible to perform same in software.

Oops, this is very long, hope there is something here that isn't drivel 
- for reading / commenting.

DaveT.