[gentoo-dev] GLEP 19, reloaded (again)

[gentoo-dev] GLEP 19, reloaded (again)

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 2854 bytes --]

OK, as msot of the other folks who attended LWE will attest, a stable
portage tree was the number one most-requested/discussed feature at the
booth.  So, here's a stab at summarizing the other flame^Wthread and
suggesting some next steps...

First off, some folks tried to bolt on some features to the GLEP 19.
Things such as XML-based ChangeLogs might be nice, but they're outside the
scope of this GLEP.  So, I'm ignoring them for purposes of this discussion.

Second, there was some question about how often the tree would be updated.
The GLEP doesn't really specify this, but I think once a year is a
reasonable timeframe.

Third, many folks want long-term support of these releases.  I *don't*
think this is viable and am not willing to personally sponsor this.  A core
component of this GLEP is that we will *not* be backporting security fixes.
(at least not as a rule)  We will be relying on the versions that the
original authors provide except in very unusual circumstances.  The reason
for this is simple -- we don't have the resources to guarantee that we can
backport things (and, more importantly, guarantee that they'll work right
once backported)  Suppporting a profile for four or more years almost
guarantees you'll be doing a lot of backporting.  I don't plan to
incorporate long-term support as part of this GLEP.  That might, however,
be an excellent opportunity for commercial companies with greater finanial
resources than us.  

Fourth, the GLEP currently recommends use of a 'stable' keyword.  A
number of folks have suggested using a custom profile instead.  This is
less intrusive and doesn't require any changes to portage to make it work.
It's also easier to maintain since everything is in one file.  The main
problem here is that all packages need to be explicitly listed in this file
in order to be of any use.  If we can get enough developer buy-in and maybe
even add some repoman checks, this might be easier to manage...

Finally, the current GLEP doesn't really address how to ensure a minimum
life for all ebuilds in the tree.  I'm open to suggestions on this, but the
best idea I've heard so far is using a separate rsync module and removing
the --delete option from the command used to populate it.

So, at this point, I'm suggesting three changes to the GLEP:

1) specify annual updates for the stable tree
2) replacing the stable keywording stuff with stable profiling stuff
3) adding a separate rsync module for the stable portage tree (or one for
   each release of the stable portage tree)

With that, comments/suggestions are welcome.  Please keep in mind that this
is a very focused GLEP designed to provide a stable tree and predictable
expiration of ebuilds to our users.  It is not intended to propose other
far-reaching changes to Gentoo Linux.

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Dylan Carlson]

On Sunday 08 August 2004 2:51 pm, Kurt Lieber wrote:
> So, at this point, I'm suggesting three changes to the GLEP:
>
> 1) specify annual updates for the stable tree
> 2) replacing the stable keywording stuff with stable profiling stuff
> 3) adding a separate rsync module for the stable portage tree (or one
> for each release of the stable portage tree)
>
> With that, comments/suggestions are welcome.  Please keep in mind that
> this is a very focused GLEP designed to provide a stable tree and
> predictable expiration of ebuilds to our users.  It is not intended to
> propose other far-reaching changes to Gentoo Linux.
>

Most of that sounds good to me, particularly the profiling.   Godspeed.

However, if we propose using a different tree, repo or branch tags for 
enterprise, I'm not a big fan of that approach.  IMO it should be taken 
incrementally; that is, get it to work in the existing tree w/ new 
profiles, and if there is some implementation problem getting enterprise 
to co-exist with everything else, move it out.  

The only other reason I can see justifying a new tree/repo/branch would be 
if the enterprise team itself was a totally separate organization of 
developers for certification reasons.  One developer flipping between two 
trees both for the sake of Gentoo is duplicating a lot of effort.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]

On Mon, Aug 09, 2004 at 01:04:49AM -0400 or thereabouts, Dylan Carlson wrote:
> However, if we propose using a different tree, repo or branch tags for 
> enterprise, I'm not a big fan of that approach.  IMO it should be taken 
> incrementally; that is, get it to work in the existing tree w/ new 
> profiles, and if there is some implementation problem getting enterprise 
> to co-exist with everything else, move it out.  

The only "extra" thing we've talked about so far is a separate rsync module
that has the --delete option removed (but is otherwise identical to the
gentoo-portage module)

Come up with a better way to *guarantee* ebuilds stay in the tree for a
minimum length of time and I'm all for it.  

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

On Mon, 2004-08-09 at 05:52, Kurt Lieber wrote:
> The only "extra" thing we've talked about so far is a separate rsync module
> that has the --delete option removed (but is otherwise identical to the
> gentoo-portage module)
> 
> Come up with a better way to *guarantee* ebuilds stay in the tree for a
> minimum length of time and I'm all for it.  

Fork into a completely new module.

Take any and all ebuilds which are marked as stable for a particular
arch, remove any ~arch keywords, and split it to a gentoo-$version
module.  Since it is a separate module, the ebuilds will always be
there.  Since it was taken from the release snapshot for each arch,
it'll also match what is done on the release media, making bug hunting
even easier.  You use ~arch for any backports or bug fixes that do come
along, but don't guarantee either.

Here, we're using the SYNC variable to control the tree, rather than a
profile.  This means we can support multiple profiles on the same tree
easily, and also keeps ebuilds around for as long as we keep the tree
around.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

On Mon, Aug 09, 2004 at 10:21:09AM -0400 or thereabouts, Chris Gianelloni wrote:
> Fork into a completely new module.

I don't think this is a very good idea for reasons that I'll discuss below.

> Take any and all ebuilds which are marked as stable for a particular
> arch, remove any ~arch keywords, and split it to a gentoo-$version
> module.  

Agreed, though I don't see a real need to remove ~arch ebuilds.

> Since it is a separate module, the ebuilds will always be
> there.  Since it was taken from the release snapshot for each arch,
> it'll also match what is done on the release media, making bug hunting
> even easier.  

[side note] the releases of the tree are not tied to the releases of our
liveCD/package sets.[/side note]

> Here, we're using the SYNC variable to control the tree, rather than a
> profile.  This means we can support multiple profiles on the same tree
> easily, and also keeps ebuilds around for as long as we keep the tree
> around.

One think that I think *everyone* agrees on is that any stable tree needs
to be regularly updated with security fixes.  With this in mind, I'm
concerned with trying to maintain multiple separate SYNC modules.  We'd
have to upgrade each one with every GLSA, thus doubling or tripling the
amount of CVS work needed each time.

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Corey Shields]

On Monday 09 August 2004 19:01, Kurt Lieber wrote:
> One think that I think *everyone* agrees on is that any stable tree needs
> to be regularly updated with security fixes.  With this in mind, I'm
> concerned with trying to maintain multiple separate SYNC modules.  We'd
> have to upgrade each one with every GLSA, thus doubling or tripling the
> amount of CVS work needed each time.

One quick hack is to just sync the full tree to the stable tree without the 
--delete option, so that everything old stays and we get all of the new 
programs.  Any updates we want to activate would need to be modified in the 
profiled mask files.  No CVS work for the tree involved here.

-C

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Olivier Crete]

On Mon, 2004-08-09 at 19:13 -0500, Corey Shields wrote:
> On Monday 09 August 2004 19:01, Kurt Lieber wrote:
> > One think that I think *everyone* agrees on is that any stable tree needs
> > to be regularly updated with security fixes.  With this in mind, I'm
> > concerned with trying to maintain multiple separate SYNC modules.  We'd
> > have to upgrade each one with every GLSA, thus doubling or tripling the
> > amount of CVS work needed each time.

Having a stable system double or tripes the amount of work every time
anyways because we need to test on each "stable tree".. Newer versions
might not work anyways.. CVS work is very little compared to testing
work.

> One quick hack is to just sync the full tree to the stable tree without the 
> --delete option, so that everything old stays and we get all of the new 
> programs.  Any updates we want to activate would need to be modified in the 
> profiled mask files.  No CVS work for the tree involved here.

The problem with that is that the tree for stable users will start
growing and they will start getting lots of old crap...  And it doesnt
give us separation of "base" and "updates" that I think many "corporate"
types want.. 

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]

On Mon, Aug 09, 2004 at 09:04:48PM -0400 or thereabouts, Olivier Crete wrote:
> Having a stable system double or tripes the amount of work every time
> anyways because we need to test on each "stable tree".. Newer versions
> might not work anyways.. CVS work is very little compared to testing
> work.

I've said this before and I'll say it again.  This GLEP has NOTHING to do
with QA.  No additional QA is going to be done on this stable tree above
and beyond what we already do.

Yes, we need more QA and yes, the stable project needs an extra dose of it.
That's a job for a separate GLEP, however.  

This GLEP is the *first step* towards an enterprise/stable version of
Gentoo.  It is not intended to be an all-encompassing solution to it.

> The problem with that is that the tree for stable users will start
> growing and they will start getting lots of old crap...  And it doesnt
> give us separation of "base" and "updates" that I think many "corporate"
> types want.. 

That's controlled through the profile.  Save a copy of your profile when
you first create the server and you have your "base" system.

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]

On Mon, 2004-08-09 at 21:04, Olivier Crete wrote:
> Having a stable system double or tripes the amount of work every time
> anyways because we need to test on each "stable tree".. Newer versions
> might not work anyways.. CVS work is very little compared to testing
> work.

Exactly.

This is why I think separate trees is the way to go.  If you're already
having to test for *every* ebuild, why make it more complex by having
TONS of "stable" ebuilds in the same tree.  With a separate tree, one
can simply test against the packages IN THAT TREE AND NO OTHER and get
an accurate test of what the user would see.

> > One quick hack is to just sync the full tree to the stable tree without the 
> > --delete option, so that everything old stays and we get all of the new 
> > programs.  Any updates we want to activate would need to be modified in the 
> > profiled mask files.  No CVS work for the tree involved here.
> 
> The problem with that is that the tree for stable users will start
> growing and they will start getting lots of old crap...  And it doesnt
> give us separation of "base" and "updates" that I think many "corporate"
> types want.. 

arch is base... ~arch is updates...  This is simple.  For people that
want all the updates, they set ACCEPT_KEYWORDS to ~arch.  For people
that want to verify updates, they simply re-KEYWORD the package once
they've approved it.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

On Tue, Aug 10, 2004 at 09:27:27AM -0400 or thereabouts, Chris Gianelloni wrote:
> This is why I think separate trees is the way to go.  If you're already
> having to test for *every* ebuild, why make it more complex by having
> TONS of "stable" ebuilds in the same tree.  With a separate tree, one
> can simply test against the packages IN THAT TREE AND NO OTHER and get
> an accurate test of what the user would see.

