[gentoo-dev] Versioning the tree

[gentoo-dev] Versioning the tree

[Steve Long]

Hi,

  There was a discussion a few weeks back about stopping system b0rkage; a
possible sol'n had been previously discussed on the fora, ie having the
tree in svn for easier branching. I understand from the recent ANNOUNCE by
Robin Johnson that svn access is now available, as well as anonymous CVS.
Kudos for all that work, guys.

>> Is it correct that versioning the tree would solve it by allowing various
>> releases to stick to lower versions of packages until they have been QAed
>> by the gentoo community?
Stuart Herbert <stuart.herbert <at> gmail.com> wrote:
> Yes.
> 
> The Gentoo package tree is a "live" tree - whatever we commit goes
> straight out to the rsync mirrors for users to download and use.
> 
> Live trees are not compatible w/ a high quality product.

Patrick McLean <chutzpah <at> gentoo.org> wrote:
> This is the entire reason for ~arch, packages are all tested in ~ for at
> least 30 days before they are stabilized by arch teams.
Well that's clearly not working is it? Seems that the users are doing the QA
in the wild ATM, and often their systems are borking, even when running
stable (or often enough.)

In any event, what I'd like to raise is the issue of having a
(semi-)official version of gentoo that lags behind the cutting-edge distro
for stability. Is this feasible?

Apologies if this is already being discussed elsewhere.

Regards,
Steve.


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Versioning the tree

[Steve Long]

> In any event, what I'd like to raise is the issue of having a
> (semi-)official version of gentoo that lags behind the cutting-edge distro
> for stability. Is this feasible?
> 
> Apologies if this is already being discussed elsewhere.
> 
I appreciate that there is GLEP 19 according to earlier discussion on this
list (from 2004).

I guess I'm asking whether it's a) more feasible now (I'm guessing yes) and
b) whether it's something that would have any support from current devs.
Not in terms of workload, but culturally.

Sorry for not being clear straight off.

Steve.


-- 
gentoo-dev@gentoo.org mailing list

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

[paul]

Steve Long schrieb:
>> In any event, what I'd like to raise is the issue of having a
>> (semi-)official version of gentoo that lags behind the cutting-edge distro
>> for stability. Is this feasible?
>>
>> Apologies if this is already being discussed elsewhere.
>>
> I appreciate that there is GLEP 19 according to earlier discussion on this
> list (from 2004).
The GLEP has been withdrawn by the author.

> 
> I guess I'm asking whether it's a) more feasible now (I'm guessing yes) and
> b) whether it's something that would have any support from current devs.
> Not in terms of workload, but culturally.
You can't take workload out of the picture since it's the main issue
here. Stable tree means backport fixes and I don't see this happening as
it can't be automated:
-there is no agreed machine parsable format/central location for CVEs/bugs.
-you can't rely on upstream issuing security patches not tied to new
releases (with new bugs/features).

So who is going to watch all that mailing lists, pulling code from
upstream, patching, testing, etc.?

Don't get me wrong. I'd really love to have a more "stable" base system
at least for core packages and those prone to break remote reboots ;)

cheers
 Paul
-- 
gentoo-dev@gentoo.org mailing list

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

[Stuart Herbert]

On 11/27/06, paul <paul@subsignal.org> wrote:
> You can't take workload out of the picture since it's the main issue
> here. Stable tree means backport fixes and I don't see this happening as
> it can't be automated:

"Stable tree means backport fixes" is an assumption, not a requirement.

It's one reason why the word "stable" is a poor choice for any such
tree, just as it is a poor choice for the current Portage tree.

I think the original poster hit the nail on the head.  The real
barrier preventing a slower-moving tree is cultural.

Best regards,
Stu
--
-- 
gentoo-dev@gentoo.org mailing list

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

[Kevin F. Quinn]

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

On Mon, 27 Nov 2006 13:02:17 +0000
"Stuart Herbert" <stuart.herbert@gmail.com> wrote:

> On 11/27/06, paul <paul@subsignal.org> wrote:
> > You can't take workload out of the picture since it's the main issue
> > here. Stable tree means backport fixes and I don't see this
> > happening as it can't be automated:
> 
> "Stable tree means backport fixes" is an assumption, not a
> requirement.
> 
> It's one reason why the word "stable" is a poor choice for any such
> tree, just as it is a poor choice for the current Portage tree.
> 
> I think the original poster hit the nail on the head.  The real
> barrier preventing a slower-moving tree is cultural.

One method could be to snapshot all package versions at the time that
Release Engineering make a release, building a package.mask file out of
it masking out all packages of higher revisions (i.e. having '>CPVR'
entry for every package in the tree in stable, and 'CPVR' if no
versions are stable).

Then, rather than back-port security fixes, this list would be updated
with security-fixed version numbers, along with minimum required updates
to dependent packages. The lists could be stored in the tree; for
example as profiles/default-linux/x86/stable.mask.

Obviously maintaining that list is some work; predominantly watching
the announcements from the security team and fixing up dependencies,
and masking out new packages (for what that's worth).  It could be
regenerated on some or all releases, or perhaps on a yearly basis.  It
would also mean that versions listed there cannot be removed from the
tree (until they're bumped in the list).

Some of that maintenance could be tool-assisted; in particular masking
new packages and finding the minimum required bumps to support a
package that was bumped for a security fix.

People who want to use it could then just soft-link
from /etc/portage/package.mask to that list.

It's just a suggestion - I'm not prepared to do the work ;)  However it
might be a simple but effective method to help people maintain secure
but relatively stable systems, without having to upgrade umpteen
packages a week.

-- 
Kevin F. Quinn

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

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

[Marius Mauch]

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

On Mon, 27 Nov 2006 11:33:58 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:

> > In any event, what I'd like to raise is the issue of having a
> > (semi-)official version of gentoo that lags behind the cutting-edge
> > distro for stability. Is this feasible?
> > 
> > Apologies if this is already being discussed elsewhere.
> > 
> I appreciate that there is GLEP 19 according to earlier discussion on
> this list (from 2004).
> 
> I guess I'm asking whether it's a) more feasible now (I'm guessing
> yes) and b) whether it's something that would have any support from
> current devs. Not in terms of workload, but culturally.
> 
> Sorry for not being clear straight off.

See http://forums.gentoo.org/viewtopic-p-3730878.html#3730878 for a
related discussion.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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

Re: [gentoo-dev] Versioning the tree

[Alec Warner]

Steve Long wrote:
> Hi,
> 
>   There was a discussion a few weeks back about stopping system b0rkage; a
> possible sol'n had been previously discussed on the fora, ie having the
> tree in svn for easier branching. I understand from the recent ANNOUNCE by
> Robin Johnson that svn access is now available, as well as anonymous CVS.
> Kudos for all that work, guys.
> 

Just a note, that the Tree itself is not in SVN; the SVN repositories 
only hold ancillary Gentoo projects, such as portage and gentoolkit and 
whatnot.  The tree is still stored in CVS.

-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Mon, 2006-11-27 at 11:33 +0000, Steve Long wrote:
> > In any event, what I'd like to raise is the issue of having a
> > (semi-)official version of gentoo that lags behind the cutting-edge distro
> > for stability. Is this feasible?
> > 
> > Apologies if this is already being discussed elsewhere.
> > 
> I appreciate that there is GLEP 19 according to earlier discussion on this
> list (from 2004).
> 
> I guess I'm asking whether it's a) more feasible now (I'm guessing yes) and

It isn't.

> b) whether it's something that would have any support from current devs.

Probably not, considering even the people that were proponents of GLEP19
have dropped support for it.

Personally, I would prefer seeing my "release trees" idea take off.
Essentially, it freezes the tree at a certain point (which I just
coincide with our releases).  Updates are security-only.

Now, this doesn't mean that *everything* must remain this way.  For
example, there could be a 2007.0-r1 "tree" or something which is
2007.0's tree, with some major bug fixes.  The real question is how much
manpower would it take to maintain such a tree and how much use would
"normal" users get out of it, as opposed to "enterprise" users?

I'm thinking of releasing a tarball for a "release tree" next time
around, just to see how it flies.  The main question I have is whether
we'll have time.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

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

[Chris Gianelloni]

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

On Mon, 2006-11-27 at 13:02 +0000, Stuart Herbert wrote:
> I think the original poster hit the nail on the head.  The real
> barrier preventing a slower-moving tree is cultural.

Somewhat.

As I have said, I've mentioned several times the idea of doing a
"release tree" to go along with each release.  Support on these trees
would be essentially equivalent to our security support model.  We would
support only packages marked stable.  Of course, we also understand that
since we're building off upstream's work, there *will* be times when a
version bump is necessary to reduce our workload.  Basically, our rule
is kinda like this.

No version changes on any packages, except those which are necessary due
to a security violation, or a vulnerable package's dependencies.

Now, I don't know if it is the best approach, but it is the best one
that I could come up with on my own that allows for a slow-moving tree
with higher QA done on it (as the release trees are what we use for
releases, they undergo an enormous amount of testing, in the default
configuration, of course) and minimal changes.

Something that would be useful would be for package maintainers that
wish to participate to perform further testing and validation on
packages in the release snapshot prior to its final freeze.  This would
give us even more eyes on the tree and hopefully provide a much higher
quality snapshot once we're done.

Since it seems that there is still interest in the idea, I'll start
working on it some more.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

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

[Chris Gianelloni]

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

On Mon, 2006-11-27 at 16:18 +0100, Kevin F. Quinn wrote:
> One method could be to snapshot all package versions at the time that
> Release Engineering make a release, building a package.mask file out of
> it masking out all packages of higher revisions (i.e. having '>CPVR'
> entry for every package in the tree in stable, and 'CPVR' if no
> versions are stable).

It would be infinitely easier to create a tree just for this.

> Then, rather than back-port security fixes, this list would be updated
> with security-fixed version numbers, along with minimum required updates
> to dependent packages. The lists could be stored in the tree; for
> example as profiles/default-linux/x86/stable.mask.

This is essentially the idea that my release tree uses, except the tree
itself is completely stripped down to stable packages.  I have a script
which already does several things:

#1. grabs "best_visible" for stable on each arch
#2. repeat for each SLOT
#3. purge unnecessary files from FILESDIR
#4. strip to only "stable" profiles from profiles.desc
#5. purge unnecessary USE from use.local.desc and use.desc
#6. strip unused eclasses
#7. regenerate Manifest (via ebuild $foo digest)

I had also planned on it doing the following, but they haven't been
implemented just yet:

- strip all USE flags that aren't used from use.mask (per-profile)
- strip all packages that aren't available from package.mask
(per-profile)

What this gives us is a *much* smaller tree, as it only includes stable
packages/versions.

