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.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