With a separate profile, one can simply test against the packages IN THAT
PROFILE AND NO OTHER and get an accurate test of what the user would see.

> arch is base... ~arch is updates...  This is simple.  For people that
> want all the updates, they set ACCEPT_KEYWORDS to ~arch.  For people
> that want to verify updates, they simply re-KEYWORD the package once
> they've approved it.

This would require us to dramatically revamp the process used to issue
GLSAs.  For "mainstream" users, we'd have to tell them to look for arch
ebuilds.  For "stable" users, we'd have to tell them to look for ~arch
ebuilds.  Mass confusion ensues.

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]

On Mon, 2004-08-09 at 20:01, Kurt Lieber wrote:
> > Take any and all ebuilds which are marked as stable for a particular
> > arch, remove any ~arch keywords, and split it to a gentoo-$version
> > module.  
> 
> Agreed, though I don't see a real need to remove ~arch ebuilds.

There's no need, at all.  I was simply suggesting it, since if we don't
seem them "stable" in the tree, why should they be in a stable tree? 
*grin*

> > Since it is a separate module, the ebuilds will always be
> > there.  Since it was taken from the release snapshot for each arch,
> > it'll also match what is done on the release media, making bug hunting
> > even easier.  
> 
> [side note] the releases of the tree are not tied to the releases of our
> liveCD/package sets.[/side note]

This I don't understand at all.  Why maintain 2 separate release cycles?

> > Here, we're using the SYNC variable to control the tree, rather than a
> > profile.  This means we can support multiple profiles on the same tree
> > easily, and also keeps ebuilds around for as long as we keep the tree
> > around.
> 
> One think that I think *everyone* agrees on is that any stable tree needs
> to be regularly updated with security fixes.  With this in mind, I'm
> concerned with trying to maintain multiple separate SYNC modules.  We'd
> have to upgrade each one with every GLSA, thus doubling or tripling the
> amount of CVS work needed each time.

So the idea is to create exactly *one* stable tree?  How is this any
different than just doing better with our current tree?  Honestly, from
what I've heard from our users, they want package stability (as in
freeze) much more than anything else.  This is *exactly* why I recommend
tying the "stable" trees with the releases.  I'm not sure I can
understand how doing anything else really gives us anything other than
adding more workload for the simple fact of adding workload.  Having a
"stable" tree that still moves, and only providing a single "stable"
tree doesn't seem to be an improvement from what we have at all.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 1875 bytes --]

On Tue, Aug 10, 2004 at 09:23:08AM -0400 or thereabouts, Chris Gianelloni wrote:
> > [side note] the releases of the tree are not tied to the releases of our
> > liveCD/package sets.[/side note]
> 
> This I don't understand at all.  Why maintain 2 separate release cycles?

The release schedule for liveCDs/package sets is 4/year.  We're talking
about an annual cycle here.

> > One think that I think *everyone* agrees on is that any stable tree needs
> > to be regularly updated with security fixes.  With this in mind, I'm
> > concerned with trying to maintain multiple separate SYNC modules.  We'd
> > have to upgrade each one with every GLSA, thus doubling or tripling the
> > amount of CVS work needed each time.
> 
> So the idea is to create exactly *one* stable tree?  How is this any
> different than just doing better with our current tree?  Honestly, from
> what I've heard from our users, they want package stability (as in
> freeze) much more than anything else.  This is *exactly* why I recommend
> tying the "stable" trees with the releases.  I'm not sure I can
> understand how doing anything else really gives us anything other than
> adding more workload for the simple fact of adding workload.  Having a
> "stable" tree that still moves, and only providing a single "stable"
> tree doesn't seem to be an improvement from what we have at all.

No -- we would have one tree for each release, but the difference is that
you're talking about using the tree to control versions and I'm talking
about using profiles to control versions.  With the current proposal, the
*only* difference between the main rsync module and the "stable" module is
that the latter has the --delete option removed.  This is to ensure ebuilds
remain in the tree for a predictable period of time.  It has nothing to do
with package versioning.

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2360 bytes --]

On Tue, 2004-08-10 at 09:24, Kurt Lieber wrote:
> The release schedule for liveCDs/package sets is 4/year.  We're talking
> about an annual cycle here.

At no point have I ever seen a cycle mentioned for the "stable" tree,
until now.  Also, I've stated in many threads before that -releng is
more than willing to work with whomever to make changes to the release
cycle to best serve the needs of our users.  UNFORTUNATELY, it seems
that people don't read most of the threads that go on here, so I have to
repeat myself quite a bit to get this out to everyone interested... ;]

> > So the idea is to create exactly *one* stable tree?  How is this any
> > different than just doing better with our current tree?  Honestly, from
> > what I've heard from our users, they want package stability (as in
> > freeze) much more than anything else.  This is *exactly* why I recommend
> > tying the "stable" trees with the releases.  I'm not sure I can
> > understand how doing anything else really gives us anything other than
> > adding more workload for the simple fact of adding workload.  Having a
> > "stable" tree that still moves, and only providing a single "stable"
> > tree doesn't seem to be an improvement from what we have at all.
> 
> No -- we would have one tree for each release, but the difference is that
> you're talking about using the tree to control versions and I'm talking
> about using profiles to control versions.  With the current proposal, the
> *only* difference between the main rsync module and the "stable" module is
> that the latter has the --delete option removed.  This is to ensure ebuilds
> remain in the tree for a predictable period of time.  It has nothing to do
> with package versioning.

So we move no closer to our goal of providing a stable/frozen
installation environment than to ensure ebuilds don't disappear from the
tree?  How is this really beneficial to our users?  Is there a reason
for completely separating the idea of a "stable" tree from our already
established releases?  Is there a reason why they cannot both be
modified to work together and do what is best for our users, gives them
the most choice, and gives them what they're actually asking for?

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Jeremy Maitin-Shepard]

[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

Chris Gianelloni <wolf31o2@gentoo.org> writes:

> [snip]

> So we move no closer to our goal of providing a stable/frozen
> installation environment than to ensure ebuilds don't disappear from the
> tree?  How is this really beneficial to our users?  Is there a reason
> for completely separating the idea of a "stable" tree from our already
> established releases?  Is there a reason why they cannot both be
> modified to work together and do what is best for our users, gives them
> the most choice, and gives them what they're actually asking for?

If we make sure to follow the convention throughout the tree that
revisions are only used for bug fixes (which is essentially the current
convention, with a few exceptions), then a `stable' release profile
could be automatically generated from the normal release profile using
an automated tool that, for every package included in the release,
simply hard masks later versions (but not later revisions) of the
package.

If it is desirable that future packages added to the tree be blocked as
well, the `stable' profiles could be augmented with a file that would
limit the user to only those packages listed in this file.

-- 
Jeremy Maitin-Shepard

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 1881 bytes --]

On Tue, Aug 10, 2004 at 09:55:31AM -0400 or thereabouts, Chris Gianelloni wrote:
> At no point have I ever seen a cycle mentioned for the "stable" tree,
> until now.  

Please re-read the original post of this thread, then.

> Also, I've stated in many threads before that -releng is more than
> willing to work with whomever to make changes to the release cycle to
> best serve the needs of our users.  

I've had a different experience when interacting with releng, *especially*
when it comes to changing the release cycle, so I'm not as optimistic as
you are.  I'm open to discussing it, however, so feel free to contact me
offline.

> So we move no closer to our goal of providing a stable/frozen
> installation environment than to ensure ebuilds don't disappear from the
> tree?  

Yes, we do.  Ebuilds in the "stable" tree are never deleted.  Ever.  We
have one "stable" tree per release and they can be archived forever.

> How is this really beneficial to our users?  Is there a reason for
> completely separating the idea of a "stable" tree from our already
> established releases?  Is there a reason why they cannot both be modified
> to work together and do what is best for our users, gives them the most
> choice, and gives them what they're actually asking for?

That presupposes that the current proposal doesn't do provide our users the
most choice and/or what they're asking for.  I disagree with this
presupposition.

If this GLEP ends up getting approved and adopted, I see no problem
synchronizing the annual release of this stable tree with one of the
four/whatever annual releases of the livecd/package CDs.  I'm just not
going to let releng requirements get in the way of doing what is best for
this project.  If we can have the two happily co-exist without sacrificing
the needs of the server project, great.

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2884 bytes --]

On Tue, 2004-08-10 at 19:24, Kurt Lieber wrote:
> I've had a different experience when interacting with releng, *especially*
> when it comes to changing the release cycle, so I'm not as optimistic as
> you are.  I'm open to discussing it, however, so feel free to contact me
> offline.

I once had a bad experience with a police officer who was an asshole. 
By extension, all police should not be trusted. *grin*

Not even attempting a conversation gets nowhere.  I am telling you right
now (actually in the other post) that releng *is* willing to work on the
release cycles.  To be honest, I was going to suggest that we switch to
a 6-month release cycle for our release media, simply to give more time
between releases and to ease the pressure on arch maintainers and leads
who work with releng.  It also removes any chance for excuses on why
anyone doesn't meet the release deadlines.  I was planning on having
this voted on first by releng, then by the managers, and implemented for
2005.X and beyond.

> > So we move no closer to our goal of providing a stable/frozen
> > installation environment than to ensure ebuilds don't disappear from the
> > tree?  
> 
> Yes, we do.  Ebuilds in the "stable" tree are never deleted.  Ever.  We
> have one "stable" tree per release and they can be archived forever.

This is exactly what I was saying.  I think the confusion was us both
using different terminology to describe the same thing.  This is exactly
what I was describing.

> > How is this really beneficial to our users?  Is there a reason for
> > completely separating the idea of a "stable" tree from our already
> > established releases?  Is there a reason why they cannot both be modified
> > to work together and do what is best for our users, gives them the most
> > choice, and gives them what they're actually asking for?
> 
> That presupposes that the current proposal doesn't do provide our users the
> most choice and/or what they're asking for.  I disagree with this
> presupposition.

Actually, we were both talking about the same thing, but describing it
differently.  Sorry for the confusion.

> If this GLEP ends up getting approved and adopted, I see no problem
> synchronizing the annual release of this stable tree with one of the
> four/whatever annual releases of the livecd/package CDs.  I'm just not
> going to let releng requirements get in the way of doing what is best for
> this project.  If we can have the two happily co-exist without sacrificing
> the needs of the server project, great.

Would it be too horrible to change to a 6-month release?  Then we could
coincide the information between us both and not have 2 separate
processes for doing essentially the same thing.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Dylan Carlson]