> Obviously maintaining that list is some work; predominantly watching
> the announcements from the security team and fixing up dependencies,
> and masking out new packages (for what that's worth).  It could be
> regenerated on some or all releases, or perhaps on a yearly basis.  It
> would also mean that versions listed there cannot be removed from the
> tree (until they're bumped in the list).

Well, the simpler approach was to simply copy over the newer, secure
ebuilds, and any required dependencies, into the release tree.  There'd
be no need to update mask files and such this way.  It would also be
generated with the releases, automatically.

> Some of that maintenance could be tool-assisted; in particular masking
> new packages and finding the minimum required bumps to support a
> package that was bumped for a security fix.
> 
> People who want to use it could then just soft-link
> from /etc/portage/package.mask to that list.
> 
> It's just a suggestion - I'm not prepared to do the work ;)  However it
> might be a simple but effective method to help people maintain secure
> but relatively stable systems, without having to upgrade umpteen
> packages a week.

Well, I am willing, and have been doing, some of the work.  The one
disadvantage to my design is it needs infra.  It needs it's own
repository and rsync.

Basically, it makes the system act a bit more like some other
development models.  We end up with the following:

rsync://rsync.gentoo.org/gentoo-portage (this is equivalent to -current)
rsync://rsync.gentoo.org/2007.0-release (this is the release tree)

Now, the release trees are non-moving.  The 2007.0-release tree is
*always* the 2007.0-release tree for as long as we decide to support it.
Likely, this support period would begin as a single release and get
extended as volunteers came around to support it.  New releases get
their own tree.

I also started writing a tool to "upgrade" the distribution.  The tool
reads pre and post scripts for the upgrade, and performs the necessary
steps.  Basically, a user can "dist-upgrade 2007.1" and the system
would:

- switch to the "2007.1" tree and "emerge --sync"
- perform all "pre" steps from 2007.1
- update world + revdep-rebuild + whatever else is necessary
- perform all "post" steps

With this, there would be a special "version" called "current" which
would put the user on the "gentoo-portage" tree, AKA the tree we all
know and love/loathe.  Release trees wouldn't have "arch" and "~arch" as
everything would be stable there.  Testing would be done in the main
tree.  This, in essence, gives us "testing", "release candidate" and
"stable" environments, with the release trees being stable, and the
current tree becoming test/release candidate.  Anything marked stable in
the current tree would be a candidate for stable in the next release
tree.

Users who want to use the current portage tree get what they want.
Users who want a more stable tree get what they want.  Basically,
everyone (hopefully) is happy, or at least as happy as we can feasibly
make them.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

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

[James Potts]

On 11/28/06, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> On Mon, 2006-11-27 at 16:18 +0100, Kevin F. Quinn wrote:
> > One method could be to snapshot all package versions at the time that
> > Release Engineering make a release, building a package.mask file out of
> > it masking out all packages of higher revisions (i.e. having '>CPVR'
> > entry for every package in the tree in stable, and 'CPVR' if no
> > versions are stable).
>
> It would be infinitely easier to create a tree just for this.
>
> > Then, rather than back-port security fixes, this list would be updated
> > with security-fixed version numbers, along with minimum required updates
> > to dependent packages. The lists could be stored in the tree; for
> > example as profiles/default-linux/x86/stable.mask.
>
> This is essentially the idea that my release tree uses, except the tree
> itself is completely stripped down to stable packages.  I have a script
> which already does several things:
>
> #1. grabs "best_visible" for stable on each arch
> #2. repeat for each SLOT
> #3. purge unnecessary files from FILESDIR
> #4. strip to only "stable" profiles from profiles.desc
> #5. purge unnecessary USE from use.local.desc and use.desc
> #6. strip unused eclasses
> #7. regenerate Manifest (via ebuild $foo digest)
>
> I had also planned on it doing the following, but they haven't been
> implemented just yet:
>
> - strip all USE flags that aren't used from use.mask (per-profile)
> - strip all packages that aren't available from package.mask
> (per-profile)
>
> What this gives us is a *much* smaller tree, as it only includes stable
> packages/versions.
>
> > Obviously maintaining that list is some work; predominantly watching
> > the announcements from the security team and fixing up dependencies,
> > and masking out new packages (for what that's worth).  It could be
> > regenerated on some or all releases, or perhaps on a yearly basis.  It
> > would also mean that versions listed there cannot be removed from the
> > tree (until they're bumped in the list).
>
> Well, the simpler approach was to simply copy over the newer, secure
> ebuilds, and any required dependencies, into the release tree.  There'd
> be no need to update mask files and such this way.  It would also be
> generated with the releases, automatically.
>
> > Some of that maintenance could be tool-assisted; in particular masking
> > new packages and finding the minimum required bumps to support a
> > package that was bumped for a security fix.
> >
> > People who want to use it could then just soft-link
> > from /etc/portage/package.mask to that list.
> >
> > It's just a suggestion - I'm not prepared to do the work ;)  However it
> > might be a simple but effective method to help people maintain secure
> > but relatively stable systems, without having to upgrade umpteen
> > packages a week.
>
> Well, I am willing, and have been doing, some of the work.  The one
> disadvantage to my design is it needs infra.  It needs it's own
> repository and rsync.
>
> Basically, it makes the system act a bit more like some other
> development models.  We end up with the following:
>
> rsync://rsync.gentoo.org/gentoo-portage (this is equivalent to -current)
> rsync://rsync.gentoo.org/2007.0-release (this is the release tree)
>
> Now, the release trees are non-moving.  The 2007.0-release tree is
> *always* the 2007.0-release tree for as long as we decide to support it.
> Likely, this support period would begin as a single release and get
> extended as volunteers came around to support it.  New releases get
> their own tree.
>
> I also started writing a tool to "upgrade" the distribution.  The tool
> reads pre and post scripts for the upgrade, and performs the necessary
> steps.  Basically, a user can "dist-upgrade 2007.1" and the system
> would:
>
> - switch to the "2007.1" tree and "emerge --sync"
> - perform all "pre" steps from 2007.1
> - update world + revdep-rebuild + whatever else is necessary
> - perform all "post" steps
>
> With this, there would be a special "version" called "current" which
> would put the user on the "gentoo-portage" tree, AKA the tree we all
> know and love/loathe.  Release trees wouldn't have "arch" and "~arch" as
> everything would be stable there.  Testing would be done in the main
> tree.  This, in essence, gives us "testing", "release candidate" and
> "stable" environments, with the release trees being stable, and the
> current tree becoming test/release candidate.  Anything marked stable in
> the current tree would be a candidate for stable in the next release
> tree.
>
> Users who want to use the current portage tree get what they want.
> Users who want a more stable tree get what they want.  Basically,
> everyone (hopefully) is happy, or at least as happy as we can feasibly
> make them.
>

This looks good on the surface, Chris, but what happens in the case
where somebody wants to use the Release tree, but also wants (or
needs) one or more packages from the Live tree, and doesn't want to
switch completely over to the live tree?  If I understand what you
want to do correctly, the Release tree would include only stable
packages.  Other packages wouldn't just be masked, they would be
completely unavailable to anybody using that tree.

I like the idea of having a stable p.mask much better, which says
"profile" to me.  Any thoughts on a special profile just for releases?

--Arek (James Potts)
arek75@gmail.com
-- 
gentoo-dev@gentoo.org mailing list

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

[Caleb Cushing]

they could pull the more current ebuilds and put them in an overlay.
also correct me if I'm wrong isn't it possible only to sync certain
parts of the tree using excludes. maybe some additional functionality
saying only sync package X for updates.

On 11/28/06, James Potts <arek75@gmail.com> wrote:
> On 11/28/06, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> > On Mon, 2006-11-27 at 16:18 +0100, Kevin F. Quinn wrote:
> > > One method could be to snapshot all package versions at the time that
> > > Release Engineering make a release, building a package.mask file out of
> > > it masking out all packages of higher revisions (i.e. having '>CPVR'
> > > entry for every package in the tree in stable, and 'CPVR' if no
> > > versions are stable).
> >
> > It would be infinitely easier to create a tree just for this.
> >
> > > Then, rather than back-port security fixes, this list would be updated
> > > with security-fixed version numbers, along with minimum required updates
> > > to dependent packages. The lists could be stored in the tree; for
> > > example as profiles/default-linux/x86/stable.mask.
> >
> > This is essentially the idea that my release tree uses, except the tree
> > itself is completely stripped down to stable packages.  I have a script
> > which already does several things:
> >
> > #1. grabs "best_visible" for stable on each arch
> > #2. repeat for each SLOT
> > #3. purge unnecessary files from FILESDIR
> > #4. strip to only "stable" profiles from profiles.desc
> > #5. purge unnecessary USE from use.local.desc and use.desc
> > #6. strip unused eclasses
> > #7. regenerate Manifest (via ebuild $foo digest)
> >
> > I had also planned on it doing the following, but they haven't been
> > implemented just yet:
> >
> > - strip all USE flags that aren't used from use.mask (per-profile)
> > - strip all packages that aren't available from package.mask
> > (per-profile)
> >
> > What this gives us is a *much* smaller tree, as it only includes stable
> > packages/versions.
> >
> > > Obviously maintaining that list is some work; predominantly watching
> > > the announcements from the security team and fixing up dependencies,
> > > and masking out new packages (for what that's worth).  It could be
> > > regenerated on some or all releases, or perhaps on a yearly basis.  It
> > > would also mean that versions listed there cannot be removed from the
> > > tree (until they're bumped in the list).
> >
> > Well, the simpler approach was to simply copy over the newer, secure
> > ebuilds, and any required dependencies, into the release tree.  There'd
> > be no need to update mask files and such this way.  It would also be
> > generated with the releases, automatically.
> >
> > > Some of that maintenance could be tool-assisted; in particular masking
> > > new packages and finding the minimum required bumps to support a
> > > package that was bumped for a security fix.
> > >
> > > People who want to use it could then just soft-link
> > > from /etc/portage/package.mask to that list.
> > >
> > > It's just a suggestion - I'm not prepared to do the work ;)  However it
> > > might be a simple but effective method to help people maintain secure
> > > but relatively stable systems, without having to upgrade umpteen
> > > packages a week.
> >
> > Well, I am willing, and have been doing, some of the work.  The one
> > disadvantage to my design is it needs infra.  It needs it's own
> > repository and rsync.
> >
> > Basically, it makes the system act a bit more like some other
> > development models.  We end up with the following:
> >
> > rsync://rsync.gentoo.org/gentoo-portage (this is equivalent to -current)
> > rsync://rsync.gentoo.org/2007.0-release (this is the release tree)
> >
> > Now, the release trees are non-moving.  The 2007.0-release tree is
> > *always* the 2007.0-release tree for as long as we decide to support it.
> > Likely, this support period would begin as a single release and get
> > extended as volunteers came around to support it.  New releases get
> > their own tree.
> >
> > I also started writing a tool to "upgrade" the distribution.  The tool
> > reads pre and post scripts for the upgrade, and performs the necessary
> > steps.  Basically, a user can "dist-upgrade 2007.1" and the system
> > would:
> >
> > - switch to the "2007.1" tree and "emerge --sync"
> > - perform all "pre" steps from 2007.1
> > - update world + revdep-rebuild + whatever else is necessary
> > - perform all "post" steps
> >
> > With this, there would be a special "version" called "current" which
> > would put the user on the "gentoo-portage" tree, AKA the tree we all
> > know and love/loathe.  Release trees wouldn't have "arch" and "~arch" as
> > everything would be stable there.  Testing would be done in the main
> > tree.  This, in essence, gives us "testing", "release candidate" and
> > "stable" environments, with the release trees being stable, and the
> > current tree becoming test/release candidate.  Anything marked stable in
> > the current tree would be a candidate for stable in the next release
> > tree.
> >
> > Users who want to use the current portage tree get what they want.
> > Users who want a more stable tree get what they want.  Basically,
> > everyone (hopefully) is happy, or at least as happy as we can feasibly
> > make them.
> >
>
> This looks good on the surface, Chris, but what happens in the case
> where somebody wants to use the Release tree, but also wants (or
> needs) one or more packages from the Live tree, and doesn't want to
> switch completely over to the live tree?  If I understand what you
> want to do correctly, the Release tree would include only stable
> packages.  Other packages wouldn't just be masked, they would be
> completely unavailable to anybody using that tree.
>
> I like the idea of having a stable p.mask much better, which says
> "profile" to me.  Any thoughts on a special profile just for releases?
>
> --Arek (James Potts)
> arek75@gmail.com
> --
> gentoo-dev@gentoo.org mailing list
>
>
-- 
gentoo-dev@gentoo.org mailing list

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

[Andrew Gaffney]

James Potts wrote:
> This looks good on the surface, Chris, but what happens in the case
> where somebody wants to use the Release tree, but also wants (or
> needs) one or more packages from the Live tree, and doesn't want to
> switch completely over to the live tree?  If I understand what you
> want to do correctly, the Release tree would include only stable
> packages.  Other packages wouldn't just be masked, they would be
> completely unavailable to anybody using that tree.

This is what overlays are for :)

-- 
Andrew Gaffney                            http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer                                   Installer Project
Today's lesson in political correctness:      "Go asphyxiate on a phallus"
-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Tue, 2006-11-28 at 14:56 -0600, James Potts wrote:
> This looks good on the surface, Chris, but what happens in the case
> where somebody wants to use the Release tree, but also wants (or
> needs) one or more packages from the Live tree, and doesn't want to
> switch completely over to the live tree?  If I understand what you
> want to do correctly, the Release tree would include only stable
> packages.  Other packages wouldn't just be masked, they would be
> completely unavailable to anybody using that tree.

Correct.  The whole concept of the release tree is it is a complete
package.  All of the parts are supposed to work together.  There's
*nothing* that is not considered stable.  If you need other packages,
you add them to an overlay and support them yourself.

> I like the idea of having a stable p.mask much better, which says
> "profile" to me.  Any thoughts on a special profile just for releases?

It is completely unworkable with the 11,000+ packages we currently have
in the tree, whereas an automated script that parses the current tree is
much simpler.  Quite simply, when GLEP19 was being worked on, it became
painfully obvious almost immediately that even with the 10+ people who
volunteered to work on it, that it would be impossible to maintain a
profile-based system.  We estimated that it would take us more than
twice as many developers working on *only* the stable tree than we had
working on the "live" tree to even keep up.

To put it simply, I have *zero* interest in any profile/mask-based
concepts for providing "stable" as they don't work.  All they do is
create an enormous bottleneck and a massive amount of workload for every
single developer.  With the release trees, essentially only those
interested in supporting the tree are required to work on it.  The tree
is created entirely by scripts and is tested *before* it's released on
the public.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

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

[Stuart Herbert]

On 11/28/06, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> As I have said, I've mentioned several times the idea of doing a
> "release tree" to go along with each release.

The release tree is not the basis for this.

a) Releases (and the releng work that goes into it) are exclusively
desktop-oriented.
b) Release trees have a nasty habit of picking up last minute changes
(such as gcc 4.1) to suit the release, not stability.

