Re: [gentoo-dev] Re: Versioning the tree

[Andrew Gaffney]

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@g.o mailing list