On Wednesday 11 August 2004 10:23 am, Chris Gianelloni wrote:
> Would it be too horrible to change to a 6-month release?  Then we could
> coincide the information between us both and not have 2 separate
> processes for doing essentially the same thing.

I agree with this and have suggested it in the past.   I think six months  
gives us enough time to package a release, and allows enough time for 
significant changes to show up to make releases worthwhlie/newsworthy.

A few cows moo'd that they didn't want time-based releases, though.  For 
whatever reasons I can't fathom.  It makes our release process more 
predictable for everyone, including developers.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]

On Wednesday 11 August 2004 18:05, Dylan Carlson wrote:
> A few cows moo'd that they didn't want time-based releases, though.  For
> whatever reasons I can't fathom.  It makes our release process more
> predictable for everyone, including developers.

Just remind those grazers the problems we had before we decided on this 
date-based release scheme. While for somethings the stance of "it's ready 
when it's ready" works. This is not true for such a dynamic animal as gentoo.

I also like the idea of coinciding normal releases with stable tree releases. 
We could also merge the media. I guess I can trust you to make a reasonable 
assesment on the posibility of doing this. For me a 6 months cycle is 
probably better than 3 months. 3 months has shown to be too short for real 
work. We could maybe alternatively provide a good manual (if we don't yet) 
for users how to make their own releases / livecd's.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[John Davis]

[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]

On Tue, 2004-08-10 at 19:24, Kurt Lieber wrote:
> I've had a different experience when interacting with releng, *especially*
> when it comes to changing the release cycle, so I'm not as optimistic as
> you are.  I'm open to discussing it, however, so feel free to contact me
> offline.
> 

I take it that you are referring to our argument. I never said that we
would not change cycles, I just said that we would not do it mid-year.
There has been an expectation for awhile now that the release cycle is
going to change for 2005. Re-read the logs.

> If this GLEP ends up getting approved and adopted, I see no problem
> synchronizing the annual release of this stable tree with one of the
> four/whatever annual releases of the livecd/package CDs.  I'm just not
> going to let releng requirements get in the way of doing what is best for
> this project.  If we can have the two happily co-exist without sacrificing
> the needs of the server project, great.
> 
> --kurt

And we don't want the server project to get in the way of releng's
progress. We (releng) are willing to work with you and cooperate in any
way that we can, but judging from the above quote, as well as past
experience with you, let's hope that our projects can in fact "happily
co-exist" without one side strong-arming for the top position.

Regards,
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 4F9E 41F6 D072 5C1A 636C  2D46 B92C 4823 E281 41BB

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Corey Shields]

On Tuesday 10 August 2004 08:23 am, Chris Gianelloni wrote:
> > [side note] the releases of the tree are not tied to the releases of our
> > liveCD/package sets.[/side note]
>
> This I don't understand at all.  Why maintain 2 separate release cycles?

There is no release for this at all..  We can use the same release cd's that 
are currently available.

> So the idea is to create exactly *one* stable tree?  How is this any
> different than just doing better with our current tree?  Honestly, from
> what I've heard from our users, they want package stability (as in
> freeze) much more than anything else.  This is *exactly* why I recommend
> tying the "stable" trees with the releases.  I'm not sure I can
> understand how doing anything else really gives us anything other than
> adding more workload for the simple fact of adding workload.  Having a
> "stable" tree that still moves, and only providing a single "stable"
> tree doesn't seem to be an improvement from what we have at all.

when we say "stable" we are talking about the package freeze you mention.  
Some people want daily updates of stuff to be on the bleeding edge.  This is 
one of the biggest selling points of Gentoo, and should remain that way.  
This project aims at making a tree (or however it is implemented) that does 
not change as often.  For example, I don't need every little gcc and 
man-pages update on my production system.  This would provide some stability 
to the tree.  I guess that "stable" is a bad term here as it is easily 
confused for system stability.

Cheers,

-C

-- 
Corey Shields
Gentoo Linux Infrastructure Team and Devrel Team
Gentoo Foundation Board of Trustees
http://www.gentoo.org/~cshields

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2761 bytes --]

On Tue, 2004-08-10 at 09:26, Corey Shields wrote:
> There is no release for this at all..  We can use the same release cd's that 
> are currently available.

I still don't see the advantage of 2 release cycles.  I honestly feel
like our current quarterly release cycles are a bit ambitious.  Adding
any other release cycles into this mix would simply be overwhelming for
our staff.

> > So the idea is to create exactly *one* stable tree?  How is this any
> > different than just doing better with our current tree?  Honestly, from
> > what I've heard from our users, they want package stability (as in
> > freeze) much more than anything else.  This is *exactly* why I recommend
> > tying the "stable" trees with the releases.  I'm not sure I can
> > understand how doing anything else really gives us anything other than
> > adding more workload for the simple fact of adding workload.  Having a
> > "stable" tree that still moves, and only providing a single "stable"
> > tree doesn't seem to be an improvement from what we have at all.
> 
> when we say "stable" we are talking about the package freeze you mention.  
> Some people want daily updates of stuff to be on the bleeding edge.  This is 
> one of the biggest selling points of Gentoo, and should remain that way.  
> This project aims at making a tree (or however it is implemented) that does 
> not change as often.  For example, I don't need every little gcc and 
> man-pages update on my production system.  This would provide some stability 
> to the tree.  I guess that "stable" is a bad term here as it is easily 
> confused for system stability.

I guess when I hear stable, I think *UN*changing... not "changing less
often".  Adding "some" stability is not what our users are asking for
from us.  They are asking for a "stable" tree.  A single tree cannot
provide this.  Having a "bleeding" and a "stable" tree cannot provide
this.  This is why I have always been pushing the idea of having a
"release" tree which coincides with the release media.  You then have a
complete set of "stable" packages, both in the form of the release tree,
and also in the form of pre-compiled binary GRP packages.  It also would
open up the possibility of creating binary-only update packages if we so
desired to in the future.  Installing from a Gentoo 2019.2 CD would then
*always* produce an *identical* install, just as it does with any other
distribution, and just like our users are requesting.  This does not
change the "gentoo-portage" module, which would be the equivalent of
something like freebsd's or slackware's -current branches.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

On Tuesday 10 August 2004 15:48, Chris Gianelloni wrote:
> On Tue, 2004-08-10 at 09:26, Corey Shields wrote:
> > There is no release for this at all..  We can use the same release cd's
> > that are currently available.
>
> I still don't see the advantage of 2 release cycles.  I honestly feel
> like our current quarterly release cycles are a bit ambitious.  Adding
> any other release cycles into this mix would simply be overwhelming for
> our staff.

Why not merge the cycles? Once per year (or whatever is decided) the media 
release (like current releases) coincides with the release of the 
stable/release tree. The other media releases will be similar, but the tree 
will not be maintained or provided as release.

Paul

ps. The difference for the installation medium between a release current style 
and a stable release could just be the profile provided. (The profile taking 
care of the different tree etc.)

pps. Of course it could also be done in the manual

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

On Tue, 2004-08-10 at 10:20, Paul de Vrieze wrote:
> Why not merge the cycles? Once per year (or whatever is decided) the media 
> release (like current releases) coincides with the release of the 
> stable/release tree. The other media releases will be similar, but the tree 
> will not be maintained or provided as release.

There's no problem with that at all... or changing the release cycle for
release media to only 2 per year, while releasing the stable tree
simultaneously...

The whole point is that we should be working together on it, not working
apart from each other.  We already *have* a Release Engineering Top
Level Project, there's no need to duplicate their efforts.

> ps. The difference for the installation medium between a release current style 
> and a stable release could just be the profile provided. (The profile taking 
> care of the different tree etc.)

With the SYNC variable idea, there's no need for separate media at all. 
All release media is "stable" media, with a simple instruction in the
Handbook for how to change to the "current" tree.

> pps. Of course it could also be done in the manual

*grin*

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Corey Shields]

On Tuesday 10 August 2004 08:48 am, Chris Gianelloni wrote:
> I guess when I hear stable, I think *UN*changing... not "changing less
> often".  Adding "some" stability is not what our users are asking for
> from us.  They are asking for a "stable" tree.  A single tree cannot
> provide this.  Having a "bleeding" and a "stable" tree cannot provide

how do you provide security updates without changing the tree?   That is the 
only thing that would change in this tree (until a new "release" is made, 
whether that be a new CD or a new tree, whatever).

Cheers

-- 
Corey Shields
Gentoo Linux Infrastructure Team and Devrel Team
Gentoo Foundation Board of Trustees
http://www.gentoo.org/~cshields

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

On Tue, 2004-08-10 at 10:27, Corey Shields wrote:
> On Tuesday 10 August 2004 08:48 am, Chris Gianelloni wrote:
> > I guess when I hear stable, I think *UN*changing... not "changing less
> > often".  Adding "some" stability is not what our users are asking for
> > from us.  They are asking for a "stable" tree.  A single tree cannot
> > provide this.  Having a "bleeding" and a "stable" tree cannot provide
> 
> how do you provide security updates without changing the tree?   That is the 
> only thing that would change in this tree (until a new "release" is made, 
> whether that be a new CD or a new tree, whatever).

By making them additional, and non-mandatory.  Providing the newer
ebuilds as ~arch or as an overlay would both accomplish this, though
like many others, I think using an overlay is a bad idea for this.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Spider]

[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]

begin  quote
On Tue, 10 Aug 2004 00:01:07 +0000
Kurt Lieber <klieber@gentoo.org> wrote:

> One think that I think *everyone* agrees on is that any stable tree
> needs to be regularly updated with security fixes.  With this in mind,
> I'm concerned with trying to maintain multiple separate SYNC modules. 
> We'd have to upgrade each one with every GLSA, thus doubling or
> tripling the amount of CVS work needed each time.

Once again, coming from an ISV standpoint where we would have loved to
use Gentoo (or, I would, some of the people wouldn't care, and one or
two i'd have to beat to make them bend to my will, but whatever ;) 

We had to scrap both Gentoo -and- Debian stable trees. Why?  Because
both update the -main- repository when releasing security fixes/
bugfixes. Neither have a stable tree thats archived once and never
changes.

If you have to actively change a tree (modifications directly into the
"frozen" tree) which is the case in many environmens, you get stuck with
this problem. if upstream ever changes their tree, work is lost. You can
separate local trees and so on, however, once again work is lost when
internal revisions have superceeded the ones in the tree. (fex, local
changes to sshd to patch ther initscripts and default config files
before rollout, which ups the revision of openssh a few times, and then
there is a backported securityfix?  It won't get merged. )

this is why I'd like to push, once more, for separated "stable" (frozen
snapshot basically) and "updates"  pushed in a separate repo. If we
want others to use this in enterprise, we have to make it easy for them.
  :-)