> No version changes on any packages, except those which are necessary due
> to a security violation, or a vulnerable package's dependencies.

Tying a minimal-b0rkage tree to the arbitrary schedule of our releases
does not serve all of our users.  We are back to the same arguments we
had when I said that the Seeds project would have to have its own
independent release schedules :(

Thereś little merit in us creating mostly stagnant trees.  Other Linux
distros are already very good at doing that - far better than we will
be at it - because they have advantages such as a paid workforce and
more upstream developers on their books.

A minimal-b0rkage tree needs to move to reflect the packages that we
believe our users should be using for a stable environment.

Best regards,
Stu

-- 
gentoo-dev@gentoo.org mailing list

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

[Stephen P. Becker]

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

On Tue, 28 Nov 2006 14:56:47 -0600
"James Potts" <arek75@gmail.com> wrote:

> This looks good on the surface, Chris, but what happens in the case
> where somebody wants to use the Release tree, but also wants (or
> needs) one or more packages from the Live tree, and doesn't want to
> switch completely over to the live tree?  If I understand what you
> want to do correctly, the Release tree would include only stable
> packages.  Other packages wouldn't just be masked, they would be
> completely unavailable to anybody using that tree.
> 
> I like the idea of having a stable p.mask much better, which says
> "profile" to me.  Any thoughts on a special profile just for releases?

Sounds like a perfect situation to use a package manager with true
multiple repository support.

-Steve

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

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

[Andrew Gaffney]

Stuart Herbert wrote:
> On 11/28/06, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
>> As I have said, I've mentioned several times the idea of doing a
>> "release tree" to go along with each release.
> 
> The release tree is not the basis for this.
> 
> a) Releases (and the releng work that goes into it) are exclusively
> desktop-oriented.

You make it sound like releng doesn't care at all about non-desktop packages. 
The reason for the "exclusivity" is that the media that's typically built for 
release (GRP, LiveCD) is targetted for the largest audience...desktop users. If 
someone wants to volunteer to create a set of server-related GRP and a server 
LiveCD (as silly as this is for most things), they wouldn't be blocked outright.

> b) Release trees have a nasty habit of picking up last minute changes
> (such as gcc 4.1) to suit the release, not stability.

Gcc 4.1.1 wasn't a last minute change. The release snapshots are originally 
created a month or more before the actual release. As stuff is stabilized in the 
tree, it's stabilized in the release snapshot as well. During the release cycle, 
we planned for gcc-4.1.1 to be stable by release (at least for x86, amd64, and a 
few other arches). We had it stable in the release snapshot a few weeks before 
the tree did and were testing the crap out of it.

>> No version changes on any packages, except those which are necessary due
>> to a security violation, or a vulnerable package's dependencies.
> 
> Tying a minimal-b0rkage tree to the arbitrary schedule of our releases
> does not serve all of our users.  We are back to the same arguments we
> had when I said that the Seeds project would have to have its own
> independent release schedules :(

The "release tree" isn't really for minimal breakage. The *real* intent (at 
least from my POV) is to have a non-moving target for vendors to certify their 
software against (wouldn't it be nice for Oracle to be actually supported on 
Gentoo 2007.0 or something like that?), and so admins don't have to do the 
"upgrade dance" once a week or even every day (like I do).

> Thereś little merit in us creating mostly stagnant trees.  Other Linux
> distros are already very good at doing that - far better than we will
> be at it - because they have advantages such as a paid workforce and
> more upstream developers on their books.

The "non-stagnant" nature of Gentoo isn't the only reason that people use 
Gentoo. People use Gentoo for the configurability and customizability. As 
someone who admins more than a handful of Gentoo servers, I would absolutely 
*love* the combo of Gentoo's flexibility and a non-moving tree to make upgrades 
easier to deal with.

-- 
Andrew Gaffney                            http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer                                   Installer Project
Today's lesson in political correctness:      "Go asphyxiate on a phallus"
-- 
gentoo-dev@gentoo.org mailing list

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

[Steve Long]

Chris Gianelloni wrote:

> I have a script which already does several things:
> 
> #1. grabs "best_visible" for stable on each arch
> #2. repeat for each SLOT
> #3. purge unnecessary files from FILESDIR
> #4. strip to only "stable" profiles from profiles.desc
> #5. purge unnecessary USE from use.local.desc and use.desc
> #6. strip unused eclasses
> #7. regenerate Manifest (via ebuild $foo digest)
> 
> I had also planned on it doing the following, but they haven't been
> implemented just yet:
> 
> - strip all USE flags that aren't used from use.mask (per-profile)
> - strip all packages that aren't available from package.mask
> (per-profile)
> 
> What this gives us is a *much* smaller tree, as it only includes stable
> packages/versions.
>
The smaller tree sounds great in terms of maintenance for the volunteers who
maintain the release.
 
>> Obviously maintaining that list is some work; predominantly watching
>> the announcements from the security team and fixing up dependencies,
>> and masking out new packages (for what that's worth).  It could be
>> regenerated on some or all releases, or perhaps on a yearly basis.  It
>> would also mean that versions listed there cannot be removed from the
>> tree (until they're bumped in the list).
> 
> Well, the simpler approach was to simply copy over the newer, secure
> ebuilds, and any required dependencies, into the release tree.  There'd
> be no need to update mask files and such this way.  It would also be
> generated with the releases, automatically.
> 
<snip> .. The one
> disadvantage to my design is it needs infra.  It needs it's own
> repository and rsync.
> 
What does that entail? Would a co-located server suffice? 

(If it gets popular, I'd imagine those mirroring current rsyncs etc would
want to mirror the releases as well.)

> Basically, it makes the system act a bit more like some other
> development models.  We end up with the following:
> 
> rsync://rsync.gentoo.org/gentoo-portage (this is equivalent to -current)
> rsync://rsync.gentoo.org/2007.0-release (this is the release tree)
> 
> Now, the release trees are non-moving.  The 2007.0-release tree is
> *always* the 2007.0-release tree for as long as we decide to support it.
> Likely, this support period would begin as a single release and get
> extended as volunteers came around to support it.  New releases get
> their own tree.
> 
Well count me in as a volunteer to help set this up and maintain an x86
release. I'm a pretty good coder if that helps.

> I also started writing a tool to "upgrade" the distribution.  The tool
> reads pre and post scripts for the upgrade, and performs the necessary
> steps.  Basically, a user can "dist-upgrade 2007.1" and the system
> would:
> 
> - switch to the "2007.1" tree and "emerge --sync"
> - perform all "pre" steps from 2007.1
> - update world + revdep-rebuild + whatever else is necessary
> - perform all "post" steps
> 
> With this, there would be a special "version" called "current" which
> would put the user on the "gentoo-portage" tree, AKA the tree we all
> know and love/loathe.  Release trees wouldn't have "arch" and "~arch" as
> everything would be stable there.  Testing would be done in the main
> tree.  This, in essence, gives us "testing", "release candidate" and
> "stable" environments, with the release trees being stable, and the
> current tree becoming test/release candidate.  Anything marked stable in
> the current tree would be a candidate for stable in the next release
> tree.
> 
This sounds like a much more professional proposition to put to an IT exec.

> Users who want to use the current portage tree get what they want.
> Users who want a more stable tree get what they want.  Basically,
> everyone (hopefully) is happy, or at least as happy as we can feasibly
> make them.
> 
This all sounds great. Respect for the work you've already put in.

other post:
> With the release trees, essentially only those
> interested in supporting the tree are required to work on it.  The tree
> is created entirely by scripts and is tested before it's released on
> the public.

Having it automated is definitely what I wanted to know about in the
original discussion.

>From your post we need to add:
> - strip all USE flags that aren't used from use.mask (per-profile)
> - strip all packages that aren't available from package.mask
> (per-profile)

What language is the script implemented in?

Wrt security updates, is it possible to tie into GLSAs so that we could
automate updating packages that need it? By updating I mean adding the
ebuilds and any dependencies (or dependants that might require updating.)

Caleb Cushing wrote:
> .. isn't it possible only to sync certain
> parts of the tree using excludes. maybe some additional functionality
> saying only sync package X for updates.

Would that help in terms of having say, up to date GUI packages, or is it
just easier to use overlays?

Chris Gianelloni wrote:

> No version changes on any packages, except those which are necessary due
> to a security violation, or a vulnerable package's dependencies.
> 
I could imagine a situation where a dependant package (ie one using the
package updated) would also require an update. It'd be rare though, so I
guess it wouldn't need automating.

> Now, I don't know if it is the best approach, but it is the best one
> that I could come up with on my own that allows for a slow-moving tree
> with higher QA done on it (as the release trees are what we use for
> releases, they undergo an enormous amount of testing, in the default
> configuration, of course) and minimal changes.
> 
It sounds like the right approach to me. There's all the custom approach of
gentoo, eg overlays, so users can always stay up to date with anything they
particularly want.

> Something that would be useful would be for package maintainers that
> wish to participate to perform further testing and validation on
> packages in the release snapshot prior to its final freeze.  This would
> give us even more eyes on the tree and hopefully provide a much higher
> quality snapshot once we're done.

It sounds like it'd also make the releases in general have better QA. What
do package/ herd maintainers think?

-- 
gentoo-dev@gentoo.org mailing list

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

[Alec Warner]

Steve Long wrote:

> <snip> .. The one
>> disadvantage to my design is it needs infra.  It needs it's own
>> repository and rsync.
>>
> What does that entail? Would a co-located server suffice? 
> 
> (If it gets popular, I'd imagine those mirroring current rsyncs etc would
> want to mirror the releases as well.)
> 

One of the problems here (IIRC) is that our mirrors are quite full.  Not 
only must you mirror the release tree (which is trivial in size) you 
also have to mirror the distfiles for that tree.  Right now our 
distfiles are maintained by a wonderful python script that checks the 
files in SRC_URI and fetches them to the master when needed; when an 
ebuild is removed from CVS, the fetcher will not fetch the file and it 
will get removed (after two weeks, afaik).

The bonus is that we then need to have a fetcher that runs over the main 
tree and all supported release trees, and this of course increases 
mirror size as we now have distfiles in the tree from a year ago to 
support a year old release.  I am unsure how much space this would take 
up; but this is an obstacle that must be overcome (somehow), preferably 
by giving infra an estimate on the space reqs.


-- 
gentoo-dev@gentoo.org mailing list

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

[Stuart Herbert]

On 11/28/06, Andrew Gaffney <agaffney@gentoo.org> wrote:
> You make it sound like releng doesn't care at all about non-desktop packages.

That wasn't how it was meant.  Was simply meant as a statement of
fact.  Releng activities are currently exclusively desktop-oriented.
Until that changes, releng snapshots aren't fit for the purpose of
being a non-moving tree, as far as servers are concerned.

> The reason for the "exclusivity" is that the media that's typically built for
> release (GRP, LiveCD) is targetted for the largest audience...desktop users. If
> someone wants to volunteer to create a set of server-related GRP and a server
> LiveCD (as silly as this is for most things), they wouldn't be blocked outright.

I'd like to see some figures proving that our largest audience is
desktop users.  I'm not prepared to take that on faith.  (Alas,
producing these figures is non-trivial in the extreme, if not
impossible).

> > b) Release trees have a nasty habit of picking up last minute changes
> > (such as gcc 4.1) to suit the release, not stability.
>
> Gcc 4.1.1 wasn't a last minute change.

