Stuart Herbert wrote:
> b) Release trees have a nasty habit of picking up last minute changes
> (such as gcc 4.1) to suit the release, not stability.
Gcc 4.1.1 wasn't a last minute change.
I can't agree with you there. It doesn't matter how many months of
planning and work you guys put into getting gcc-4.1 fit for stable.
If you're doing it off in your own little corner of the world, and
then springing it on the rest of us just days before the release
happens, then to the much larger dev community, it comes as a last
minute change.
The 3-4 weeks of releng filing a ton of "doesn't build with gcc-4.1.1" bugs
wasn't a big enough clue? :) Also, the arch teams (or at least the arch's
release coordinator...if they didn't tell the rest of their team, that's not
releng's fault) that were moving to it and people in base-system working on it
were "in the know".
The "release tree" isn't really for minimal breakage.
But that is what Steve (who started this thread) asked for. And what
he has asked for in his previous thread too.
Well, wolf31o2 has been floating around this idea for quite a while, and I'm
speaking from the POV of his ideas. The "minimal b0rkage" tree is far less
likely to happen due to the extra manpower involved.
The *real* intent (at
least from my POV) is to have a non-moving target for vendors to
certify their
software against (wouldn't it be nice for Oracle to be actually
supported on
Gentoo 2007.0 or something like that?),
Well, there's a dichotamy here. Sun were able to certify Gentoo
against their hardware without such a tree. Has anyone approached
Oracle and asked them what their actual requirements are? Do Oracle
actually want to certify Oracle on Gentoo at all?
Certifying hardware and software are 2 completely different things. Also, I'm
not sure that Sun certifying their hardware even meant anything. The T2000 dev
box has been seeing random lockups and other weird problems, although, that may
be related to the fact that it recently "lost" 16GB of memory due to an error
detected by the diagnostics. As for the Oracle example, it was just that...an
example.
and so admins don't have to do the
"upgrade dance" once a week or even every day (like I do).
A slower-moving tree will substantially reduce this amount of work,
but it isn't going to go away, unless your boxes are on a private
network w/ no local security threats at all.
There'll always be GLSA's to respond to. That's another issue that
needs to be handled w/ a slow-moving tree. Are you going to restrict
changes in the slow-moving tree only to changes against a GLSA?
Yes, that's part of wolf31o2's idea. The tree would be "non-moving" except for
GLSA's and any dependencies required by the updated version of the
security-affected package.
The "non-stagnant" nature of Gentoo isn't the only reason that people use
Gentoo. People use Gentoo for the configurability and customizability. As
someone who admins more than a handful of Gentoo servers, I would
absolutely
*love* the combo of Gentoo's flexibility and a non-moving tree to make
upgrades
easier to deal with.
I honestly don't think you're ever going to get that out of Gentoo,
because of the lack of backporting. Can you live with a slower-moving
tree? Or do you personally really need a non-moving tree?
A slower-moving (or "non-moving" with security updates) tree is perfect for me,
and I'm sure for many other people as well.
--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Installer Project
Today's lesson in political correctness: "Go asphyxiate on a phallus"
--
gentoo-dev@gentoo.org mailing list