//Spider



-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 3358 bytes --]

On Tue, 2004-08-10 at 14:05, Spider wrote:
> begin  quote
> On Tue, 10 Aug 2004 00:01:07 +0000
> Kurt Lieber <klieber@gentoo.org> wrote:
> 
> > One think that I think *everyone* agrees on is that any stable tree
> > needs to be regularly updated with security fixes.  With this in mind,
> > I'm concerned with trying to maintain multiple separate SYNC modules. 
> > We'd have to upgrade each one with every GLSA, thus doubling or
> > tripling the amount of CVS work needed each time.
> 
> Once again, coming from an ISV standpoint where we would have loved to
> use Gentoo (or, I would, some of the people wouldn't care, and one or
> two i'd have to beat to make them bend to my will, but whatever ;) 
> 
> We had to scrap both Gentoo -and- Debian stable trees. Why?  Because
> both update the -main- repository when releasing security fixes/
> bugfixes. Neither have a stable tree thats archived once and never
> changes.

I have no problem with that at all, and this is really more what I would
like to see.  The only reason I was mentioning using ~arch as a method
for security updates was to quell the people asking about security
updates.

> If you have to actively change a tree (modifications directly into the
> "frozen" tree) which is the case in many environmens, you get stuck with
> this problem. if upstream ever changes their tree, work is lost. You can
> separate local trees and so on, however, once again work is lost when
> internal revisions have superceeded the ones in the tree. (fex, local
> changes to sshd to patch ther initscripts and default config files
> before rollout, which ups the revision of openssh a few times, and then
> there is a backported securityfix?  It won't get merged. )
> 
> this is why I'd like to push, once more, for separated "stable" (frozen
> snapshot basically) and "updates"  pushed in a separate repo. If we
> want others to use this in enterprise, we have to make it easy for them.
>   :-)

To accomplish this would require a change to portage, but I think it
could be done with minimal work.  Allow me to ramble... *grin*

We add something along the lines of a PORTAGE_TREE variable, that can be
set to either the release version, or to "current".  So you would have
for 2005.0 something like:

PORTAGE_TREE="2005.0"

in make.conf (actually, in make.profile/make.defaults).  When this is
set to something non-"current", then portage will rsync *only* the
2005.0 directory in the "gentoo-updates" module, which goes to an
updates directory under /usr/portage, which is just an overlay which is
added due to being non-"current".  The rest of the tree is *never*
synched when an emerge sync is done.  When PORTAGE_TREE="current", the
overlay doesn't exist, and the tree is synched as normal.

Now, this gives us a non-moving, completely frozen tree for
installations/QA/whatever and also gives us a mechanism for updates.  It
requires a little bit more work from the portage developers (whom I am
sure are busy enough), but then takes up minimal space on the mirrors
and requires the addition of only one rsync module.  It also keeps the
mirrors from having to process rsync over the entire frozen portion of
the tree.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Olivier Crete]

I'm happy to see that I'm not the only one who thinks that stable should
mean frozen, ie not moving and not, slowly moving or somewhat slowly
moving..

While I'm at it, I propose renaming the GLEP 19 to "Gentoo Frozen
Portage Tree" so people will not think that its about package stability.

On Tue, 2004-08-10 at 15:03 -0400, Chris Gianelloni wrote:
> On Tue, 2004-08-10 at 14:05, Spider wrote:
> > this is why I'd like to push, once more, for separated "stable" (frozen
> > snapshot basically) and "updates"  pushed in a separate repo. If we
> > want others to use this in enterprise, we have to make it easy for them.
> >   :-)
> 
> To accomplish this would require a change to portage, but I think it
> could be done with minimal work.  Allow me to ramble... *grin*

Why not just set SYNC="" (so emerge sync will fail) and use gensync ? Or
does emerge glsa not use overlays or something else like that?

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]

On Tue, 2004-08-10 at 15:23, Olivier Crete wrote:
> I'm happy to see that I'm not the only one who thinks that stable should
> mean frozen, ie not moving and not, slowly moving or somewhat slowly
> moving..
> 
> While I'm at it, I propose renaming the GLEP 19 to "Gentoo Frozen
> Portage Tree" so people will not think that its about package stability.
> 
> On Tue, 2004-08-10 at 15:03 -0400, Chris Gianelloni wrote:
> > On Tue, 2004-08-10 at 14:05, Spider wrote:
> > > this is why I'd like to push, once more, for separated "stable" (frozen
> > > snapshot basically) and "updates"  pushed in a separate repo. If we
> > > want others to use this in enterprise, we have to make it easy for them.
> > >   :-)
> > 
> > To accomplish this would require a change to portage, but I think it
> > could be done with minimal work.  Allow me to ramble... *grin*
> 
> Why not just set SYNC="" (so emerge sync will fail) and use gensync ? Or
> does emerge glsa not use overlays or something else like that?

I didn't think anything actually used overlays.  The emerge glsa was
being designed to work like "emerge system" or "emerge world".  It would
require a regular "emerge sync" step to work properly... at least, that
was my understanding.  Forgive me if I'm wrong on that.

Personally, I think there should be as little change for the user as
possible.  Breaking "emerge sync" is probably not the best way to go
about it.  Causing "emerge sync" to perform a slightly different
function, though with the same results (getting new ebuilds) is probably
the way to go.  While I doubt we would be using gensync directly, it
definitely gives us a strong starting point.  I am going to say that I
wouldn't be opposed to using gensync and a separate repository, I just
think it ends up being overly complex, as if we're going to be offering
it as an "official" Gentoo release, we should add proper support into
the tools we already have (portage).  Also, using portage and emerge
sync for updates allows a user to switch to the "current" tree with
almost no work.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 3613 bytes --]

On 08/10/04  Chris Gianelloni wrote:

> I didn't think anything actually used overlays.  The emerge glsa was
> being designed to work like "emerge system" or "emerge world".  It
> would require a regular "emerge sync" step to work properly... at
> least, that was my understanding.  Forgive me if I'm wrong on that.

Interesting to see people talking about things that aren't completely
implemented yet ;)
At the moment GLSAs reside in $PORTDIR/metadata/glsa and on
http://www.gentoo.org/security/en/glsa, the current code (used by
glsa-check) only looks at the former location. However I've written the
code in a way so that the location can be changed in the same way as
other portage variables (in make.* or on the commandline), so it's not a
problem to change the location in the profile, however you'll have to
find a way to get the GLSAs there. I originally also planned to
implement a way to get the GLSAs directly over http, but that's more
complicated than I thought first (and not very useful for our current
tree anyway).

> Personally, I think there should be as little change for the user as
> possible.  Breaking "emerge sync" is probably not the best way to go
> about it.  Causing "emerge sync" to perform a slightly different
> function, though with the same results (getting new ebuilds) is
> probably the way to go.  While I doubt we would be using gensync
> directly, it definitely gives us a strong starting point.  I am going
> to say that I wouldn't be opposed to using gensync and a separate
> repository, I just think it ends up being overly complex, as if we're
> going to be offering it as an "official" Gentoo release, we should add
> proper support into the tools we already have (portage).  Also, using
> portage and emerge sync for updates allows a user to switch to the
> "current" tree with almost no work.

As for generating a frozen tree I understand that there are basically
two options: a) use our current (changing) tree and only freeze the
versions of packages in the profile or b) create a new tree that 
doesn't change at all (maybe even limited to only include supported
packages/versions). The first is easier to implement but has IMO several
problems:
- we can only limit a package to a specific version, but not "remove" a
complete package that we don't want to support (under the assumption
that we're not going to support the whole tree)
- I doubt that a "packages" file with several hundred (or thousand)
entries is someting most developers want to maintain
- As Spider has already mentioned: It doesn't guarantee a definite base
system as the tree (including the profile) can change over time.

That leaves us with option b): We already offer tarballs of the portage
tree, including the tarballs used to create our releases. People even
have to use them if they want to use GRP. As people already know how to
use them I'd suggest that we use tarballs to provide our frozen tree
(wether we use the existing ones or create special ones is open for
discussion). As this GLEP is looking for a long-term solution we can
probably rely on some portage modifications that will be included in the
version after 2.0.51 that will enhance our `emerge sync` mechanisms
greatly (removing the need for emerge-webrsync and gensync). With these
modifications we can set SYNC to our tarball and offer updates over
rsync/cvs/tarballs/other transport that will be stored in an overlay,
that overlay can then by synced with `emerge --sync updates` ("updates"
is just an example, we can use any name there).
(Anyone interested in the details of the modification see bug 35535).

Marius

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]

On Wednesday 11 August 2004 06:22, Marius Mauch wrote:
>
> That leaves us with option b): We already offer tarballs of the portage
> tree, including the tarballs used to create our releases. People even
> have to use them if they want to use GRP. As people already know how to
> use them I'd suggest that we use tarballs to provide our frozen tree
> (wether we use the existing ones or create special ones is open for
> discussion). As this GLEP is looking for a long-term solution we can
> probably rely on some portage modifications that will be included in the
> version after 2.0.51 that will enhance our `emerge sync` mechanisms
> greatly (removing the need for emerge-webrsync and gensync). With these
> modifications we can set SYNC to our tarball and offer updates over
> rsync/cvs/tarballs/other transport that will be stored in an overlay,
> that overlay can then by synced with `emerge --sync updates` ("updates"
> is just an example, we can use any name there).
> (Anyone interested in the details of the modification see bug 35535).

What I see in this discussion is one thing. We really need to have ebuilds 
specify the auxiliary files they use (the files in the files directory except 
digest). Using such a AUX_FILES variable it is possible to automatically make 
a tree containing only one stable ebuild version per slot (with checked 
deps). It also allows keeping track of which files are still in actual use.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 4457 bytes --]

On Wed, 2004-08-11 at 00:22, Marius Mauch wrote:
> On 08/10/04  Chris Gianelloni wrote:
> 
> > I didn't think anything actually used overlays.  The emerge glsa was
> > being designed to work like "emerge system" or "emerge world".  It
> > would require a regular "emerge sync" step to work properly... at
> > least, that was my understanding.  Forgive me if I'm wrong on that.
> 
> Interesting to see people talking about things that aren't completely
> implemented yet ;)
> At the moment GLSAs reside in $PORTDIR/metadata/glsa and on
> http://www.gentoo.org/security/en/glsa, the current code (used by
> glsa-check) only looks at the former location. However I've written the
> code in a way so that the location can be changed in the same way as
> other portage variables (in make.* or on the commandline), so it's not a
> problem to change the location in the profile, however you'll have to
> find a way to get the GLSAs there. I originally also planned to
> implement a way to get the GLSAs directly over http, but that's more
> complicated than I thought first (and not very useful for our current
> tree anyway).