I can't agree with you there.  It doesn't matter how many months of
planning and work you guys put into getting gcc-4.1 fit for stable.
If you're doing it off in your own little corner of the world, and
then springing it on the rest of us just days before the release
happens, then to the much larger dev community, it comes as a last
minute change.

If you're "testing the crap" out of something, but only in an
exclusively desktop-oriented way ... well, that can only really be
partial testing, can't it?

> The "release tree" isn't really for minimal breakage.

But that is what Steve (who started this thread) asked for.  And what
he has asked for in his previous thread too.

> The *real* intent (at
> least from my POV) is to have a non-moving target for vendors to certify their
> software against (wouldn't it be nice for Oracle to be actually supported on
> Gentoo 2007.0 or something like that?),

Well, there's a dichotamy here.  Sun were able to certify Gentoo
against their hardware without such a tree.  Has anyone approached
Oracle and asked them what their actual requirements are?  Do Oracle
actually want to certify Oracle on Gentoo at all?

I personally deplore this habit of trying to second guess what someone
else wants.  Assumptions are the mother of all fuckups.  Let's see an
email to -dev from someone at Oracle w/ their shopping list of needs,
and then base the discussion around that.

> and so admins don't have to do the
> "upgrade dance" once a week or even every day (like I do).

A slower-moving tree will substantially reduce this amount of work,
but it isn't going to go away, unless your boxes are on a private
network w/ no local security threats at all.

There'll always be GLSA's to respond to.  That's another issue that
needs to be handled w/ a slow-moving tree.  Are you going to restrict
changes in the slow-moving tree only to changes against a GLSA?

> The "non-stagnant" nature of Gentoo isn't the only reason that people use
> Gentoo. People use Gentoo for the configurability and customizability. As
> someone who admins more than a handful of Gentoo servers, I would absolutely
> *love* the combo of Gentoo's flexibility and a non-moving tree to make upgrades
> easier to deal with.

I honestly don't think you're ever going to get that out of Gentoo,
because of the lack of backporting.  Can you live with a slower-moving
tree?  Or do you personally really need a non-moving tree?

If you really need a non-moving tree, I think you're better off with
RHES or Ubuntu.

Best regards,
Stu
-- 
gentoo-dev@gentoo.org mailing list

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

[Andrew Gaffney]

Stuart Herbert wrote:
>> > b) Release trees have a nasty habit of picking up last minute changes
>> > (such as gcc 4.1) to suit the release, not stability.
>>
>> Gcc 4.1.1 wasn't a last minute change.
> 
> I can't agree with you there.  It doesn't matter how many months of
> planning and work you guys put into getting gcc-4.1 fit for stable.
> If you're doing it off in your own little corner of the world, and
> then springing it on the rest of us just days before the release
> happens, then to the much larger dev community, it comes as a last
> minute change.

The 3-4 weeks of releng filing a ton of "doesn't build with gcc-4.1.1" bugs 
wasn't a big enough clue? :) Also, the arch teams (or at least the arch's 
release coordinator...if they didn't tell the rest of their team, that's not 
releng's fault) that were moving to it and people in base-system working on it 
were "in the know".

>> The "release tree" isn't really for minimal breakage.
> 
> But that is what Steve (who started this thread) asked for.  And what
> he has asked for in his previous thread too.

Well, wolf31o2 has been floating around this idea for quite a while, and I'm 
speaking from the POV of his ideas. The "minimal b0rkage" tree is far less 
likely to happen due to the extra manpower involved.

>> The *real* intent (at
>> least from my POV) is to have a non-moving target for vendors to 
>> certify their
>> software against (wouldn't it be nice for Oracle to be actually 
>> supported on
>> Gentoo 2007.0 or something like that?),
> 
> Well, there's a dichotamy here.  Sun were able to certify Gentoo
> against their hardware without such a tree.  Has anyone approached
> Oracle and asked them what their actual requirements are?  Do Oracle
> actually want to certify Oracle on Gentoo at all?

Certifying hardware and software are 2 completely different things. Also, I'm 
not sure that Sun certifying their hardware even meant anything. The T2000 dev 
box has been seeing random lockups and other weird problems, although, that may 
be related to the fact that it recently "lost" 16GB of memory due to an error 
detected by the diagnostics. As for the Oracle example, it was just that...an 
example.

>> and so admins don't have to do the
>> "upgrade dance" once a week or even every day (like I do).
> 
> A slower-moving tree will substantially reduce this amount of work,
> but it isn't going to go away, unless your boxes are on a private
> network w/ no local security threats at all.
> 
> There'll always be GLSA's to respond to.  That's another issue that
> needs to be handled w/ a slow-moving tree.  Are you going to restrict
> changes in the slow-moving tree only to changes against a GLSA?

Yes, that's part of wolf31o2's idea. The tree would be "non-moving" except for 
GLSA's and any dependencies required by the updated version of the 
security-affected package.

>> The "non-stagnant" nature of Gentoo isn't the only reason that people use
>> Gentoo. People use Gentoo for the configurability and customizability. As
>> someone who admins more than a handful of Gentoo servers, I would 
>> absolutely
>> *love* the combo of Gentoo's flexibility and a non-moving tree to make 
>> upgrades
>> easier to deal with.
> 
> I honestly don't think you're ever going to get that out of Gentoo,
> because of the lack of backporting.  Can you live with a slower-moving
> tree?  Or do you personally really need a non-moving tree?

A slower-moving (or "non-moving" with security updates) tree is perfect for me, 
and I'm sure for many other people as well.

-- 
Andrew Gaffney                            http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer                                   Installer Project
Today's lesson in political correctness:      "Go asphyxiate on a phallus"
-- 
gentoo-dev@gentoo.org mailing list

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

[Andrew Gaffney]

Steve Long wrote:
> Chris Gianelloni wrote:
> From your post we need to add:
>> - strip all USE flags that aren't used from use.mask (per-profile)
>> - strip all packages that aren't available from package.mask
>> (per-profile)
> 
> What language is the script implemented in?

The current script is actually 2 scripts: a python script that I wrote that 
interfaces with the portage API and a bash script that wolf31o2 wrote that takes 
the output from my script and does the cleanup.

Last night, with the help of ferringb, I started working on a replacement script 
that uses the pkgcore API. The portage-based script takes quite a while to run, 
and gets it wrong if there are any p.mask'd stable packages on any arch or other 
weird things. The pkgcore-based script actually uses the profiles properly and 
runs over the entire tree with all the "stable" profiles (according to 
profiles.desc) in 1m1.869s (on my box). I'll probably end up combining the 
scripts and doing the cleanup in python to make things easier.

> Wrt security updates, is it possible to tie into GLSAs so that we could
> automate updating packages that need it? By updating I mean adding the
> ebuilds and any dependencies (or dependants that might require updating.)

I'm not sure this is the best idea.

> Caleb Cushing wrote:
>> .. isn't it possible only to sync certain
>> parts of the tree using excludes. maybe some additional functionality
>> saying only sync package X for updates.
> 
> Would that help in terms of having say, up to date GUI packages, or is it
> just easier to use overlays?

Overlays are definitely best here.

-- 
Andrew Gaffney                            http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer                                   Installer Project
Today's lesson in political correctness:      "Go asphyxiate on a phallus"
-- 
gentoo-dev@gentoo.org mailing list

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

[Stuart Herbert]

On 11/29/06, Andrew Gaffney <agaffney@gentoo.org> wrote:
> The 3-4 weeks of releng filing a ton of "doesn't build with gcc-4.1.1" bugs
> wasn't a big enough clue? :)

No.  We get those all the time; there's always someone trying out an
unsupported release of gcc.