So I was half right... Thanks for filling in the gaps.

> > Personally, I think there should be as little change for the user as
> > possible.  Breaking "emerge sync" is probably not the best way to go
> > about it.  Causing "emerge sync" to perform a slightly different
> > function, though with the same results (getting new ebuilds) is
> > probably the way to go.  While I doubt we would be using gensync
> > directly, it definitely gives us a strong starting point.  I am going
> > to say that I wouldn't be opposed to using gensync and a separate
> > repository, I just think it ends up being overly complex, as if we're
> > going to be offering it as an "official" Gentoo release, we should add
> > proper support into the tools we already have (portage).  Also, using
> > portage and emerge sync for updates allows a user to switch to the
> > "current" tree with almost no work.
> 
> As for generating a frozen tree I understand that there are basically
> two options: a) use our current (changing) tree and only freeze the
> versions of packages in the profile or b) create a new tree that 
> doesn't change at all (maybe even limited to only include supported
> packages/versions). The first is easier to implement but has IMO several
> problems:
> - we can only limit a package to a specific version, but not "remove" a
> complete package that we don't want to support (under the assumption
> that we're not going to support the whole tree)
> - I doubt that a "packages" file with several hundred (or thousand)
> entries is someting most developers want to maintain
> - As Spider has already mentioned: It doesn't guarantee a definite base
> system as the tree (including the profile) can change over time.
> 
> That leaves us with option b): We already offer tarballs of the portage
> tree, including the tarballs used to create our releases. People even
> have to use them if they want to use GRP. As people already know how to
> use them I'd suggest that we use tarballs to provide our frozen tree
> (wether we use the existing ones or create special ones is open for
> discussion). As this GLEP is looking for a long-term solution we can
> probably rely on some portage modifications that will be included in the
> version after 2.0.51 that will enhance our `emerge sync` mechanisms
> greatly (removing the need for emerge-webrsync and gensync). With these
> modifications we can set SYNC to our tarball and offer updates over
> rsync/cvs/tarballs/other transport that will be stored in an overlay,
> that overlay can then by synced with `emerge --sync updates` ("updates"
> is just an example, we can use any name there).
> (Anyone interested in the details of the modification see bug 35535).

I think the release tarballs are a good start.  I'm more than willing to
work to make the tarballs to provide what is wanted for the GLEP.

I definitely think that what we use for releases should match the frozen
tree that coincides with that release.  It means there would be only one
set of packages to support, which makes things very easy, and as I said,
even allows for possible binary updates in the future, if we so desired.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

On Tue, Aug 10, 2004 at 03:23:02PM -0400 or thereabouts, Olivier Crete wrote:
> Why not just set SYNC="" (so emerge sync will fail) and use gensync ? Or
> does emerge glsa not use overlays or something else like that?

You mean other than because that's an ugly, ungraceful hack?

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Jeremy Maitin-Shepard]

[-- Attachment #1: Type: text/plain, Size: 1314 bytes --]

Spider <spider@gentoo.org> writes:

> [snip]

> We had to scrap both Gentoo -and- Debian stable trees. Why?  Because
> both update the -main- repository when releasing security fixes/
> bugfixes. Neither have a stable tree thats archived once and never
> changes.

> If you have to actively change a tree (modifications directly into the
> "frozen" tree) which is the case in many environmens, you get stuck with
> this problem. if upstream ever changes their tree, work is lost. You can
> separate local trees and so on, however, once again work is lost when
> internal revisions have superceeded the ones in the tree. (fex, local
> changes to sshd to patch ther initscripts and default config files
> before rollout, which ups the revision of openssh a few times, and then
> there is a backported securityfix?  It won't get merged. )

If you want a tree that doesn't change, you can simply not update it
(from the Gentoo mirrors).  This is particularly easy if you are running
your own internal rsync mirror, since then you don't even have to worry
about not having a convenient mechanism for distributing the portage
tree to the users.  This requires no work from Gentoo -- what does
require significant work, and what some users want, is a tree that is
only updated with bug fixes.


-- 
Jeremy Maitin-Shepard

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Spider]

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]

begin  quote
On Tue, 10 Aug 2004 16:34:32 -0400
Jeremy Maitin-Shepard <jbms@gentoo.org> wrote:

> If you want a tree that doesn't change, you can simply not update it
> (from the Gentoo mirrors).  This is particularly easy if you are
> running your own internal rsync mirror, since then you don't even have
> to worry about not having a convenient mechanism for distributing the
> portage tree to the users.  This requires no work from Gentoo -- what
> does require significant work, and what some users want, is a tree
> that is only updated with bug fixes.

I know how to create a solid, frozen, environment. Its not that, and
that solution is Not An Option. Not syncing means that you don't get
securityupdates and so on.   So its a losing situation there.

And I also know how much work it entails to track releases and test
updates and patches against the stable tree. (since it requires you to
have a dedicated partition/tree for it..)

I also know that this is a tree we could easily provide a running GRP
set against for anyone and their monkey to update with. "emerge sync;
emerge -gukK world" should be a safe operation. 
 ( as if.. ;)

//Spider



-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Jeremy Maitin-Shepard]

[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]

Spider <spider@gentoo.org> writes:

> Jeremy Maitin-Shepard <jbms@gentoo.org> wrote:

>> If you want a tree that doesn't change, you can simply not update it
>> (from the Gentoo mirrors).  This is particularly easy if you are
>> running your own internal rsync mirror, since then you don't even have
>> to worry about not having a convenient mechanism for distributing the
>> portage tree to the users.  This requires no work from Gentoo -- what
>> does require significant work, and what some users want, is a tree
>> that is only updated with bug fixes.

> I know how to create a solid, frozen, environment. Its not that, and
> that solution is Not An Option. Not syncing means that you don't get
> securityupdates and so on.   So its a losing situation there.

I'm confused.  In the message to which I replied, you stated that the
problem with the Debian tree is that it does not remain *exactly* the
same, namely that bug fixes and security fixes are added.  That is why I
suggested that you can achieve this quite simply on Gentoo by not
syncing.  If you meant something else in your previous message, could
you please explain it?

> [snip]

-- 
Jeremy Maitin-Shepard

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Spider]

[-- Attachment #1: Type: text/plain, Size: 2332 bytes --]

begin  quote
On Wed, 11 Aug 2004 03:50:04 -0400
Jeremy Maitin-Shepard <jbms@gentoo.org> wrote:

> If you meant something else in your previous message, could
> you please explain it?

I believe I did argue -why- updating the main tree is a bad idea for an
"enterprise"  ("stable") release.   

*) Don't assume that ISV/Enterprise users won't want updates. They do.
They count on it. Otherwise they would simply take a snapshot, run their
own changes, QA it for a month and deploy...  Erm.. No, thats the point
of using a distribution, to not have to do that.


*) Enterprise/ISVs -will- make modifications to their sources. Thats
part of the point of running Gentoo for custom deployments. Its easy to
customize Gentoo, thats one of our strengths.

 ( Yes, for servers they may well run unpatched and so on, however, even
server deployments on large scale are likely to modify some packages.
Fex. basic server configurations and so on. Its easier to change the
default ntpd package + configs than it is to manually track n machines
and do the same cut-n-paste changes.)



*) Updates in main tree break upgradability of such trees. Badly at
that.    This is why I argue a separated release process, because then
its simple to check "whats new" in the released tree, which will be a
fairly -small- tree at that. Check fex. redhat's "errata" tree for their
older distributions. 


Point example that invalidated debian from such a process, was this:

1) foobah in main tree released as stable.
1.2) internal bumps of foobah to patch some issues from upstream CVS
that casued problems. (debian didn't consider this bad enough)
and add  config file changes to go into the package directly.( this is
released in a separate, internal, apt repo. Sort of like having an
Gentoo overlay tree)

1.3) upstream releases modified foobah into mainline.

This means that the base version is modified, and there is no notice to
others about this, because internal deployment has already taken the
package five to ten revisions higher.  The internal repo has predecent
and and update doesn't work.

With Gentoo the case would be the same, leaving systems vulnerable.


I hope I have been able to explain the problems involved here.



-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Dylan Carlson]

On Monday 09 August 2004 5:52 am, Kurt Lieber wrote:
> The only "extra" thing we've talked about so far is a separate rsync
> module that has the --delete option removed (but is otherwise identical
> to the gentoo-portage module)
>
> Come up with a better way to *guarantee* ebuilds stay in the tree for a
> minimum length of time and I'm all for it.

That sounds reasonable to me.  

I was trying to clarify if GLEP19 was going to recommend setting up another 
tree in CVS (which IMO results in duplication of effort and resources.)  
That would be my only objection.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Corey Shields]

On Monday 09 August 2004 05:11 pm, Dylan Carlson wrote:
> That sounds reasonable to me.
>
> I was trying to clarify if GLEP19 was going to recommend setting up another
> tree in CVS (which IMO results in duplication of effort and resources.)
> That would be my only objection.

Not at all..  we would do this with the same cvs tree.  Theoretically this 
could be setup tomorrow without any maintainers involved.

Cheers!

-Corey

-- 
Corey Shields
Gentoo Linux Infrastructure Team and Devrel Team
Gentoo Foundation Board of Trustees
http://www.gentoo.org/~cshields

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Corey Shields]

On Monday 09 August 2004 12:04 am, Dylan Carlson wrote:
> However, if we propose using a different tree, repo or branch tags for
> enterprise, I'm not a big fan of that approach.  IMO it should be taken
> incrementally; that is, get it to work in the existing tree w/ new
> profiles, and if there is some implementation problem getting enterprise
> to co-exist with everything else, move it out.

The reason for this is because with the current tree, old versions would be 
removed too soon.  Yet we don't want a larger tree for our general user base, 
so having a seperate tree is the current solution.  It would be identical to 
the current tree with regards to new packages, but older packages would not 
be deleted 3 months after they have become outdated, per se.  This is the 
whole idea behind a stable tree.  If I can go a year without needing to 
update gcc on a production server, then I don't want to have to update it.  
Yet if the version I am running is pulled out of the tree, that may cause 
problems for new installs.

Cheers!

-C

-- 
Corey Shields
Gentoo Linux Infrastructure Team and Devrel Team
Gentoo Foundation Board of Trustees
http://www.gentoo.org/~cshields

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Jeremy Maitin-Shepard]