> Also, the arch teams (or at least the arch's
> release coordinator...if they didn't tell the rest of their team, that's not
> releng's fault) that were moving to it and people in base-system working on it
> were "in the know".

What about everyone else, who isn't part of an arch team?  Sorry, but
I just don't get how you expected us to know it was coming, when you
didn't announce it, and you don't even feel that an announcement was
your (releng's) responsibility (even though stabilisation of gcc-4.1
was for you).

You personally went out of your way earlier this year to critisise me
about bad communication, just for announcing that work had started on
something in Gentoo.  And yet here you are today, somehow expecting
the rest of us to rely on clairvoyance to know in advance about a
change that your team pushed onto the entire tree.

It's a great illustration why the releng snapshots, as things stand
today, aren't the right way to deliver a meaningfully stable tree to
our users.  It's simply difficult to trust you with the way you choose
to behave today.

> Yes, that's part of wolf31o2's idea. The tree would be "non-moving" except for
> GLSA's and any dependencies required by the updated version of the
> security-affected package.

How are you going to ensure that all the security fixes that never get
a GLSA get into the tree?

> A slower-moving (or "non-moving" with security updates) tree is perfect for me,
> and I'm sure for many other people as well.

Before you release these trees to users, I trust you'll be doing the
responsible thing, and ensuring that upgrades from one tree to the
next work?  You can't take that for granted; package maintainers
cannot be relied upon to test upgrades spanning that length of time.
(Which is why upgrade early, upgrade often is a practical way to
manage Gentoo boxes)

Best regards,
Stu
--
-- 
gentoo-dev@gentoo.org mailing list

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

[Andrew Gaffney]

Stuart Herbert wrote:
> On 11/29/06, Andrew Gaffney <agaffney@gentoo.org> wrote:
>> The 3-4 weeks of releng filing a ton of "doesn't build with gcc-4.1.1" 
>> bugs
>> wasn't a big enough clue? :)
> 
> No.  We get those all the time; there's always someone trying out an
> unsupported release of gcc.

 From other developers, most of which were releng members?

>> Also, the arch teams (or at least the arch's
>> release coordinator...if they didn't tell the rest of their team, 
>> that's not
>> releng's fault) that were moving to it and people in base-system 
>> working on it
>> were "in the know".
> 
> What about everyone else, who isn't part of an arch team?  Sorry, but
> I just don't get how you expected us to know it was coming, when you
> didn't announce it, and you don't even feel that an announcement was
> your (releng's) responsibility (even though stabilisation of gcc-4.1
> was for you).

It's stupid to "blame" releng for the stabilization of gcc-4.1.1. It would have 
been stabilized soon as part of the normal process of package maintenance 
whether releng wanted it or not. And really, it was up to each arch to say they 
wanted it for the release, not releng. We didn't force it on people.

And as always, if you wanted to know what was going on as part of the release, 
the info was there for everyone to see in the usual places (such as the 
gentoo-releng mailing list or the #gentoo-releng IRC channel). This argument 
about people not knowing what releng is doing seems to come up after every 
release. It's crap.

>> Yes, that's part of wolf31o2's idea. The tree would be "non-moving" 
>> except for
>> GLSA's and any dependencies required by the updated version of the
>> security-affected package.
> 
> How are you going to ensure that all the security fixes that never get
> a GLSA get into the tree?

If it doesn't get a GLSA, it doesn't get in the release tree. This may mean that 
we need to modify the GLSA process a bit so that ~arch packages found to be 
vulnerable get GLSAs as well. Although, release tree users won't have these 
~arch versions anyway, so I don't see it being *that* big of an issue.

>> A slower-moving (or "non-moving" with security updates) tree is 
>> perfect for me,
>> and I'm sure for many other people as well.
> 
> Before you release these trees to users, I trust you'll be doing the
> responsible thing, and ensuring that upgrades from one tree to the
> next work?  You can't take that for granted; package maintainers
> cannot be relied upon to test upgrades spanning that length of time.
> (Which is why upgrade early, upgrade often is a practical way to
> manage Gentoo boxes)

Absolutely, it would be stupid to release it to users without testing that the 
upgrade path is even feasible. However, we can't test the upgrade with *all* 
packages in the tree, but we can certainly do it with certain "profiles" (gnome 
desktop, kde desktop, LAMP server, etc.) to try to cover as many bases as 
possible. This testing can be easily scripted.

-- 
Andrew Gaffney                            http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer                                   Installer Project
Today's lesson in political correctness:      "Go asphyxiate on a phallus"
-- 
gentoo-dev@gentoo.org mailing list

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

[Bo Ørsted Andresen]

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

On Wednesday 29 November 2006 09:37, Stuart Herbert wrote:
> > Gcc 4.1.1 wasn't a last minute change.
>
> I can't agree with you there.  It doesn't matter how many months of
> planning and work you guys put into getting gcc-4.1 fit for stable.
> If you're doing it off in your own little corner of the world, and
> then springing it on the rest of us just days before the release
> happens, then to the much larger dev community, it comes as a last
> minute change.

It was announced two months before 2006.1 was released.

http://thread.gmane.org/gmane.linux.gentoo.devel/39848

-- 
Bo Andresen

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

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

[Chris Gianelloni]

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

On Wed, 2006-11-29 at 06:37 +0000, Steve Long wrote:
> <snip> .. The one
> > disadvantage to my design is it needs infra.  It needs it's own
> > repository and rsync.
> > 
> What does that entail? Would a co-located server suffice?

Sure.  It would be much better to simply use what we currently have,
though.  Honestly, I was pursuing this with Infra a few months back, and
have since dropped it, due to time constraints.  I plan on picking it
back up, as I said, so I don't know what is necessary at this point.

> > Now, the release trees are non-moving.  The 2007.0-release tree is
> > *always* the 2007.0-release tree for as long as we decide to support it.
> > Likely, this support period would begin as a single release and get
> > extended as volunteers came around to support it.  New releases get
> > their own tree.
> > 
> Well count me in as a volunteer to help set this up and maintain an x86
> release. I'm a pretty good coder if that helps.

There wouldn't be an "x86 release" or anything.  It would be the whole
thing.  All or nothing.

> > Users who want to use the current portage tree get what they want.
> > Users who want a more stable tree get what they want.  Basically,
> > everyone (hopefully) is happy, or at least as happy as we can feasibly
> > make them.
> > 
> This all sounds great. Respect for the work you've already put in.

Well, Andrew Gaffney really helped out, as he's been doing the python
work to utilize portage to get the proper information to strip the tree.
Since these scripts were originally written and subsequently abandoned,
they've needed a little work.  Andrew and I are working on this now to
try to get everything back to working order.

> From your post we need to add:
> > - strip all USE flags that aren't used from use.mask (per-profile)
> > - strip all packages that aren't available from package.mask
> > (per-profile)
> 
> What language is the script implemented in?

There are several scripts.  They are written in either python or bash.

> Wrt security updates, is it possible to tie into GLSAs so that we could
> automate updating packages that need it? By updating I mean adding the
> ebuilds and any dependencies (or dependants that might require updating.)

What were you expecting that we would do?

> Would that help in terms of having say, up to date GUI packages, or is it
> just easier to use overlays?

I have no desire to support any packages that weren't in the original
tree.  If you want something we aren't providing, use an overlay.

> Chris Gianelloni wrote:
> 
> > No version changes on any packages, except those which are necessary due
> > to a security violation, or a vulnerable package's dependencies.
> > 
> I could imagine a situation where a dependant package (ie one using the
> package updated) would also require an update. It'd be rare though, so I
> guess it wouldn't need automating.

"or a vulnerable package's dependencies"

> > Something that would be useful would be for package maintainers that
> > wish to participate to perform further testing and validation on
> > packages in the release snapshot prior to its final freeze.  This would
> > give us even more eyes on the tree and hopefully provide a much higher
> > quality snapshot once we're done.
> 
> It sounds like it'd also make the releases in general have better QA. What
> do package/ herd maintainers think?

Absolutely.

One thing that I am working on doing with agaffney is building more and
more automated systems for doing testing.  We have our Release
Engineering build box doing weekly builds of all of the stages from
scratch for i686.  I plan on doing the same for i586/no-nptl, to cover
that facet, as well as amd64.  Currently, I am testing against the
dev/2007.0 profile, but plan on testing against dev/2007.0/desktop and
dev/2007.0/server in addition to the dev/2007.0 profile.

I will also be adding a test suite on my Alpha and PPC machines at home.
Aside from this, I will be running catalyst tinderbox builds on at least
x86/amd64 for many packages that aren't included in the LiveCD/LiveDVD
sets.  At some point, I'll likely be asking for suggestions on packages
to add to this testing.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

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

[Chris Gianelloni]

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

On Wed, 2006-11-29 at 02:21 -0500, Alec Warner wrote:
> The bonus is that we then need to have a fetcher that runs over the main 
> tree and all supported release trees, and this of course increases 
> mirror size as we now have distfiles in the tree from a year ago to 
> support a year old release.  I am unsure how much space this would take 
> up; but this is an obstacle that must be overcome (somehow), preferably 
> by giving infra an estimate on the space reqs.

Well, we have to provide distfiles for everything we've ever released a
binary of, forever, to comply with the GPL.

As of this release, I kept a copy of all of the distfiles for the entire
release, and can make a DVD of it, on request.  This fulfills our
requirements with the GPL.

I would bet that for most of the tree, the size increase would be
negligible, since quite a bit of the tree doesn't change every six
months.  Of course, the stuff that does change tends to be the larger
things, like desktop environments and such.  I wouldn't have a clue how
to give you an idea of the space requirements until the next release
comes about and I also have distfiles for that release.  That will give
you an idea, based only on what we release, though.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

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

[Stuart Herbert]

On 11/29/06, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> As of this release, I kept a copy of all of the distfiles for the entire
> release, and can make a DVD of it, on request.  This fulfills our
> requirements with the GPL.

What are the arrangements should you go under a bus on the way home
from work tonight?

Best regards,
Stu
--
-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Wed, 2006-11-29 at 08:37 +0000, Stuart Herbert wrote:
> On 11/28/06, Andrew Gaffney <agaffney@gentoo.org> wrote:
> > You make it sound like releng doesn't care at all about non-desktop packages.
> 
> That wasn't how it was meant.  Was simply meant as a statement of
> fact.  Releng activities are currently exclusively desktop-oriented.

I'm sorry, but how the hell do you know?  You are not a member of
Release Engineering, and have *NO CLUE* what we do over there.  What we
release isn't the only thing we do.

> Until that changes, releng snapshots aren't fit for the purpose of
> being a non-moving tree, as far as servers are concerned.

Luckily, I'm not asking you.  Instead, I'm asking interested developers
to assist us in making what we plan on doing much more viable.  Feel
free to sit over there and naysay until you're blue in the face.  We'll
be over here getting something accomplished via teamwork.

> > > b) Release trees have a nasty habit of picking up last minute changes
> > > (such as gcc 4.1) to suit the release, not stability.
> >
> > Gcc 4.1.1 wasn't a last minute change.
> 
> I can't agree with you there.  It doesn't matter how many months of
> planning and work you guys put into getting gcc-4.1 fit for stable.
> If you're doing it off in your own little corner of the world, and
> then springing it on the rest of us just days before the release
> happens, then to the much larger dev community, it comes as a last
> minute change.

Except it was announced before we even made the snapshot, and we worked
with the toolchain guys to get it to happen and entirely with their
blessing.  Just because we didn't take the time out to stop and make
sure you were personally comfortable with the change doesn't mean we
didn't prepare for it and announce it.

> If you're "testing the crap" out of something, but only in an
> exclusively desktop-oriented way ... well, that can only really be
> partial testing, can't it?

Again, you don't know what you're talking about, so I'd really
appreciate it if you just shut the hell up until you decide to get
yourself informed on the facts.

> There'll always be GLSA's to respond to.  That's another issue that
> needs to be handled w/ a slow-moving tree.  Are you going to restrict
> changes in the slow-moving tree only to changes against a GLSA?

That's what we've said.

> I honestly don't think you're ever going to get that out of Gentoo,
> because of the lack of backporting.  Can you live with a slower-moving
> tree?  Or do you personally really need a non-moving tree?
> 
> If you really need a non-moving tree, I think you're better off with
> RHES or Ubuntu.

While I truly appreciate your ability to give your opinion, I don't
care.  As I said, I am working on this concept as an experiment.  It is
being done by Release Engineering.  We aren't really *asking* anyone for
their opinion.  We're simply stating what we plan on working on and will
be asking people who *want* to participate to do so.  Anyone not
interested in participating in this Release Engineering-driven project
is welcome to completely ignore us, as we will them.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

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

[Chris Gianelloni]

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

On Wed, 2006-11-29 at 16:01 +0000, Stuart Herbert wrote:
> On 11/29/06, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> > As of this release, I kept a copy of all of the distfiles for the entire
> > release, and can make a DVD of it, on request.  This fulfills our
> > requirements with the GPL.
> 
> What are the arrangements should you go under a bus on the way home
> from work tonight?

You'd like that, wouldn't you?

Well, since you asked, the distfiles are stored on Release Engineering's
server, under /release/2006.1/distfiles, which is accessible to anyone
in Release Engineering, as well as the OSL and Infra.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

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

[Andrew Gaffney]

Stuart Herbert wrote:
> On 11/29/06, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
>> As of this release, I kept a copy of all of the distfiles for the entire
>> release, and can make a DVD of it, on request.  This fulfills our
>> requirements with the GPL.
> 
> What are the arrangements should you go under a bus on the way home
> from work tonight?

I believe they're kept on poseidon, which many people have access to. Please 
stop arguing just for the sake of arguing. Are you trying to become the next 
ciaranm (no offense to ciaranm :P)?

-- 
Andrew Gaffney                            http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer                                   Installer Project
Today's lesson in political correctness:      "Go asphyxiate on a phallus"
-- 
gentoo-dev@gentoo.org mailing list

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

[Stuart Herbert]

On 11/29/06, Andrew Gaffney <agaffney@gentoo.org> wrote:
>  From other developers, most of which were releng members?

I get most of mine from users, who are normally kind enough to submit
the required patches at the same time.

> It's stupid to "blame" releng for the stabilization of gcc-4.1.1.   We didn't force
> it on people.

You're responsible for it being stabilised when it was.  It's
disappointing that you choose to disavow all responsibility for that
happening.

I'm not arguing that gcc-4.1 shouldn't have been stabilised at some
point in time (although the performance penalty it introduces is a
shame).  I'm just pointing out a flaw with the idea that the releng
snapshots are fit for the purpose of being a non-moving tree for our
users.

> And as always, if you wanted to know what was going on as part of the release,
> the info was there for everyone to see in the usual places (such as the
> gentoo-releng mailing list or the #gentoo-releng IRC channel). This argument
> about people not knowing what releng is doing seems to come up after every
> release. It's crap.

I don't agree with you, sorry.

Releng members in the past have complained about not knowing what is
going on elsewhere in Gentoo; they have _specifically_ complained
because information was not _actively_ sent in their direction.  But,
when the point is raised in the opposite direction, your answer is
"it's crap".

I'm left very disappointed by that.

> If it doesn't get a GLSA, it doesn't get in the release tree. This may mean that
> we need to modify the GLSA process a bit so that ~arch packages found to be
> vulnerable get GLSAs as well. Although, release tree users won't have these
> ~arch versions anyway, so I don't see it being *that* big of an issue.

It would be worth checking to make sure that all security bugs for all
stable packages get GLSAs first.  I don't know whether they do or they
don't.

> Absolutely, it would be stupid to release it to users without testing that the
> upgrade path is even feasible. However, we can't test the upgrade with *all*
> packages in the tree, but we can certainly do it with certain "profiles" (gnome
> desktop, kde desktop, LAMP server, etc.) to try to cover as many bases as
> possible. This testing can be easily scripted.

Cool.

Best regards,
Stu
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Wed, 29 Nov 2006 16:01:11 +0000 "Stuart Herbert"
<stuart.herbert@gmail.com> wrote:
| On 11/29/06, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
| > As of this release, I kept a copy of all of the distfiles for the
| > entire release, and can make a DVD of it, on request.  This
| > fulfills our requirements with the GPL.
| 
| What are the arrangements should you go under a bus on the way home
| from work tonight?

George and Reuben get a visit from the local police department.

-- 
Ciaran McCreesh
Mail                : ciaranm at ciaranm.org
Web                 : http://ciaranm.org/
as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13


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

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

[Stuart Herbert]

On 11/29/06, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> > What are the arrangements should you go under a bus on the way home
> > from work tonight?
>
> You'd like that, wouldn't you?

That was _completely_ uncalled for.

"go under a bus" is just a phrase that's commonly used here in the UK
(because our major public transport infrastructure consists of buses
and trains) when talking about business continuity of key personnel.

Our liabilities under the GPL are ultimately the Foundation's
responsibility.  It's perfectly reasonable to want to know understand
how we'd meet that liability if something did happen to you.

> Well, since you asked, the distfiles are stored on Release Engineering's
> server, under /release/2006.1/distfiles, which is accessible to anyone
> in Release Engineering, as well as the OSL and Infra.

Thank you.  Do we have backups in place covering these files?  Have we
tested the backups to confirm that they actually work?

Best regards,
Stu
--
-- 
gentoo-dev@gentoo.org mailing list

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

[Mike Doty]

Stuart Herbert wrote:
[snip]

> Thank you.  Do we have backups in place covering these files?  Have we
> tested the backups to confirm that they actually work?
I have a couple of locations where I could store backups, depending on 
size and projected growth.  I suppose it'll have to wait until 2007.0 
though so we can actually gage it as opposed to speculating wildly.

--Mike

-- 
gentoo-dev@gentoo.org mailing list

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

[Josh Saddler]

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

Chris Gianelloni wrote:
> While I truly appreciate your ability to give your opinion, I don't
> care.  As I said, I am working on this concept as an experiment.  It is
> being done by Release Engineering.  We aren't really *asking* anyone for
> their opinion.  We're simply stating what we plan on working on and will
> be asking people who *want* to participate to do so.  Anyone not
> interested in participating in this Release Engineering-driven project
> is welcome to completely ignore us, as we will them.
> 

Now that I think about it, regardless of the technical merits of moving
trees etc., Chris's statement here is more or less like the one issued
by Stuart in the creation of the Seeds project.

@Stuart:
That's something to keep in mind. It looks like for the time being this
will be an "in-house" project by releng, so if they want to spend the
manpower, resources, and time to work on it, why not let 'em? After all,
such reasoning went into the Seeds project, didn't it?


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

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

[Stuart Herbert]

On 11/29/06, Mike Doty <kingtaco@gentoo.org> wrote:
> Stuart Herbert wrote:
> I have a couple of locations where I could store backups, depending on
> size and projected growth.  I suppose it'll have to wait until 2007.0
> though so we can actually gage it as opposed to speculating wildly.

If anything happens to poseiden ... does anyone have a backup anywhere
that we can use to rebuild the distfiles archive for 2006.1?

What's the situation with older releases?  Do we have the distfile
archives for those on poseiden too?  Would that give you the sizing
data you need to put backups in place?

Best regards,
Stu
-- 
gentoo-dev@gentoo.org mailing list

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

[Mike Doty]

Stuart Herbert wrote:
> On 11/29/06, Mike Doty <kingtaco@gentoo.org> wrote:
>> Stuart Herbert wrote:
>> I have a couple of locations where I could store backups, depending on
>> size and projected growth.  I suppose it'll have to wait until 2007.0
>> though so we can actually gage it as opposed to speculating wildly.
> 
> If anything happens to poseiden ... does anyone have a backup anywhere
> that we can use to rebuild the distfiles archive for 2006.1?
> 
> What's the situation with older releases?  Do we have the distfile
> archives for those on poseiden too?  Would that give you the sizing
> data you need to put backups in place?
Chris had mentioned earlier that we started with 2006.1(iirc the 
discussion about GPL requirements came up between .0 and .1)  having 2+ 
snapshots allows me to determine which server is best to use.

--Mike
-- 
gentoo-dev@gentoo.org mailing list

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

[Stuart Herbert]

On 11/29/06, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> I'm sorry, but how the hell do you know?  You are not a member of
> Release Engineering, and have *NO CLUE* what we do over there.  What we
> release isn't the only thing we do.

Then this is a great opportunity to set the record straight, by
explaining what server-oriented work releng do with each release.

> Luckily, I'm not asking you.  Instead, I'm asking interested developers
> to assist us in making what we plan on doing much more viable.  Feel
> free to sit over there and naysay until you're blue in the face.  We'll
> be over here getting something accomplished via teamwork.

Odd; I'm trying to get involved, by providing feedback and asking questions.

> Except it was announced before we even made the snapshot,

Sorry, I've looked, but the only announcement I found on gentoo-dev
was posted two days before gcc-4.1 was stabilised [1].  I must have
missed the earlier announcement?

> Just because we didn't take the time out to stop and make
> sure you were personally comfortable with the change doesn't mean we
> didn't prepare for it and announce it.

I'm sorry that you've gone with the "I always know best, you're a
fucking chump so shut the fuck up" type of response :(  That seems to
be your answer of choice to all feedback these days.

I'm sorry you feel that my input isn't welcome in your world.

[1] http://marc.theaimsgroup.com/?l=gentoo-dev&m=115672836418923&w=2

Best regards,
Stu
-- 
gentoo-dev@gentoo.org mailing list

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

[Andrew Gaffney]

Stuart Herbert wrote:
> Sorry, I've looked, but the only announcement I found on gentoo-dev
> was posted two days before gcc-4.1 was stabilised [1].  I must have
> missed the earlier announcement?

Do you just ignore the rest of the thread when responding to individual emails? 
About 2 hours ago, someone posted the following link in this thread in response 
to your earlier post about gcc-4.1.1 being a last minute change.

http://thread.gmane.org/gmane.linux.gentoo.devel/39848

-- 
Andrew Gaffney                            http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer                                   Installer Project
Today's lesson in political correctness:      "Go asphyxiate on a phallus"
-- 
gentoo-dev@gentoo.org mailing list

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

[Bo Ørsted Andresen]

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

On Wednesday 29 November 2006 18:11, Stuart Herbert wrote:
> > Except it was announced before we even made the snapshot,
>
> Sorry, I've looked, but the only announcement I found on gentoo-dev
> was posted two days before gcc-4.1 was stabilised [1].  I must have
> missed the earlier announcement?

Maybe you should read the replies you got the first time you made this claim 
on this list [1]. I've stated my opinion on the matter once at the 
gentoo-user mailing list [2] so I'll refrain from doing so here. Also just 
for completeness I repeat the link to the original announce [3] two months 
prior to the release.

[1] http://thread.gmane.org/gmane.linux.gentoo.devel/41923/focus=41944
[2] http://thread.gmane.org/gmane.linux.gentoo.user/169041/focus=169455
[3] http://thread.gmane.org/gmane.linux.gentoo.devel/39848

-- 
Bo Andresen

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

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

[Alec Warner]

Stuart Herbert wrote:
> 
>> Just because we didn't take the time out to stop and make
>> sure you were personally comfortable with the change doesn't mean we
>> didn't prepare for it and announce it.
> 
> I'm sorry that you've gone with the "I always know best, you're a
> fucking chump so shut the fuck up" type of response :(  That seems to
> be your answer of choice to all feedback these days.
> 

Please keep the name-calling off-list.  While it is nice to have input 
on a particular project and we should strive to work together, remember 
that this is a project headed up by Chris and Release Engineering.  As 
such they have the right to ignore all other input if they so choose.

If their goals don't coincide with yours then that is a shame, but don't 
push it too far please.
-- 
gentoo-dev@gentoo.org mailing list

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

[Stuart Herbert]

Hi,

On 11/29/06, Bo Ørsted Andresen <bo.andresen@zlin.dk> wrote:
> Maybe you should read the replies you got the first time you made this claim
> on this list [1].

Many thanks for these links.  I didn't see your original email.

Best regards,
Stu

-- 
gentoo-dev@gentoo.org mailing list

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

[Richard Fish]

On 11/29/06, Stuart Herbert <stuart.herbert@gmail.com> wrote:
> Hi,
>
> On 11/29/06, Bo Ørsted Andresen <bo.andresen@zlin.dk> wrote:
> > Maybe you should read the replies you got the first time you made this claim
> > on this list [1].
>
> Many thanks for these links.  I didn't see your original email.

Wanna add a comment here: :-)

http://bugs.gentoo.org/show_bug.cgi?id=141904

-Richard

-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Wed, 29 Nov 2006 13:01:37 -0700 "Richard Fish"
<bigfish@asmallpond.org> wrote:
| On 11/29/06, Stuart Herbert <stuart.herbert@gmail.com> wrote:
| > On 11/29/06, Bo Ørsted Andresen <bo.andresen@zlin.dk> wrote:
| > > Maybe you should read the replies you got the first time you made
| > > this claim on this list [1].
| >
| > Many thanks for these links.  I didn't see your original email.
| 
| Wanna add a comment here: :-)
| 
| http://bugs.gentoo.org/show_bug.cgi?id=141904

By "didn't see", he means he was so busy participating in his favourite
game of Chris bashing that he didn't get around to reading any of the
relevant material first...

-- 
Ciaran McCreesh
Mail                : ciaranm at ciaranm.org
Web                 : http://ciaranm.org/
as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13


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

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

[Seemant Kulleen]

On Wed, 2006-11-29 at 20:10 +0000, Ciaran McCreesh wrote:

> By "didn't see", he means he was so busy participating in his favourite
> game of Chris bashing that he didn't get around to reading any of the
> relevant material first...


Could be, or (as happened here) mails arrived at different times. I saw
responses before the parent message in a few sub-threads, today.  Enough
with the bashing (there's an irony to your own stuart bashing above),
already.

-- 
Seemant Kulleen
Developer, Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

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

[George Prowse]

Ciaran McCreesh wrote:
> On Wed, 29 Nov 2006 16:01:11 +0000 "Stuart Herbert"
> <stuart.herbert@gmail.com> wrote:
> | On 11/29/06, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> | > As of this release, I kept a copy of all of the distfiles for the
> | > entire release, and can make a DVD of it, on request.  This
> | > fulfills our requirements with the GPL.
> | 
> | What are the arrangements should you go under a bus on the way home
> | from work tonight?
> 
> George and Reuben get a visit from the local police department.
> 
Hahahahaha.

How would they narrow it down to us though ;)
-- 
gentoo-dev@gentoo.org mailing list

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

[Steve Long]

Chris Gianelloni wrote:

> It would be much better to simply use what we currently have,
> though.  Honestly, I was pursuing this with Infra a few months back, and
> have since dropped it, due to time constraints.  I plan on picking it
> back up, as I said, so I don't know what is necessary at this point.
> 
Makes sense. 

>> > Now, the release trees are non-moving.  The 2007.0-release tree is
>> > *always* the 2007.0-release tree for as long as we decide to support
>> > it. Likely, this support period would begin as a single release and get
>> > extended as volunteers came around to support it.  New releases get
>> > their own tree.
>> > 
>> Well count me in as a volunteer to help set this up and maintain an x86
>> release. I'm a pretty good coder if that helps.
> 
> There wouldn't be an "x86 release" or anything.  It would be the whole
> thing.  All or nothing.
> 
I hear you- it's the tree that's being released. I guess x86 is the most
common architecture anyway, so testers for it aren't gonna be hard to find.

>> > Users who want to use the current portage tree get what they want.
>> > Users who want a more stable tree get what they want.  Basically,
>> > everyone (hopefully) is happy, or at least as happy as we can feasibly
>> > make them.
>> > 
>> This all sounds great. Respect for the work you've already put in.
> 
> Well, Andrew Gaffney really helped out, as he's been doing the python
> work to utilize portage to get the proper information to strip the tree.
> Since these scripts were originally written and subsequently abandoned,
> they've needed a little work.  Andrew and I are working on this now to
> try to get everything back to working order.
> 
Well can I take the opportunity to thank you both then? It's clearly
something with interest, as you mentioned.

>> From your post we need to add:
>> > - strip all USE flags that aren't used from use.mask (per-profile)
>> > - strip all packages that aren't available from package.mask
>> > (per-profile)
>> 
>> What language is the script implemented in?
> 
[Andrew Gaffney wrote:]
> The current script is actually 2 scripts: a python script that I wrote
> that interfaces with the portage API and a bash script that wolf31o2 wrote
> that takes the output from my script and does the cleanup.
> 
> Last night, with the help of ferringb, I started working on a replacement
> script that uses the pkgcore API. The portage-based script takes quite a
> while to run, and gets it wrong if there are any p.mask'd stable packages
> on any arch or other weird things. The pkgcore-based script actually uses
> the profiles properly and runs over the entire tree with all the "stable"
> profiles (according to profiles.desc) in 1m1.869s (on my box). I'll
> probably end up combining the scripts and doing the cleanup in python to
> make things easier.
Excellent; pkgcore really sounds great- is there any possibility that it'll
become the new portage?

>> Wrt security updates, is it possible to tie into GLSAs so that we could
>> automate updating packages that need it? By updating I mean adding the
>> ebuilds and any dependencies (or dependants that might require updating.)
> 
> What were you expecting that we would do?
> 
Lol; exactly that. I guess I was asking how difficult it is to automate the
process.

Although Andrew wrote that he didn't think it was necessarily the best idea.
Why is that?

>> > No version changes on any packages, except those which are necessary
>> > due to a security violation, or a vulnerable package's dependencies.
>> > 
>> I could imagine a situation where a dependant package (ie one using the
>> package updated) would also require an update. It'd be rare though, so I
>> guess it wouldn't need automating.
> 
> "or a vulnerable package's dependencies"
> 
Sure, if the update meant the dependencies needed updating too. Again,
that'd need automating, so we're talking about checking the tree in both
directions (dependencies and dependants in my terms, sorry if I'm using the
words wrongly.)

> One thing that I am working on doing with agaffney is building more and
> more automated systems for doing testing.  We have our Release
> Engineering build box doing weekly builds of all of the stages from
> scratch for i686.  I plan on doing the same for i586/no-nptl, to cover
> that facet, as well as amd64.  Currently, I am testing against the
> dev/2007.0 profile, but plan on testing against dev/2007.0/desktop and
> dev/2007.0/server in addition to the dev/2007.0 profile.
> 
> I will also be adding a test suite on my Alpha and PPC machines at home.
> Aside from this, I will be running catalyst tinderbox builds on at least
> x86/amd64 for many packages that aren't included in the LiveCD/LiveDVD
> sets.  At some point, I'll likely be asking for suggestions on packages
> to add to this testing.
> 
This all sounds wicked. The more automation the better.

-- 
gentoo-dev@gentoo.org mailing list

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

[Steve Long]

>> There'll always be GLSA's to respond to.  That's another issue that
>> needs to be handled w/ a slow-moving tree.  Are you going to restrict
>> changes in the slow-moving tree only to changes against a GLSA?
> 
> That's what we've said.
> 
I don't have a problem with this at all. The slow-moving tree isn't; it's a
release tree. The only question I have, which Stuart also mentioned, is
whether all security updates go thru the GLSA process.


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Can we have some manners, please?

[Steve Long]

Just a general point: I think people are being a bit harsh on Stuart in this
thread. I'm picking up on Chris's post as I'm interested in the
releng-related stuff, but this isn't exclusively about his responses.

Stuart Herbert wrote:
> On 11/29/06, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
>> I'm sorry, but how the hell do you know?  You are not a member of
>> Release Engineering, and have *NO CLUE* what we do over there.  What we
>> release isn't the only thing we do.
> 
> Then this is a great opportunity to set the record straight, by
> explaining what server-oriented work releng do with each release.
> 
I agree with Stuart on this. While released stuff is of course not all any
team does in software development, it is all that anyone external usually
sees, or associates with that group.

>> Luckily, I'm not asking you.  Instead, I'm asking interested developers
>> to assist us in making what we plan on doing much more viable.  Feel
>> free to sit over there and naysay until you're blue in the face.  We'll
>> be over here getting something accomplished via teamwork.
> 
> Odd; I'm trying to get involved, by providing feedback and asking
> questions.
> 
Again I think Stuart is right; he's asking questions which while they might
sound irritating if you've explained the stuff before, should be treated
with respect, or at least basic courtesy.

>> Just because we didn't take the time out to stop and make
>> sure you were personally comfortable with the change doesn't mean we
>> didn't prepare for it and announce it.
> 
> I'm sorry that you've gone with the "I always know best, you're a
> fucking chump so shut the fuck up" type of response :(  That seems to
> be your answer of choice to all feedback these days.
> 
It's obviously something to do with you personally Stuart, and no I'm not
trying to insult you by that. I think you'd have been better quoting this
bit:
>> If you're "testing the crap" out of something, but only in an
>> exclusively desktop-oriented way ... well, that can only really be
>> partial testing, can't it?
> 
> Again, you don't know what you're talking about, so I'd really
> appreciate it if you just shut the hell up until you decide to get
> yourself informed on the facts.
> 
AFAIC that response is unacceptable, and should have been called, rather
than Stuart's understandable upset at being dealt with in such a manner.

> I'm sorry you feel that my input isn't welcome in your world.
And that is exactly why we don't need such responses; it just switches
people off, who are genuinely (and politely) trying to contribute.

Wrt others not understanding, it's much simpler to write a one-liner
explaining where they're going wrong, rather than slagging them off, which
only has negative consequences.

Disclaimer: I don't know all the background in terms of prior discussion
which may have led people to deal with Stuart so nastily. TBH I don't think
it really matters; from the outside it looks like bashing someone who seems
to be asking reasonable questions and making valid points, at least within
the context of the discussion. There have been comparisons with ciaranm,
but again, I've seen tirades against him when he had seemed (to me) to be
asking reasonable questions.

In summary, I'd just like to say that if you think someone's missing a basic
point, can you please either put him/her straight or just ignore them. The
bad manners can only put others off.

A wider point is that the record may be set straight, as Stuart puts it, by
responding with info rather than an insult, but that's only for that *one*
discussion. I guess I'm wondering whether documentation people read this
stuff, and if so, couldn't any points that get made be fed back into docs?
So in this case, as an example, if more info came from releng with regard
to what they do in terms of server stuff that _wasn't_ already in the docs,
the docs would be updated. And of course, if it /were/ in the docs, a
simple link could take the place of an insult.

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Versioning the tree

[Duncan]

Steve Long <slong@rathaus.eclipse.co.uk> posted
ekol7b$q8i$1@sea.gmane.org, excerpted below, on  Fri, 01 Dec 2006 07:23:09
+0000:

> Excellent; pkgcore really sounds great- is there any possibility that it'll
> become the new portage?

Possibility, yes.  It's not certain, as there are multiple contenders
(paludis is the other), and it will be some time, in any case.

The current problem is that there's no standard definition for what
constitutes an acceptable ebuild, beyond the basic gentoo dev guidelines.
The de facto definition is whatever works with versions of portage
currently in the tree (or just barely removed), but that presents many
difficulties, including both slow upgrades since backward compatibility
must be maintained for longer even when the former functionality is
considered b0rken, and questions of what's broken, the package manager or
the ebuild, when something fails to work as expected.

Thus, all three package managers, the current portage solution, and paludis
and pkgcore as well, are currently under slower development than they might
otherwise be, while interested parties attempt to hash out a working
standard definition of what actually constitutes a proper ebuild, and
what helper functions said ebuild can in fact depend upon the package
manager to make available.  Once that's decided and approved, the playing
field upon which the merits of the next generation package managers can be
judged will be much fairer for all.  Of course, with that defined, portage
itself will be freer to progress at speed as well, and it may be that it
will remain the default "approved" solution for quite some time.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Fri, 2006-12-01 at 07:23 +0000, Steve Long wrote:
> >> Well count me in as a volunteer to help set this up and maintain an x86
> >> release. I'm a pretty good coder if that helps.
> > 
> > There wouldn't be an "x86 release" or anything.  It would be the whole
> > thing.  All or nothing.
> > 
> I hear you- it's the tree that's being released. I guess x86 is the most
> common architecture anyway, so testers for it aren't gonna be hard to find.

Actually, it depends on what you're testing.  For x86, there's much more
hardware to test, so there's always some problem which couldn't be
tested for before-hand.  When it comes to software, it's usually easier
to test for, so it depends on the package quite a bit.

Now, we can definitely use help in testing the snapshot.  We're going to
be announcing a new round of "Release Testers" for 2007.0 once we get
ramped up into the release cycle.  I am going to be working with the
rest of the Release Engineering team to try to come up with some testing
methodologies for people to use when testing, as well as a standard
report for successes and failures.

> >> Wrt security updates, is it possible to tie into GLSAs so that we could
> >> automate updating packages that need it? By updating I mean adding the
> >> ebuilds and any dependencies (or dependants that might require updating.)
> > 
> > What were you expecting that we would do?
> > 
> Lol; exactly that. I guess I was asking how difficult it is to automate the
> process.
> 
> Although Andrew wrote that he didn't think it was necessarily the best idea.
> Why is that?

Well, these sort of things are hard to automate, for one.  Second, if
we're trying to produce a quality product, we want to have some checks
in place prior to updates hitting the world.  Having a set of human eyes
helps.

> > "or a vulnerable package's dependencies"
> > 
> Sure, if the update meant the dependencies needed updating too. Again,
> that'd need automating, so we're talking about checking the tree in both
> directions (dependencies and dependants in my terms, sorry if I'm using the
> words wrongly.)

Why does it need automating?  We generally don't get more than 10 or so
GLSA a week.  Even doing everything by hand, this would be a very
minimal workload to keep updated.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

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

[Chris Gianelloni]

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

On Fri, 2006-12-01 at 07:22 -0600, Andrew Gaffney wrote:
> Steve Long wrote:
> >>> There'll always be GLSA's to respond to.  That's another issue that
> >>> needs to be handled w/ a slow-moving tree.  Are you going to restrict
> >>> changes in the slow-moving tree only to changes against a GLSA?
> >> That's what we've said.
> >>
> > I don't have a problem with this at all. The slow-moving tree isn't; it's a
> > release tree. The only question I have, which Stuart also mentioned, is
> > whether all security updates go thru the GLSA process.
> 
> Are you asking if all security updates that are done to the release will have 
> gone through the GLSA process? I'd say the answer is yes, since the only updates 
> that will go in the release tree are security updates from GLSAs :P

Actually, we would have to review the process, since not everything that
gets a security bug ends up with a GLSA.  My current loose rule is that
if it deserves a GLSA, then it deserves and update, but I don't know the
exact criteria the security team uses to decide if something warrants a
GLSA or not.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

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

[Andrew Gaffney]

Steve Long wrote:
>>> There'll always be GLSA's to respond to.  That's another issue that
>>> needs to be handled w/ a slow-moving tree.  Are you going to restrict
>>> changes in the slow-moving tree only to changes against a GLSA?
>> That's what we've said.
>>
> I don't have a problem with this at all. The slow-moving tree isn't; it's a
> release tree. The only question I have, which Stuart also mentioned, is
> whether all security updates go thru the GLSA process.

Are you asking if all security updates that are done to the release will have 
gone through the GLSA process? I'd say the answer is yes, since the only updates 
that will go in the release tree are security updates from GLSAs :P

-- 
Andrew Gaffney                            http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer                                   Installer Project
Today's lesson in political correctness:      "Go asphyxiate on a phallus"
-- 
gentoo-dev@gentoo.org mailing list

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

[Steve Long]

Chris Gianelloni wrote:

> On Fri, 2006-12-01 at 07:22 -0600, Andrew Gaffney wrote:
>> Steve Long wrote:
>> > The only question I have, which Stuart also
>> > mentioned, is whether all security updates go thru the GLSA process.
>> 
>> Are you asking if all security updates that are done to the release will
>> have gone through the GLSA process? I'd say the answer is yes, since the
>> only updates that will go in the release tree are security updates from
>> GLSAs :P
> 
> Actually, we would have to review the process, since not everything that
> gets a security bug ends up with a GLSA.  My current loose rule is that
> if it deserves a GLSA, then it deserves and update, but I don't know the
> exact criteria the security team uses to decide if something warrants a
> GLSA or not.
> 
Well, I'm guessing that the bugs are entered and reviewed as security bugs
on some system or another. If so, we can just get the basic list automated
to tie into a script collection.

Who would know what criteria the security people use?


-- 
gentoo-dev@gentoo.org mailing list

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

[Steve Long]

Chris Gianelloni wrote:

> Now, we can definitely use help in testing the snapshot.  We're going to
> be announcing a new round of "Release Testers" for 2007.0 once we get
> ramped up into the release cycle.  I am going to be working with the
> rest of the Release Engineering team to try to come up with some testing
> methodologies for people to use when testing, as well as a standard
> report for successes and failures.
> 
Well I volunteer for one. I'm guessing you can get someone to post to the
forums as and when you're ready to get more volunteers ;)

>> >> Wrt security updates, is it possible to tie into GLSAs so that we
>> >> could automate updating packages that need it? By updating I mean
>> >> adding the ebuilds and any dependencies (or dependants that might
>> >> require updating.)
>> > 
>> > What were you expecting that we would do?
>> > 
>> Lol; exactly that. I guess I was asking how difficult it is to automate
>> the process.
>> 
>> Although Andrew wrote that he didn't think it was necessarily the best
>> idea. Why is that?
> 
> Well, these sort of things are hard to automate, for one.  Second, if
> we're trying to produce a quality product, we want to have some checks
> in place prior to updates hitting the world.  Having a set of human eyes
> helps.
> 
I totally understand the process point in terms of QA. As for automation,
isn't there an existing system used to process security bugs?

>> > "or a vulnerable package's dependencies"
>> > 
>> Sure, if the update meant the dependencies needed updating too. Again,
>> that'd need automating, so we're talking about checking the tree in both
>> directions (dependencies and dependants in my terms, sorry if I'm using
>> the words wrongly.)
> 
> Why does it need automating?  We generally don't get more than 10 or so
> GLSA a week.  Even doing everything by hand, this would be a very
> minimal workload to keep updated.
> 
I didn't know the frequency of GLSAs. According to the other thread, not all
security bugs warrant an advisory. In any event, I don't see why we
shouldn't automate it while we can to save us the tedious workload later.


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Versioning the tree

[Steve Long]

Duncan wrote:

> Steve Long <slong@rathaus.eclipse.co.uk> posted
> ekol7b$q8i$1@sea.gmane.org, excerpted below, on  Fri, 01 Dec 2006 07:23:09
> +0000:
> 
>> Excellent; pkgcore really sounds great- is there any possibility that
>> it'll become the new portage?
> 
> Possibility, yes.  It's not certain, as there are multiple contenders
> (paludis is the other), and it will be some time, in any case.
> 
> The current problem is that there's no standard definition for what
> constitutes an acceptable ebuild, beyond the basic gentoo dev guidelines.
> The de facto definition is whatever works with versions of portage
> currently in the tree (or just barely removed), but that presents many
> difficulties, including both slow upgrades since backward compatibility
> must be maintained for longer even when the former functionality is
> considered b0rken, and questions of what's broken, the package manager or
> the ebuild, when something fails to work as expected.
> 
I'd vote for the defacto with strict backward compatibility, and perhaps a
directive/ alias for newer scripts. If something really doesn't work and
someone cares (bug reporter), ask them to update the ebuild if needed. So
long as good docs are in place (the dev handbook I've seen somewhere is an
example) for the update process, that's acceptable in my book.

> Thus, all three package managers, the current portage solution, and
> paludis and pkgcore as well, are currently under slower development than
> they might otherwise be, while interested parties attempt to hash out a
> working standard definition of what actually constitutes a proper ebuild,
> and what helper functions said ebuild can in fact depend upon the package
> manager to make available.  Once that's decided and approved, the playing
> field upon which the merits of the next generation package managers can be
> judged will be much fairer for all.  Of course, with that defined, portage
> itself will be freer to progress at speed as well, and it may be that it
> will remain the default "approved" solution for quite some time.
> 
As for helper functions, I'd guess a union of all available ;)


-- 
gentoo-dev@gentoo.org mailing list

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

[Sune Kloppenborg Jeppesen]

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

On Friday 01 December 2006 13:47, Chris Gianelloni wrote:
> Actually, we would have to review the process, since not everything that
> gets a security bug ends up with a GLSA.  My current loose rule is that
> if it deserves a GLSA, then it deserves and update, but I don't know the
> exact criteria the security team uses to decide if something warrants a
> GLSA or not.
http://www.gentoo.org/security/en/vulnerability-policy.xml

For relation between severity level and GLSA publication see Dispatch.

Basically everything that ends up with Trivial severity level will NOT get a 
GLSA and everything that ends up with Minor severity level will get a vote 
from the Security team members. Two yes or no votes normally wins. Everything 
else gets a GLSA.

Then you have to add in Security supported architectures, but that's really of 
no concern to x86.

-- 
Sune Kloppenborg Jeppesen
Gentoo Linux Security Team

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