[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]

Corey Shields <cshields@gentoo.org> writes:

> [snip]

> The reason for this is because with the current tree, old versions would be 
> removed too soon.  Yet we don't want a larger tree for our general user base, 
> so having a seperate tree is the current solution.  It would be identical to 
> the current tree with regards to new packages, but older packages would not 
> be deleted 3 months after they have become outdated, per se.  This is the 
> whole idea behind a stable tree.  If I can go a year without needing to 
> update gcc on a production server, then I don't want to have to update it.  
> Yet if the version I am running is pulled out of the tree, that may cause 
> problems for new installs.

This issue is really an issue with our use of CVS and Rsync -- ideally,
we would have some distribution system that `knows' about the Gentoo
package version structure; old package versions shouldn't ever be
`deleted' such that they are inaccessible through the normal
distribution mechanism, but we don't want an ever growing portage tree
size that must sit on users' and developers' machines.  However, it is
probably not feasible to write custom software for version control and
distribution of the portage tree.

-- 
Jeremy Maitin-Shepard

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Greg KH]

On Sun, Aug 08, 2004 at 06:51:44PM +0000, Kurt Lieber wrote:
> 
> Third, many folks want long-term support of these releases.  I *don't*
> think this is viable and am not willing to personally sponsor this.  A core
> component of this GLEP is that we will *not* be backporting security fixes.

So what would happen for security fixes?  Rely on the latest release
from upstream to be used instead?  This can cause real problems, as a
lot of SATA users just found out with the most recent Fedora kernel
update due to the security fix.  They went with the most recent kernel,
which happened to rename their disk drives.

What is the downside of just backporting the security fixes to the
versions marked "stable" (becides developer time)?  I really think this
is something most people who want a "stable" tree will want to have (if
for no other reason than that's how all the other Linux distros do it,
and it will take less effort trying to explain why we don't...)

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]

On Monday 09 August 2004 08:34, Greg KH wrote:
> On Sun, Aug 08, 2004 at 06:51:44PM +0000, Kurt Lieber wrote:
> > Third, many folks want long-term support of these releases.  I
> > *don't* think this is viable and am not willing to personally sponsor
> > this.  A core component of this GLEP is that we will *not* be
> > backporting security fixes.
>
> So what would happen for security fixes?  Rely on the latest release
> from upstream to be used instead?  This can cause real problems, as a
> lot of SATA users just found out with the most recent Fedora kernel
> update due to the security fix.  They went with the most recent kernel,
> which happened to rename their disk drives.

Testing is of course necessary. At each time it needs to be considered 
whether backporting or upgrading is the best way to go. In many cases 
backporting only amounts to isolating the changes to the current ebuild 
and applying that patch to the old version. One needs some knowledge of 
the programming language used to judge the probable impact but for many 
patches one can be quite confident that the impact is minimal.

>
> What is the downside of just backporting the security fixes to the
> versions marked "stable" (becides developer time)?  I really think this
> is something most people who want a "stable" tree will want to have (if
> for no other reason than that's how all the other Linux distros do it,
> and it will take less effort trying to explain why we don't...)

I agree that discounting backporting in advance might not be the best way 
to go. But I agree that our backporting resources are very limited.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Greg KH]

On Mon, Aug 09, 2004 at 09:46:06AM +0200, Paul de Vrieze wrote:
> On Monday 09 August 2004 08:34, Greg KH wrote:
> > On Sun, Aug 08, 2004 at 06:51:44PM +0000, Kurt Lieber wrote:
> > > Third, many folks want long-term support of these releases.  I
> > > *don't* think this is viable and am not willing to personally sponsor
> > > this.  A core component of this GLEP is that we will *not* be
> > > backporting security fixes.
> >
> > So what would happen for security fixes?  Rely on the latest release
> > from upstream to be used instead?  This can cause real problems, as a
> > lot of SATA users just found out with the most recent Fedora kernel
> > update due to the security fix.  They went with the most recent kernel,
> > which happened to rename their disk drives.
> 
> Testing is of course necessary. At each time it needs to be considered 
> whether backporting or upgrading is the best way to go. In many cases 
> backporting only amounts to isolating the changes to the current ebuild 
> and applying that patch to the old version. One needs some knowledge of 
> the programming language used to judge the probable impact but for many 
> patches one can be quite confident that the impact is minimal.

Also realize that we almost always have access to just the security
patch that is needed, because this is what other distros do.  So it's
not usually a case that we need to create the patches ourselves for
this.

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

On Monday 09 August 2004 09:56, Greg KH wrote:
> Also realize that we almost always have access to just the security
> patch that is needed, because this is what other distros do.  So it's
> not usually a case that we need to create the patches ourselves for
> this.

I know that in most cases this is true. Isolating the changes can amount 
to just finding the patch ;-)

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]

On Sun, Aug 08, 2004 at 11:34:16PM -0700 or thereabouts, Greg KH wrote:
> So what would happen for security fixes?  Rely on the latest release
> from upstream to be used instead?  

Yes, in most cases.

> This can cause real problems, as a lot of SATA users just found out with
> the most recent Fedora kernel update due to the security fix.  They went
> with the most recent kernel, which happened to rename their disk drives.

Yes, but backporting security fixes to code that the original author never
planned to have it used with causes its own set of problems. 

> What is the downside of just backporting the security fixes to the
> versions marked "stable" (becides developer time)?  

Don't discount "developer time" as inconsequential.  We already have issues
with things getting patched in a timely fashion.  Trying to backport (and
test!) everything will only make it worse.  

Another gentoo-specific reason is the fact that, right now, our QA is
inadequate to support backporting.  We're setting ourselves up for failure
if we set a policy of backporting all security fixes without having
adequate QA in place to make sure they work properly.  (and no, GLEP 19
isn't designed to deal with QA -- that's a whole separate GLEP entirely)

In general, the GLEP suggests not backporting.  If there are extenuating
circumstances, then the package maintainer is free to backport at their
discretion.  A good example of this would be a security fix that is only
released in a major revision of the package.  (MySQL 5.0, for instance)  In
that case, it might make sense to backport the fix to MySQL 4.x.

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Barry Shaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kurt Lieber wrote:

| Second, there was some question about how often the tree would be updated.
| The GLEP doesn't really specify this, but I think once a year is a
| reasonable timeframe.
|
| Third, many folks want long-term support of these releases.  I *don't*
| think this is viable and am not willing to personally sponsor this.  A
core
| component of this GLEP is that we will *not* be backporting security
fixes.
| (at least not as a rule)  We will be relying on the versions that the
| original authors provide except in very unusual circumstances.  The reason
| for this is simple -- we don't have the resources to guarantee that we can
| backport things (and, more importantly, guarantee that they'll work right
| once backported)  Suppporting a profile for four or more years almost
| guarantees you'll be doing a lot of backporting.  I don't plan to
| incorporate long-term support as part of this GLEP.  That might, however,
| be an excellent opportunity for commercial companies with greater finanial
| resources than us.
|

My main concern here is that if you've got a core server, which
typically has lifetime of 3 to 4 years, you don't want to be
reinstalling it every year (in many cases you can't).  That said, I
agree that its unlikely there are resources to maintain a tree for years
on end.  As a compromise, if some consideration was given to easing
migration, that would be suitable.  Given the fact that servers have a
very minimal level of software on them anyway, its probably not too much
of a big deal.

|
| Finally, the current GLEP doesn't really address how to ensure a minimum
| life for all ebuilds in the tree.  I'm open to suggestions on this,
but the
| best idea I've heard so far is using a separate rsync module and removing
| the --delete option from the command used to populate it.
|

I like this idea.  That way if the end user doesn't want to upgrade, the
original ebuild stays in portage and they can stick with that.

Backporting has been mentioned in Greg k-h's post and I think thats
something we want to stay away from.  Ebuild maintainers may not have
the programming skill necessary to backport fixes from one version of
the software to another.  The upstream maintainers are the experts in
that respect and thats where that decision should stay.  In my
experience once the upstream maintainer stops maintaining a certain
version of the software, migration to the new version is necessary anyway.

The other downside to backporting is that it causes tonnes of false
positives if you do any proactive network scanning.  Not a major really,
but its one of my pet hates 8)

| So, at this point, I'm suggesting three changes to the GLEP:
|
| 1) specify annual updates for the stable tree
| 2) replacing the stable keywording stuff with stable profiling stuff
| 3) adding a separate rsync module for the stable portage tree (or one for
|    each release of the stable portage tree)
|

These all sound like good alterations, keeping the GLEP focussed is a
sensible idea.

Baz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBFys7JvZkjpKMF2wRAutzAJ9pyJb/0VHtvuEOE3ggv2CIMpOGZACfZ2Cm
sjiNxtYa8Q1HB+RKlZv9RzA=
=630p
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 2833 bytes --]

On Monday 09 August 2004 09:43, Barry Shaw wrote:
> Kurt Lieber wrote:
> | Second, there was some question about how often the tree would be
> | updated. The GLEP doesn't really specify this, but I think once a
> | year is a reasonable timeframe.
> |
> | Third, many folks want long-term support of these releases.  I
> | *don't* think this is viable and am not willing to personally sponsor
> | this.  A
>
> core
>
> | component of this GLEP is that we will *not* be backporting security
>
> fixes.
>
> | (at least not as a rule)  We will be relying on the versions that the
> | original authors provide except in very unusual circumstances.  The
> | reason for this is simple -- we don't have the resources to guarantee
> | that we can backport things (and, more importantly, guarantee that
> | they'll work right once backported)  Suppporting a profile for four
> | or more years almost guarantees you'll be doing a lot of backporting.
> |  I don't plan to incorporate long-term support as part of this GLEP. 
> | That might, however, be an excellent opportunity for commercial
> | companies with greater finanial resources than us.
>
> My main concern here is that if you've got a core server, which
> typically has lifetime of 3 to 4 years, you don't want to be
> reinstalling it every year (in many cases you can't).  That said, I
> agree that its unlikely there are resources to maintain a tree for
> years on end.  As a compromise, if some consideration was given to
> easing migration, that would be suitable.  Given the fact that servers
> have a very minimal level of software on them anyway, its probably not
> too much of a big deal.

The upgrade is not supposed to be a reinstall. Just an upgrade, allthough 
there might be some issues with configuration files etc.

> Backporting has been mentioned in Greg k-h's post and I think thats
> something we want to stay away from.  Ebuild maintainers may not have
> the programming skill necessary to backport fixes from one version of
> the software to another.  The upstream maintainers are the experts in
> that respect and thats where that decision should stay.  In my
> experience once the upstream maintainer stops maintaining a certain
> version of the software, migration to the new version is necessary
> anyway.

I don't think it is wise to make a black-and-white decision beforehand. Of 
course we need some general guideline though.

>
> The other downside to backporting is that it causes tonnes of false
> positives if you do any proactive network scanning.  Not a major
> really, but its one of my pet hates 8)

That's not really a fair issue. If it is an issue the version number could 
be ammended.

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Olivier Crete]

Hey,

I'm re-proposing the tarball approach. When a stable release is made, a
tarball of the tree would be taken (while removing all of the non-stable
stuff and just keeping the arch keyworks if necessary..).. And then an
overlay rsync for security updates would be created.. This ensures the
long term survival of the release.. It also allows us to keep
"distributing" very old release (we know how many shops still use
redhat7 or even 6) without putting too much strain on the mirrors.


On Sun, 2004-08-08 at 18:51 +0000, Kurt Lieber wrote:

> 2) replacing the stable keywording stuff with stable profiling stuff

Why do we need something as complex as profiling? And something that
requires work from every maintainer

> 3) adding a separate rsync module for the stable portage tree (or one for
>    each release of the stable portage tree)

Rsync is expensive for servers.. lets keep it down to the minimum. Its
much easier to get ftp/http mirrors than rsync... 


-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Corey Shields]

On Monday 09 August 2004 03:56 pm, Olivier Crete wrote:
> I'm re-proposing the tarball approach. When a stable release is made, a
> tarball of the tree would be taken (while removing all of the non-stable
> stuff and just keeping the arch keyworks if necessary..).. And then an
> overlay rsync for security updates would be created.. This ensures the
> long term survival of the release.. It also allows us to keep
> "distributing" very old release (we know how many shops still use
> redhat7 or even 6) without putting too much strain on the mirrors.

This isn't a realistic solution.  I think that moving away from the Portage 
tree as it is designed would be setting ourselves up to have a product with 
an end of life.  With an evolving tree, some things may not change for a 
year, but when they DO change, an update should be possible without breaking 
the system or needing to start from scratch.  The idea is not to freeze the 
tree permanently, but make it more "stable".

> Why do we need something as complex as profiling? And something that
> requires work from every maintainer

Profiling makes it such that we won't need work from every maintainer.

> Rsync is expensive for servers.. lets keep it down to the minimum. Its
> much easier to get ftp/http mirrors than rsync...

This is not true.  We have MANY more rsync mirrors than we have source 
mirrors.  The problem here is that most people don't have the disk space 
required for a distfiles mirror, whereas an rsync (portage) mirror is easy.  
I envision "enterprise" systems as needing to sync the tree less, especially 
if there are fewer updates expected.  The rsync issue really isn't an issue 
(and I'm not a fan of rsync by any means).

Cheers!

-C

-- 
Corey Shields
Gentoo Linux Infrastructure Team and Devrel Team
Gentoo Foundation Board of Trustees
http://www.gentoo.org/~cshields

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Olivier Crete]

On Mon, 2004-08-09 at 16:12 -0500, Corey Shields wrote:
> On Monday 09 August 2004 03:56 pm, Olivier Crete wrote:
> > I'm re-proposing the tarball approach. When a stable release is made, a
> > tarball of the tree would be taken (while removing all of the non-stable
> > stuff and just keeping the arch keyworks if necessary..).. And then an
> > overlay rsync for security updates would be created.. This ensures the
> > long term survival of the release.. It also allows us to keep
> > "distributing" very old release (we know how many shops still use
> > redhat7 or even 6) without putting too much strain on the mirrors.
> 
> This isn't a realistic solution.  I think that moving away from the Portage 
> tree as it is designed would be setting ourselves up to have a product with 
> an end of life.  With an evolving tree, some things may not change for a 
> year, but when they DO change, an update should be possible without breaking 
> the system or needing to start from scratch.  The idea is not to freeze the 
> tree permanently, but make it more "stable".

The whole point of a stable tree is to be stable.... rsync just doesn't
offer the same kind of guarantee.. Having security updates separate from
the "released" distribution is also a must imho. And this approach would
make that easy... This does not stop us from adding updates to the
overlay, it just makes it much easier for admins to control which
updates they want and which ones they dont...


> > Why do we need something as complex as profiling? And something that
> > requires work from every maintainer
> 
> Profiling makes it such that we won't need work from every maintainer.

The idea of profiles (if I understand it correctly) is that every
package that is part of stable must be added to a file (thousands of
them).. And then every maintainer must make sure that he does not delete
the stable package for every arch in every version. We already see
people deleting the stable versions for less used arches... And if
stable uses a separate tree, then there is really no point to profiles..

> > Rsync is expensive for servers.. lets keep it down to the minimum. Its
> > much easier to get ftp/http mirrors than rsync...
> 
> This is not true.  We have MANY more rsync mirrors than we have source 
> mirrors.  The problem here is that most people don't have the disk space 
> required for a distfiles mirror, whereas an rsync (portage) mirror is easy.  
> I envision "enterprise" systems as needing to sync the tree less, especially 
> if there are fewer updates expected.  The rsync issue really isn't an issue 
> (and I'm not a fan of rsync by any means).

We may have more rsync mirrors than source mirrors, but I'm sure that if
we offered the options of having stable mirrors without distfiles (just
the CD and portage tarballs), we'd have tons of those. (The new policy
of not having cds for p2,p3,p4,p68 really does help too imho)..  

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Corey Shields]

On Monday 09 August 2004 04:33 pm, Olivier Crete wrote:
> The whole point of a stable tree is to be stable.... rsync just doesn't
> offer the same kind of guarantee.. Having security updates separate from
> the "released" distribution is also a must imho. And this approach would
> make that easy... This does not stop us from adding updates to the
> overlay, it just makes it much easier for admins to control which
> updates they want and which ones they dont...

How do you plan to do updates (non-security) with this solution?

> The idea of profiles (if I understand it correctly) is that every
> package that is part of stable must be added to a file (thousands of
> them).. And then every maintainer must make sure that he does not delete
> the stable package for every arch in every version. We already see
> people deleting the stable versions for less used arches... And if
> stable uses a separate tree, then there is really no point to profiles..

There is more to profiling than this.  We can use profiles to mask down to the 
level we want, regardless of what the maintainer does.  The purpose of the 
seperate rsync module is so that stable packages do not get deleted, so that 
wouldn't be an issue.

> We may have more rsync mirrors than source mirrors, but I'm sure that if
> we offered the options of having stable mirrors without distfiles (just
> the CD and portage tarballs), we'd have tons of those. (The new policy
> of not having cds for p2,p3,p4,p68 really does help too imho)..

I don't see this happening..  I wouldn't want to split the mirroring this way 
either.  (and we are still producing the arch product CD's, just releasing 
them via bt and not on the mirrors)

Cheers,

-C

-- 
Corey Shields
Gentoo Linux Infrastructure Team and Devrel Team
Gentoo Foundation Board of Trustees
http://www.gentoo.org/~cshields

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Olivier Crete]

On Mon, 2004-08-09 at 16:45 -0500, Corey Shields wrote:
> On Monday 09 August 2004 04:33 pm, Olivier Crete wrote:
> > The whole point of a stable tree is to be stable.... rsync just doesn't
> > offer the same kind of guarantee.. Having security updates separate from
> > the "released" distribution is also a must imho. And this approach would
> > make that easy... This does not stop us from adding updates to the
> > overlay, it just makes it much easier for admins to control which
> > updates they want and which ones they dont...
> 
> How do you plan to do updates (non-security) with this solution?

just replace the tree entirely "rm -rf /usr/portage, tar xjvf
newportage.tar.bz2 -C /usr/portage" for "major upgrades"... or using an
overlay for minor local stuff... I like the idea of keeping my
"official" tree pure and then having nicely separated overlays.

> > The idea of profiles (if I understand it correctly) is that every
> > package that is part of stable must be added to a file (thousands of
> > them).. And then every maintainer must make sure that he does not delete
> > the stable package for every arch in every version. We already see
> > people deleting the stable versions for less used arches... And if
> > stable uses a separate tree, then there is really no point to profiles..
> 
> There is more to profiling than this.  We can use profiles to mask down to the 
> level we want, regardless of what the maintainer does.  The purpose of the 
> seperate rsync module is so that stable packages do not get deleted, so that 
> wouldn't be an issue.

I think we agree that this can't stay in the main tree. But then if its
separate, we can just re-keyword package instead of playing aroudn with
a profile... Since its a whole separate tree.


-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Dylan Carlson]

On Monday 09 August 2004 6:02 pm, Olivier Crete wrote:
>
> just replace the tree entirely "rm -rf /usr/portage, tar xjvf
> newportage.tar.bz2 -C /usr/portage" for "major upgrades"... or using an
> overlay for minor local stuff... I like the idea of keeping my
> "official" tree pure and then having nicely separated overlays.
>

I think it would be fine to allow people to do it this way, and some people 
already do, but I don't think it should be part of Enterprise Gentoo.  
Profiling isn't complex.  Trying to support the millions of different ways 
people can set up overlays is.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

On Mon, Aug 09, 2004 at 06:15:42PM -0400 or thereabouts, Dylan Carlson wrote:
> I think it would be fine to allow people to do it this way, and some people 
> already do, but I don't think it should be part of Enterprise Gentoo.  
> Profiling isn't complex.  Trying to support the millions of different ways 
> people can set up overlays is.

I agree with Dylan here.  While a tarball approach is certainly one
possilbe approach, requiring security ebuilds to be housed in an overlay
adds an extra layer of complexity.  The profiling solution is easier given
the way our tools (mainly portage) currently operate.

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

On Tuesday 10 August 2004 02:05, Kurt Lieber wrote:
> On Mon, Aug 09, 2004 at 06:15:42PM -0400 or thereabouts, Dylan Carlson 
wrote:
> > I think it would be fine to allow people to do it this way, and some
> > people already do, but I don't think it should be part of Enterprise
> > Gentoo. Profiling isn't complex.  Trying to support the millions of
> > different ways people can set up overlays is.
>
> I agree with Dylan here.  While a tarball approach is certainly one
> possilbe approach, requiring security ebuilds to be housed in an overlay
> adds an extra layer of complexity.  The profiling solution is easier given
> the way our tools (mainly portage) currently operate.

While I don't care about tarball vs. rsync (both don't matter that much to me) 
I don't think a profile is a solution. It would contain too many packages. 
Further it would still need maintenance for new packages as packages that are 
not pinned in the profile are available freely

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Dylan Carlson]

On Tuesday 10 August 2004 7:33 am, Paul de Vrieze wrote:
> While I don't care about tarball vs. rsync (both don't matter that much
> to me) I don't think a profile is a solution. It would contain too many
> packages. Further it would still need maintenance for new packages as
> packages that are not pinned in the profile are available freely

I don't believe the object here is to put every package in the tree in the 
profiles.   That's unrealistic to maintain, I agree.   

What should be in the profiles:  system packages (libc, cc, kernel, etc), 
KDE, Gnome, dependencies and other commonly-used app packages (apache, 
php, etc).  We start with a basic collection of packages we know everyone 
uses, and add to the profiles as folks complain about missing items.  
(This is where having voting in Bugzilla would be handy).

Bottom line, "Enterprise Gentoo" would consist of whatever is in those 
profiles, which means they are thoroughly tested, supported.   People can 
use packages not in the profile at their discretion, perhaps locking 
versions in /etc/portage.   However packages don't get the same treatment 
& testing unless it's in an enterprise profile, and hence they aren't 
supported the same.

We need to discuss the kinds of profiles we'd like to create (for different 
roles)  ... e.g., workstation, firewall, webserver, fileserver, cluster, 
etc.  This would, I believe, fit into the Installer project without any 
extra effort.

Also Kurt proposed a schedule of one release per year I believe.  I tend to 
think we can manage two (every 6 months), particularly early on as we need 
to get a feel of what people want/expect.  

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Chris Bainbridge]

On Tuesday 10 August 2004 19:33, Dylan Carlson wrote:
> Bottom line, "Enterprise Gentoo" would consist of whatever is in those
> profiles, which means they are thoroughly tested, supported.   People can
> use packages not in the profile at their discretion, perhaps locking
> versions in /etc/portage.   However packages don't get the same treatment
> & testing unless it's in an enterprise profile, and hence they aren't
> supported the same.
>
> We need to discuss the kinds of profiles we'd like to create (for different
> roles)  ... e.g., workstation, firewall, webserver, fileserver, cluster,
> etc.  This would, I believe, fit into the Installer project without any
> extra effort.

Ok I've been following this thread for a while and have a few observations and 
a cheeky proposal. Observations:

* I don't believe gentoo has many developers who are interested in supporting 
"old" software. It just doesn't scratch the itch.

* We don't have the resources to backport security fixes either. Upgrading is 
not an option for many enterprises, they want backports. Someone mentioned 
grabbing fixes from other distros... fine, but what if the versions differ? 
What about major non-security bug fixes?

* A 1 year support cycle isn't long enough for enterprise users.

* Redhat has the resources to run enterprise support. They do backports and 
bugfixes. For years.

* Redhat is the standard for enterprise linux (if you want oracle, eda 
software etc.). Many companies don't even test on anything else. I have a 
stack of commercial chip design software here, and all of it is redhat only.

So heres the cheeky proposal... make a "redhat" release. Follow redhats 
release cycle, and match their versions. Use their backported fixes. 
Commercial software will work. Bugs will be fixed. This is the power of open 
source.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 3051 bytes --]

On Tue, 2004-08-10 at 16:19, Chris Bainbridge wrote:
> Ok I've been following this thread for a while and have a few observations and 
> a cheeky proposal. Observations:
> 
> * I don't believe gentoo has many developers who are interested in supporting 
> "old" software. It just doesn't scratch the itch.

Agreed.

> * We don't have the resources to backport security fixes either. Upgrading is 
> not an option for many enterprises, they want backports. Someone mentioned 
> grabbing fixes from other distros... fine, but what if the versions differ?

Fix it for the version in question.  It's usually a lot easier to fix a
broken patch than to discover and patch a problem yourself.

> What about major non-security bug fixes?

This hasn't been discussed.  Personally, I think any fix that doesn't
alter functionality (typo fixes, bug fixes) or add new features is
fine.  Some people will want security fixes and nothing else.

> * A 1 year support cycle isn't long enough for enterprise users.

We're not talking about commercial support here.  Also, we aren't
talking about providing *any* semblance of support.  The idea is to get
a tree out there, as that seems to be enough to satisfy a large number
of people.  Perhaps having the tree out there will bring forth more
help.  Perhaps it'll bring about an interested third party willing to
offer commercial support.  Perhaps it'll bring about nothing.  No matter
what the outcome, it doesn't cost us much in time, and it satisfies a
good number of our users, so we should do it.

> * Redhat has the resources to run enterprise support. They do backports and 
> bugfixes. For years.

No argument here... They will fix whatever you want, provided you "show
them the money", so to speak.

> * Redhat is the standard for enterprise linux (if you want oracle, eda 
> software etc.). Many companies don't even test on anything else. I have a 
> stack of commercial chip design software here, and all of it is redhat only.

I'll agree here, too.

> So heres the cheeky proposal... make a "redhat" release. Follow redhats 
> release cycle, and match their versions. Use their backported fixes. 
> Commercial software will work. Bugs will be fixed. This is the power of open 
> source.

Why?  So users can have portage and the "commercial vendors" will still
release their stuff in RPM only and expect the exact same libraries of
the same versions to be installed with the same features as Red Hat. 
Are you also wanting to get rid of USE flags?  How about CFLAGS?  To be
able to ensure Red Hat compatibility, both of those would have to be
standardized to be exactly like Red Hat's.  This means CFLAGS would be
what Red Hat uses and we would compile with the same ./configure options
on each package.  At that point, we're wasting an enormous amount of
time trying to be Red Hat, and no time trying to make Gentoo better.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Chris Bainbridge]

On Tuesday 10 August 2004 22:24, Chris Gianelloni wrote:
> On Tue, 2004-08-10 at 16:19, Chris Bainbridge wrote:
> > So heres the cheeky proposal... make a "redhat" release. Follow redhats
> > release cycle, and match their versions. Use their backported fixes.
> > Commercial software will work. Bugs will be fixed. This is the power of
> > open source.
>
> Why?  So users can have portage and the "commercial vendors" will still
> release their stuff in RPM only and expect the exact same libraries of
> the same versions to be installed with the same features as Red Hat.

Yes.

> Are you also wanting to get rid of USE flags?  How about CFLAGS?  To be
> able to ensure Red Hat compatibility, both of those would have to be
> standardized to be exactly like Red Hat's.  This means CFLAGS would be
> what Red Hat uses and we would compile with the same ./configure options
> on each package.  At that point, we're wasting an enormous amount of
> time trying to be Red Hat, and no time trying to make Gentoo better.

Reproducing the binaries exactly is obviously not possible or desirable, but 
if you pin all the package versions then everything will be compatible; it 
would use same gcc, same binutils, libraries etc. Not perfect, but good 
enough.

I would also suggest that if this GLEP goes ahead each package maintainer  
should have a choice as to whether their package is in the frozen tree. 
Otherwise in 6 months time users will be filing bugs, getting the "won't 
support this/please upgrade" response, and complaining that its meant to be a 
frozen tree with a long bug fix cycle.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

On Tue, Aug 10, 2004 at 09:19:25PM +0100 or thereabouts, Chris Bainbridge wrote:
> So heres the cheeky proposal... make a "redhat" release. Follow redhats 
> release cycle, and match their versions. Use their backported fixes. 
> Commercial software will work. Bugs will be fixed. This is the power of open 
> source.

You're making a HUGE assumption that red hat compiles from the same sources
we compile from.  That's simply not the case.  Kernels, glibc, gcc, etc.
almost always have a number of patches that they add.  You cannot make the
blanket statement that commercial software will work.  More importantly,
you can't make the assumption that commercial software *companies* will
support their products on Gentoo, even if we're using the same version
numbers of key packages.

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Chris Bainbridge]

On Wednesday 11 August 2004 00:07, Kurt Lieber wrote:
> On Tue, Aug 10, 2004 at 09:19:25PM +0100 or thereabouts, Chris Bainbridge 
wrote:
> > So heres the cheeky proposal... make a "redhat" release. Follow redhats
> > release cycle, and match their versions. Use their backported fixes.
> > Commercial software will work. Bugs will be fixed. This is the power of
> > open source.
>
> You're making a HUGE assumption that red hat compiles from the same sources
> we compile from.  That's simply not the case.  Kernels, glibc, gcc, etc.
> almost always have a number of patches that they add.  You cannot make the
> blanket statement that commercial software will work.  More importantly,
> you can't make the assumption that commercial software *companies* will
> support their products on Gentoo, even if we're using the same version
> numbers of key packages.

er, of course I know we sometimes use sources with different patch sets. But 
generally the patches don't change the functionality of the original software 
that much. Its not impossible, but I'd be surprised to find any 3rd party 
software that failed because of that. And if it does fail, then its easy to 
check if the patches are different and find the bugfix.

Commercial companies aren't going to support gentoo anyway, but at least 
enterprises could still run their software on gentoo if they wanted to.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

On 08/10/04  Chris Bainbridge wrote:

> So heres the cheeky proposal... make a "redhat" release. Follow
> redhats release cycle, and match their versions. Use their backported
> fixes. Commercial software will work. Bugs will be fixed. This is the
> power of open source.

In that case you can just use Redhat instead. There is no point in
customizing our tree to behave like a Redhat release (e.g. what do you
do about baselayout, the initsystem, the new webapp-config, ...).

This would create a lot of work for us for (IMO) no benefit at all.

Marius

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19, reloaded (again)

[Chris Bainbridge]

On Wednesday 11 August 2004 04:21, Marius Mauch wrote:
> In that case you can just use Redhat instead. There is no point in
> customizing our tree to behave like a Redhat release (e.g. what do you
> do about baselayout, the initsystem, the new webapp-config, ...).

> This would create a lot of work for us for (IMO) no benefit at all.

The main point is reuse of manpower. Compatibility with commercial software is 
a secondary benefit. Behaving identically is not desirable or practical. 

My main concern is practicality. It isn't much work to create a list of 
essential package versions from another distros stable release and pin them 
in a frozen gentoo release. It is a lot of work to maintain a frozen tree 
that we create ourselves from scratch; please don't underestimate this! 
Everyone is discussing the technicalities of implementing a frozen tree, when 
we should be discussing whether its logistically possible. 

Questions:

How many developers are willing to support a new frozen tree every 6 months 
for their packages? After 12 months you have 3 frozen trees, as well as the 
main portage tree to support.

There are over 7000 open bugs on bugzilla with the existing tree! How are we 
going to manage and respond to bug reports from all of these frozen tree 
releases?

--
gentoo-dev@gentoo.org mailing list