[gentoo-dev] Revisiting GLEP 19

[gentoo-dev] Revisiting GLEP 19

[Kurt Lieber]

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

A while back, I wrote GLEP 19[1] based on some of the needs of the
gentoo-server project.  For various reasons, the GLEP was tabled at the
time and never went anywhere.  A number of folks have expressed an interest
in revitalizing this GLEP, so I'd like to start a new discussion about
implementing it.  There was a couple of previous threads on this GLEP back
when it was first introduced that I'll include[2] for your reference.  

So, with that said, thoughts, comments and other ideas are welcome.

--kurt

[1] http://glep.gentoo.org/glep-0019.html
[2] http://thread.gmane.org/gmane.linux.gentoo.devel/15511
    http://thread.gmane.org/gmane.linux.gentoo.devel/15584 (round 2)

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

Re: [gentoo-dev] Revisiting GLEP 19

[RNuno]

> So, with that said, thoughts, comments and other ideas are welcome.

Nothing here. I just wish that some devs had the time to go forward
with this GLEP. It would be great!

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Dylan Carlson]

On Tuesday 20 July 2004 9:14 am, Kurt Lieber wrote:
> A while back, I wrote GLEP 19[1] based on some of the needs of the
> gentoo-server project.  For various reasons, the GLEP was tabled at the
> time and never went anywhere.  A number of folks have expressed an
> interest in revitalizing this GLEP, so I'd like to start a new
> discussion about implementing it.  There was a couple of previous
> threads on this GLEP back when it was first introduced that I'll
> include[2] for your reference.

My thoughts on this are:

1/ Many Gentoo users want the ability to update packages for fixes only 
(and not just for servers)
2/ Maintaining separate trees in CVS is probably asking too much of our 
current roster, plus requires adding infrastructure and getting everyone 
to mirror the new tree(s)
3/ Users already have a good understanding of what profiles are.  This is 
useful.
4/ Creating separate CVS trees while also using profiles seems superfluous.

Therefore I believe another possible solution is to change the way we use 
profiles (both in practice and in QA policy):

Implications:

1/ archs will need to have a regular, predictable release schedule, 
probably at least every six months.
2/ profiles will list specific package versions whenever possible.  e.g.:
=sys-libs/glibc-2.3.2
3/ we will need to prepare a list of packages which should not change 
unless the user switches profiles.  those packages (e.g., toolchain) in 
the current, and older profiles do not get updated except for fixes.  
4/ we will need to have a policy about how long we'll support a profile, 
and a procedure for end-of-lifing profiles. (probably don't want to 
support a single profile for more than 2 years)
5/ we will need to have documentation for users who are upgrading from one 
profile to another (upgrade warnings, instructions and considerations)
6/ repoman will need to be enhanced to check the profiles before removing 
any ebuilds from the tree that might be needed.  specific versions pinned 
in profiles need to stay until the profile is changed.

Potential problems:

1/ Makes KEYWORDS redundant
2/ Unstable (unreleased) profiles will probably, often run into conflicts 
during commit

I probably missed some things, but it's a start.

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

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Tom Payne]

On Tue, Jul 20, 2004 at 04:43:25PM -0400, Dylan Carlson wrote:
> On Tuesday 20 July 2004 9:14 am, Kurt Lieber wrote:
> > A while back, I wrote GLEP 19[1] based on some of the needs of the
> > gentoo-server project.  For various reasons, the GLEP was tabled at the
> > time and never went anywhere.  A number of folks have expressed an
> > interest in revitalizing this GLEP, so I'd like to start a new
> > discussion about implementing it.  There was a couple of previous
> > threads on this GLEP back when it was first introduced that I'll
> > include[2] for your reference.
> 
> Therefore I believe another possible solution is to change the way we use 
> profiles (both in practice and in QA policy):
> 
> Implications:
> 
> 4/ we will need to have a policy about how long we'll support a profile, 
> and a procedure for end-of-lifing profiles. (probably don't want to 
> support a single profile for more than 2 years)

We will also need to persuade every dev to support this. Often bug fixes are
available from upstream only in a new version of a package, and are mixed in
with a many other improvements. Extracting the bug fix _only_ and
backporting this fix to an old version is at best time consuming, often
difficult, and occasionally impossible.

I think one of the reasons that Gentoo as stable as it is, despite the speed
at which it changes, is that we limit ourselves to supporting _only_ what
the upstream author supports. Doing anything else requires lots of manpower.
Either you employ hundreds of developers like RedHat, or you end up with a
very stable but very slow moving distribution like Debian. I don't want
Gentoo to be either.

Backporting fixes to out-of-date software that I no longer use for the
benefit of people I don't even know exist is distinctly unglamourous and
doesn't scratch any of my Open Source itches. You really need to persuade
developers that "Enterprise (slow-moving) Gentoo" is a good idea before
discussing implementation details.

-- 
Tom

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Kurt Lieber]

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

On Tue, Jul 20, 2004 at 11:03:15PM +0200 or thereabouts, Tom Payne wrote:
> We will also need to persuade every dev to support this. Often bug fixes are
> available from upstream only in a new version of a package, and are mixed in
> with a many other improvements. Extracting the bug fix _only_ and
> backporting this fix to an old version is at best time consuming, often
> difficult, and occasionally impossible.

This was never the intent of the original GLEP.  I don't think backporting
fixes is feasible for many reasons.

> Backporting fixes to out-of-date software that I no longer use for the
> benefit of people I don't even know exist is distinctly unglamourous and
> doesn't scratch any of my Open Source itches. You really need to persuade
> developers that "Enterprise (slow-moving) Gentoo" is a good idea before
> discussing implementation details.

The primary reason for writing and reviving this GLEP is because quite a
few developers, along with a great deal of users, have asked for an
enterprise version of gentoo. 

--kurt

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

Re: [gentoo-dev] Revisiting GLEP 19

[Dylan Carlson]

On Tuesday 20 July 2004 5:03 pm, Tom Payne wrote:
> We will also need to persuade every dev to support this. Often bug fixes
> are available from upstream only in a new version of a package, and are
> mixed in with a many other improvements. Extracting the bug fix _only_
> and backporting this fix to an old version is at best time consuming,
> often difficult, and occasionally impossible.

I never said anything about backporting fixes.  I'd leave that to the 
package maintainer(s) in question as to do what they think is best.  
Obviously there will be exceptions to any rule.  If it makes sense to fix 
current bugs by upgrading to an enhancement release, that's largely up to 
the package maintainer.

The bottom line is to do what's right for the package and the profile in 
question.  I would imagine any circumstance requiring backporting patches 
to be rare.  

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

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Olivier Crete]

Hi,

The main problem with the profiles approach is that need to keep all of
the "old" ebuilds for previous profiles in the tree, unnecessarily
bloating the tree and then we have the risk that package maintainers
will remove the stable packages after a while by mistake..

My favorite solution is the portage snapshot + overlay solution. Where
the gentoo-stable project makes a snapshot (like we already do on every
livecd), it could even be the same snapshot. And then maintain (in a new
tree) an overlay with only security fixes. This tree could then be
rsynced with gensync (or with a modified portage). 


Olivier

On Tue, 2004-07-20 at 16:43 -0400, Dylan Carlson wrote:
> On Tuesday 20 July 2004 9:14 am, Kurt Lieber wrote:
> > A while back, I wrote GLEP 19[1] based on some of the needs of the
> > gentoo-server project.  For various reasons, the GLEP was tabled at the
> > time and never went anywhere.  A number of folks have expressed an
> > interest in revitalizing this GLEP, so I'd like to start a new
> > discussion about implementing it.  There was a couple of previous
> > threads on this GLEP back when it was first introduced that I'll
> > include[2] for your reference.
> 
> My thoughts on this are:
> 
> 1/ Many Gentoo users want the ability to update packages for fixes only 
> (and not just for servers)
> 2/ Maintaining separate trees in CVS is probably asking too much of our 
> current roster, plus requires adding infrastructure and getting everyone 
> to mirror the new tree(s)
> 3/ Users already have a good understanding of what profiles are.  This is 
> useful.
> 4/ Creating separate CVS trees while also using profiles seems superfluous.
> 
> Therefore I believe another possible solution is to change the way we use 
> profiles (both in practice and in QA policy):
> 
> Implications:
> 
> 1/ archs will need to have a regular, predictable release schedule, 
> probably at least every six months.
> 2/ profiles will list specific package versions whenever possible.  e.g.:
> =sys-libs/glibc-2.3.2
> 3/ we will need to prepare a list of packages which should not change 
> unless the user switches profiles.  those packages (e.g., toolchain) in 
> the current, and older profiles do not get updated except for fixes.  
> 4/ we will need to have a policy about how long we'll support a profile, 
> and a procedure for end-of-lifing profiles. (probably don't want to 
> support a single profile for more than 2 years)
> 5/ we will need to have documentation for users who are upgrading from one 
> profile to another (upgrade warnings, instructions and considerations)
> 6/ repoman will need to be enhanced to check the profiles before removing 
> any ebuilds from the tree that might be needed.  specific versions pinned 
> in profiles need to stay until the profile is changed.
> 
> Potential problems:
> 
> 1/ Makes KEYWORDS redundant
> 2/ Unstable (unreleased) profiles will probably, often run into conflicts 
> during commit
> 
> I probably missed some things, but it's a start.
> 
> Cheers,
> Dylan Carlson [absinthe@gentoo.org]
> Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F
> 
> --
> gentoo-dev@gentoo.org mailing list
> 

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


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Dylan Carlson]

On Tuesday 20 July 2004 5:14 pm, Olivier Crete wrote:
> Hi,
>
> The main problem with the profiles approach is that need to keep all of
> the "old" ebuilds for previous profiles in the tree, unnecessarily
> bloating the tree and then we have the risk that package maintainers
> will remove the stable packages after a while by mistake..

That is why repoman exists.   In theory, repoman would block any commits 
removing ebuilds from the tree which are needed by a profile in the same 
way that it prevents ebuilds with broken dependencies or syntax from being 
committed.

> My favorite solution is the portage snapshot + overlay solution. Where
> the gentoo-stable project makes a snapshot (like we already do on every
> livecd), it could even be the same snapshot. And then maintain (in a new
> tree) an overlay with only security fixes. This tree could then be
> rsynced with gensync (or with a modified portage).

If we were using something besides CVS (like arch) I might agree with that, 
at least in part...

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

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Stuart Herbert]

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

On Tuesday 20 July 2004 21:43, Dylan Carlson wrote:
> My thoughts on this are:
>
> 1/ Many Gentoo users want the ability to update packages for fixes only
> (and not just for servers)

That's simple - just don't do 'emerge sync; emerge -u world' on a daily basis.  
Only upgrade when you definitely need a fix.
</troll>

There's a serious point to that.  There should be some discussion to make sure 
we actually understand the problem we're trying to solve first ;-)

> 2/ Maintaining separate trees in CVS is probably asking too much of our
> current roster, plus requires adding infrastructure and getting everyone
> to mirror the new tree(s)

Agreed.

> 3/ Users already have a good understanding of what profiles are.  This is
> useful.

I believe that's an assumption not based in fact.

> 4/ Creating separate CVS trees while also using profiles seems superfluous.

Not sure about that.  I believe a profile is something that should never 
change once it's marked stable.  Right now, I don't see how that fits in with 
our ever-changing tree.

> Therefore I believe another possible solution is to change the way we use
> profiles (both in practice and in QA policy):
>
> Implications:
>
> 1/ archs will need to have a regular, predictable release schedule,
> probably at least every six months.

Why?  Not saying I don't agree, but it'd help if this assertion was justified.

> 2/ profiles will list specific package versions whenever possible.  e.g.:
> =sys-libs/glibc-2.3.2



> 3/ we will need to prepare a list of packages which should not change
> unless the user switches profiles.  those packages (e.g., toolchain) in
> the current, and older profiles do not get updated except for fixes.

I don't think this is sustainable.  Practically every new version of a package 
contains fixes compared to the one that it replaces.

> 4/ we will need to have a policy about how long we'll support a profile,
> and a procedure for end-of-lifing profiles. (probably don't want to
> support a single profile for more than 2 years)

Not *less* than 2 years, I'd have thought.  Some commercial systems are 
supported for 5 or even 10 years.

> 5/ we will need to have documentation for users who are upgrading from one
> profile to another (upgrade warnings, instructions and considerations)
> 6/ repoman will need to be enhanced to check the profiles before removing
> any ebuilds from the tree that might be needed.  specific versions pinned
> in profiles need to stay until the profile is changed.
>
> Potential problems:
>
> 1/ Makes KEYWORDS redundant

So every single one of our 8,000+ packages that's stable will have to be 
listed in one or more profiles?  That sounds impractical.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
                                                   http://stu.gnqs.org/diary/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] Revisiting GLEP 19

[Kurt Lieber]

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

On Tue, Jul 20, 2004 at 11:06:15PM +0100 or thereabouts, Stuart Herbert wrote:
> > 4/ we will need to have a policy about how long we'll support a profile,
> > and a procedure for end-of-lifing profiles. (probably don't want to
> > support a single profile for more than 2 years)
> 
> Not *less* than 2 years, I'd have thought.  Some commercial systems are 
> supported for 5 or even 10 years.

For a community distribution, I personally believe 2 years is more than
sufficient.  I'd even say 12-18 months is reasonable.

I don't think we have the resources to maintain things for 5-10 years.

--kurt

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

Re: [gentoo-dev] Revisiting GLEP 19

[Toby Dickenson]

On Tuesday 20 July 2004 23:50, Kurt Lieber wrote:
> On Tue, Jul 20, 2004 at 11:06:15PM +0100 or thereabouts, Stuart Herbert 
wrote:
> > > 4/ we will need to have a policy about how long we'll support a profile,
> > > and a procedure for end-of-lifing profiles. (probably don't want to
> > > support a single profile for more than 2 years)
> > 
> > Not *less* than 2 years, I'd have thought.  Some commercial systems are 
> > supported for 5 or even 10 years.
> 
> For a community distribution, I personally believe 2 years is more than
> sufficient.  I'd even say 12-18 months is reasonable.
> 
> I don't think we have the resources to maintain things for 5-10 years.

Even if we dont maintain or support versions older than a year, I would like 
to see the old enterprise ebuilds available in enterprise portage for at 
least 2 years if not longer. It is important to be able to reproduce a 
production system, bugs and all.

fwiw, I still regularly emerge ebuilds from my November 2002 snapshot, and 
dont plan on retiring this system soon.

-- 
Toby Dickenson

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Dylan Carlson]

On Tuesday 20 July 2004 6:06 pm, Stuart Herbert wrote:

> That's simple - just don't do 'emerge sync; emerge -u world' on a daily
> basis. Only upgrade when you definitely need a fix.
> </troll>

Actually you have a point in that many (good) IT shops follow that policy 
already.  But they all have an upstream vendor that does much of that QA 
for them, in the event they don't have the time to exhaustively research 
an update, or run it through every test case.

> > 3/ Users already have a good understanding of what profiles are.  This
> > is useful.
>
> I believe that's an assumption not based in fact.

Given what user threads I've seen, most Gentoo users understand what 
profiles are in a basic sense.  We've had some debate here in -dev on what 
they are, and what they should be...

> > 4/ Creating separate CVS trees while also using profiles seems
> > superfluous.
>
> Not sure about that.  I believe a profile is something that should never
> change once it's marked stable.  Right now, I don't see how that fits in
> with our ever-changing tree.

Essentially we agree, we're getting our signals crossed here.   I advocate 
a single tree with static profiles.  Right now profiles are just inclusion 
masks... but ideally they would be able to nail a profile down to certain 
package versions that are considered too vital, or large/unwieldy to allow 
enhancement upgrades.

> > 1/ archs will need to have a regular, predictable release schedule,
> > probably at least every six months.
>
> Why?  Not saying I don't agree, but it'd help if this assertion was
> justified.

It clarifies a release/QA schedule for both devs & users, and allows 
downstream enterprises to plan in advance to test OS upgrades and deploy.
Everybody has a spot on the calendar they're working towards.

Even if the release isn't substantial, there's always enough change in a 
6-mo window to justify a new release.

> I don't think this is sustainable.  Practically every new version of a
> package contains fixes compared to the one that it replaces.

We have to make a distinction between critical fixes (esp. security) and 
everything else.  Most bugs are not show-stoppers.

> Not *less* than 2 years, I'd have thought.  Some commercial systems are
> supported for 5 or even 10 years.

It's rather arbitrary but whatever we decide initially will set a 
precedent.  It's all a question of what we can actually support (vs what 
we say we will).  If we start off with a 2 year policy, and we find that 
the 2-year-old profiles are still widely in use, we would probably need to 
make a decision at that juncture.

- Do we say, ok, we'll revise our policy to state a 3-year-lifespan, and 
scale our developer pool to deal with this, or...
- Say, look, we think a 2-year cycle is reasonable time for any 
organization to do upgrades.  We don't think it's in the best interests of 
Gentoo to try to spread ourselves thin supporting software versions that 
are 2 or more years old... even if that is possible.  If this doesn't meet 
an organization's particular requirements, there are other vendors who may 
support older releases longer than we do.

In sum:  we can't please everyone, and beyond that we have to be realistic 
about what we want to support.  If we get funded and have devs paid to 
support releases beyond 2 years-- well, that's another matter altogether.

> So every single one of our 8,000+ packages that's stable will have to be
> listed in one or more profiles?  That sounds impractical.

No, not at all.  Like I said:  "a list of packages which should not change 
unless the user switches profiles".  That's not meant to include the whole 
tree.  That's a set of packages which we (Gentoo devs) build and add to 
based on user feedback.

Obviously our profile system is flexible enough already where we can simply 
create different profiles for different deployment scenarios (server, 
workstation, home).   A "workstation" profile would pin versions of KDE 
and GNOME packages, for example... where "home" would not.

Hopefully I'm making sense here.  :-)

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

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Chris Gianelloni]

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

On Tue, 2004-07-20 at 16:43, Dylan Carlson wrote:
> 1/ Many Gentoo users want the ability to update packages for fixes only 
> (and not just for servers)

Agreed.

> 2/ Maintaining separate trees in CVS is probably asking too much of our 
> current roster, plus requires adding infrastructure and getting everyone 
> to mirror the new tree(s)

Agreed.

> 3/ Users already have a good understanding of what profiles are.  This is 
> useful.

Possibly... The current Gentoo profile system would need to be modified
to allow for changes.  This might be workable using cascading profiles,
though.

> 4/ Creating separate CVS trees while also using profiles seems superfluous.

Agreed.

> Therefore I believe another possible solution is to change the way we use 
> profiles (both in practice and in QA policy):

I'm not sure I like the idea of changing profiles for any reason.  As
many people agreed when I asked about the creation of the
default-x86-2004.2 profile for the switch from xfree to xorg-x11 on x86,
a user should expect the same packages be installed by the same profile,
no matter where in the release cycle or on what day they do their
install.  You *will* notice that I say "packages" and not "package
versions" in that statement.

> Implications:
> 
> 1/ archs will need to have a regular, predictable release schedule, 
> probably at least every six months.

Like our current quarterly release schedule?

> 2/ profiles will list specific package versions whenever possible.  e.g.:
> =sys-libs/glibc-2.3.2

This would make it impossible to upgrade the version.  A version should
never be pinned in a profile.

> 3/ we will need to prepare a list of packages which should not change 
> unless the user switches profiles.  those packages (e.g., toolchain) in 
> the current, and older profiles do not get updated except for fixes.  

No package should change.  Package versions should only change for major
fixes/security updates.  I'm not sure I see the point in this one, since
the list would be redundant.

> 4/ we will need to have a policy about how long we'll support a profile, 
> and a procedure for end-of-lifing profiles. (probably don't want to 
> support a single profile for more than 2 years)

I think we had decided that a good number was 4 releases.  Now, the
length of time for that would be determined by the release schedule,
naturally.  The biggest problem will be our lack of manpower to back
port fixes.  I really don't see us overcoming this problem any time
soon.

> 5/ we will need to have documentation for users who are upgrading from one 
> profile to another (upgrade warnings, instructions and considerations)

Agreed, whether it be profile-based or not.

> 6/ repoman will need to be enhanced to check the profiles before removing 
> any ebuilds from the tree that might be needed.  specific versions pinned 
> in profiles need to stay until the profile is changed.

I agree that changes would need to be made.  I just am not sure that a
profile is what would bring about such changes.

Honestly, the problem that we face is manpower.  Plain and simple.  In
many cases, we don't have enough developers for what we already are
doing.  No matter what we decide as a technical solution to a stable
tree, I just don't see a possible way to solve these problems without
adding a massive number of developers.

I can see how profiles could be used to accomplish this sort of thing,
but pinning of versions would not be the way to go about it.

Here is my ideas on how this could be done.  Feel free to rip them
apart... Some of the ideas here would require some large changes to our
Standard Operating Procedure.

For simplicity, I'm going to name everything, but none of this is set in
stone.  For one, the "gentoo-x86" CVS module would be come
"gentoo-current", as it reflects the actual usage and state of the
tree.  The profiles in the current tree would have their versions
removed, as this is a fluid target.  This matches our current tree the
best, and allows for us to make dynamic changes to the profiles between
releases.  For example, default-x86-2005.0 (or
default-linux/x86/2005.0), would become default-linux/x86/current.  Each
release tree would be identified as such.  I'm going to work with
cascading profiles, to make my life easier.  At release time, a branch
is made for the release.  We would take the stable ebuilds/packages from
gentoo-current and drop it into gentoo-2005.0-release and a new profile
default-linux/x86/2005.0 would be created.  This profile would never
change.  If there were multiple sets of stages created, such as the
amd64 release for 2004.2, which will have both gcc 3.3 and gcc 3.4
stages, a sub-profile would be created,
default-linux/amd64/2005.0/gcc34.

At this point, the -release tree is turned over to -releng and the arch
leads/maintainers for preparation for the impending release.  If changes
are needed that only affect the LiveCD/GRP, they go into the tree
directly.  If changes are needed that affect the package as a whole, the
package maintainer is contacted, and the package is fixed in both the
-current and -release trees.  At some point, the tree is frozen and a
snapshot is made.  This becomes the official snapshot for that release. 
A new rsync mirror set is created for the tree, and the make.globals
SYNC is set to that new rsync mirror,
rsync://rsync.gentoo.org/gentoo-2005.0-release/.  The stages/LiveCD/GRP
is built for the release, and everything is golden.  The things that are
marked as "stable" are never changed via rsync in this tree, as they are
the unchanging base.  The release is made, the planets align, and there
is peace for a thousand generations...

...until disaster strikes and a package has a security vulnerability. 
At this point, the package is patched, a GLSA is released, and the new
ebuild goes into the tree as ~arch.  You will notice that I have left
out the whole "who does the updates" part of this and there is a good
reason for it.  I haven't got a clue.  This would need to be decided by
interest.  After all, many people are not going to be very excited about
applying patches to old versions of software, and that's ok.
*** This is the weakness in not only my plan, but ANY "Enterprise
Gentoo" plan ***


With my method, a user can change between releases simply by overriding
SYNC in make.conf to whatever release they wish, or even to -current. 
The upgrade would be just like doing a massive "emerge sync && emerge -u
world" after not syncing for 6 months.  Everything would upgrade
smoothly.  We would update the user's profile at sync time, too.  We
would need to include some form of logic to know whether our rsync
mirror choice has changed, and take appropriate actions.  For example,
if I were going from 2005.0 to 2005.1 and running an amd64 with the
gcc34 profile, if there is an amd64/2005.1/gcc34 profile, then the
switch is simple.  If amd64 has adopted gcc 3.4 as the default, then the
profile would revert to the default.

Is there anything I missed?

Discuss amongst yourselves...

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

Is your power animal a penguin?

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

Re: [gentoo-dev] Revisiting GLEP 19

[Olivier Crete]

Hey,


On Wed, 2004-07-21 at 16:00 -0400, Chris Gianelloni wrote:
> > 4/ we will need to have a policy about how long we'll support a profile, 
> > and a procedure for end-of-lifing profiles. (probably don't want to 
> > support a single profile for more than 2 years)
> 
> I think we had decided that a good number was 4 releases.  Now, the
> length of time for that would be determined by the release schedule,
> naturally.  The biggest problem will be our lack of manpower to back
> port fixes.  I really don't see us overcoming this problem any time
> soon.

Four releases a year is way to many.. after two years its 8 releases to
support.. This vastly exceeds our current man-power.. Debian with its
over 1000 devs only maintains one.  One a year seems like a better
number to me (maybe two a year).

In the multiple profile scenario.. that would create possibly hundreds
of ebuilds to be kept in the tree for a single package (one per release
per arch and then a few unstable... thinking of a package like glibc).. 


> I can see how profiles could be used to accomplish this sort of thing,
> but pinning of versions would not be the way to go about it.

I agree


> For simplicity, I'm going to name everything, but none of this is set in
> stone.  For one, the "gentoo-x86" CVS module would be come
> "gentoo-current", as it reflects the actual usage and state of the
> tree.  The profiles in the current tree would have their versions
> removed, as this is a fluid target.  This matches our current tree the
> best, and allows for us to make dynamic changes to the profiles between
> releases.  For example, default-x86-2005.0 (or
> default-linux/x86/2005.0), would become default-linux/x86/current.  Each
> release tree would be identified as such.  I'm going to work with
> cascading profiles, to make my life easier.  At release time, a branch
> is made for the release.  We would take the stable ebuilds/packages from
> gentoo-current and drop it into gentoo-2005.0-release and a new profile
> default-linux/x86/2005.0 would be created.  This profile would never
> change.  If there were multiple sets of stages created, such as the
> amd64 release for 2004.2, which will have both gcc 3.3 and gcc 3.4
> stages, a sub-profile would be created,
> default-linux/amd64/2005.0/gcc34.
> 
> At this point, the -release tree is turned over to -releng and the arch
> leads/maintainers for preparation for the impending release.  If changes
> are needed that only affect the LiveCD/GRP, they go into the tree
> directly.  If changes are needed that affect the package as a whole, the
> package maintainer is contacted, and the package is fixed in both the
> -current and -release trees.  At some point, the tree is frozen and a
> snapshot is made.  This becomes the official snapshot for that release. 
> A new rsync mirror set is created for the tree, and the make.globals
> SYNC is set to that new rsync mirror,
> rsync://rsync.gentoo.org/gentoo-2005.0-release/.  The stages/LiveCD/GRP
> is built for the release, and everything is golden.  The things that are
> marked as "stable" are never changed via rsync in this tree, as they are
> the unchanging base.  The release is made, the planets align, and there
> is peace for a thousand generations...

I like the idea of a separate tree.. But if it really rarely changes,
rsync is just overkill and will overburden our mirrors.. Lets just make
it a tarball and put the enhancements in a rsync'ed overlay. Rsync is
for stuff that changes...


> ...until disaster strikes and a package has a security vulnerability. 
> At this point, the package is patched, a GLSA is released, and the new
> ebuild goes into the tree as ~arch.  You will notice that I have left
> out the whole "who does the updates" part of this and there is a good
> reason for it.  I haven't got a clue.  This would need to be decided by
> interest.  After all, many people are not going to be very excited about
> applying patches to old versions of software, and that's ok.
> *** This is the weakness in not only my plan, but ANY "Enterprise
> Gentoo" plan ***

This overlays should probably each have their own cvs module (or all be
directories under the same module, I dont really care... Where all
package maintainers would have access.. And then we can mark them stable
using the same kind of procedures we currently use for GLSAs...

Also, the problem with maintaining older versions is that we need to
have at least one machine available for each version where the concerned
devs can test security updates.. Ok, maybe at least one per
architectures using chroots... but its still a lot of  infrastructure..
That's why reducing the number of stable releases to maybe even just one
a year might be a good idea.



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


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Chris Gianelloni]

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

On Wed, 2004-07-21 at 17:12, Olivier Crete wrote:
> I like the idea of a separate tree.. But if it really rarely changes,
> rsync is just overkill and will overburden our mirrors.. Lets just make
> it a tarball and put the enhancements in a rsync'ed overlay. Rsync is
> for stuff that changes...

That works for me.  I was simply trying to propose a way to do it with
the least amount of changes for the users.  Perhaps have the main
tarball delivered by rsync so a version switch is still transparent?

> This overlays should probably each have their own cvs module (or all be
> directories under the same module, I dont really care... Where all
> package maintainers would have access.. And then we can mark them stable
> using the same kind of procedures we currently use for GLSAs...
> 
> Also, the problem with maintaining older versions is that we need to
> have at least one machine available for each version where the concerned
> devs can test security updates.. Ok, maybe at least one per
> architectures using chroots... but its still a lot of  infrastructure..
> That's why reducing the number of stable releases to maybe even just one
> a year might be a good idea.

I'm not opposed to that.  I think I would prefer 2, simply to reduce the
amount changed between releases, making it easier for users to upgrade. 
Switching to 2 releases per year with a 4 release retention puts us at 2
years of support in the -release trees.  Switching to 1 year release
cycles puts us out to 4 years.  An awful lot can change in 4 years in
the Linux world.  I'm not sure we would possibly be able to keep up with
such a long-reaching goal.

Personally, I would say we try to move on this by 2005.0 and see what
happens, without changing release schedules and only supporting 4
releases.  This would carry us through 2005.X and into 2006.X, where we
could make adjustments to the release cycle if we deem it necessary.

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

Is your power animal a penguin?

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

Re: [gentoo-dev] Revisiting GLEP 19

[Michael Marineau]

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

Olivier Crete wrote:

| On Wed, 2004-07-21 at 16:00 -0400, Chris Gianelloni wrote:

|>I can see how profiles could be used to accomplish this sort of thing,
|>but pinning of versions would not be the way to go about it.
|
|
| I agree

I second that, profiles seem like something that is far to static to work well
with security updates and allowing site admins to upgrade specific packages if
they choose to do so.
|
|
|
|>For simplicity, I'm going to name everything, but none of this is set in
|>stone.  For one, the "gentoo-x86" CVS module would be come
|>"gentoo-current", as it reflects the actual usage and state of the
|>tree.  The profiles in the current tree would have their versions
|>removed, as this is a fluid target.  This matches our current tree the
|>best, and allows for us to make dynamic changes to the profiles between
|>releases.  For example, default-x86-2005.0 (or
|>default-linux/x86/2005.0), would become default-linux/x86/current.  Each
|>release tree would be identified as such.  I'm going to work with
|>cascading profiles, to make my life easier.  At release time, a branch
|>is made for the release.  We would take the stable ebuilds/packages from
|>gentoo-current and drop it into gentoo-2005.0-release and a new profile
|>default-linux/x86/2005.0 would be created.  This profile would never
|>change.  If there were multiple sets of stages created, such as the
|>amd64 release for 2004.2, which will have both gcc 3.3 and gcc 3.4
|>stages, a sub-profile would be created,
|>default-linux/amd64/2005.0/gcc34.
|>
|>At this point, the -release tree is turned over to -releng and the arch
|>leads/maintainers for preparation for the impending release.  If changes
|>are needed that only affect the LiveCD/GRP, they go into the tree
|>directly.  If changes are needed that affect the package as a whole, the
|>package maintainer is contacted, and the package is fixed in both the
|>-current and -release trees.  At some point, the tree is frozen and a
|>snapshot is made.  This becomes the official snapshot for that release.
|>A new rsync mirror set is created for the tree, and the make.globals
|>SYNC is set to that new rsync mirror,
|>rsync://rsync.gentoo.org/gentoo-2005.0-release/.  The stages/LiveCD/GRP
|>is built for the release, and everything is golden.  The things that are
|>marked as "stable" are never changed via rsync in this tree, as they are
|>the unchanging base.  The release is made, the planets align, and there
|>is peace for a thousand generations...
|
|
| I like the idea of a separate tree.. But if it really rarely changes,
| rsync is just overkill and will overburden our mirrors.. Lets just make
| it a tarball and put the enhancements in a rsync'ed overlay. Rsync is
| for stuff that changes...

I also like the seperate trees.  And splitting out the base system into a
tarball and putting only updates in the rsync tree is certainly doable.
However, dividing out between a release tarball and synced updates begins to
distroy the elegence that only switching a portage tree has.  I don't really
see why using rsync will overburden the mirrors any more than they are now.
Afterall, currently everyone has to rsync.  If it is so important to use
tarballs maybe it would work to just provide update snapshots that can be
downloaded and inserted into the existing tree. Snapshots could be done by
either grabbing the whole tree or just include new or updated ebuilds.  Basicly
it would be encouraging enerprise users to use emerge-webrsync instead of
emerge sync.  Personally though, I don't think avoiding rsync would really help
that much.
|
|
|
|>...until disaster strikes and a package has a security vulnerability.
|>At this point, the package is patched, a GLSA is released, and the new
|>ebuild goes into the tree as ~arch.  You will notice that I have left
|>out the whole "who does the updates" part of this and there is a good
|>reason for it.  I haven't got a clue.  This would need to be decided by
|>interest.  After all, many people are not going to be very excited about
|>applying patches to old versions of software, and that's ok.
|>*** This is the weakness in not only my plan, but ANY "Enterprise
|>Gentoo" plan ***

Who maintains the old trees is a pretty big issue.  Is this more serious than
just determining how many releases to support and will actually limit how
'enterprise' like enterprise gentoo will be?  There have been a far range of
needs that could be addressed.  Can gentoo do it all or just rehash fancy ways
of doing `glsa-check`?
|
|
| This overlays should probably each have their own cvs module (or all be
| directories under the same module, I dont really care... Where all
| package maintainers would have access.. And then we can mark them stable
| using the same kind of procedures we currently use for GLSAs...
|
| Also, the problem with maintaining older versions is that we need to
| have at least one machine available for each version where the concerned
| devs can test security updates.. Ok, maybe at least one per
| architectures using chroots... but its still a lot of  infrastructure..
| That's why reducing the number of stable releases to maybe even just one
| a year might be a good idea.
|
|
|


- --
Michael Marineau
marineam@engr.orst.edu
Oregon State University
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA/uawiP+LossGzjARAmYbAJ4sswV9auaRqQAm+sADGL4lTXK90ACeMPIU
3aZUzSmnBx5XAQBfbwh5OBY=
=YC3k
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Chris Gianelloni]

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

On Wed, 2004-07-21 at 17:57, Michael Marineau wrote:
> I also like the seperate trees.  And splitting out the base system into a
> tarball and putting only updates in the rsync tree is certainly doable.
> However, dividing out between a release tarball and synced updates begins to
> distroy the elegence that only switching a portage tree has.  I don't really
> see why using rsync will overburden the mirrors any more than they are now.
> Afterall, currently everyone has to rsync.  If it is so important to use
> tarballs maybe it would work to just provide update snapshots that can be
> downloaded and inserted into the existing tree. Snapshots could be done by
> either grabbing the whole tree or just include new or updated ebuilds.  Basicly
> it would be encouraging enerprise users to use emerge-webrsync instead of
> emerge sync.  Personally though, I don't think avoiding rsync would really help
> that much.

I'm not sure why rsync would be too bad myself.  I merely mentioned
another option.  As I said originally, I'm totally open to discussion. 
I definitely like the simplicity in my original comment of switching
portage trees.

> Who maintains the old trees is a pretty big issue.  Is this more serious than
> just determining how many releases to support and will actually limit how
> 'enterprise' like enterprise gentoo will be?  There have been a far range of
> needs that could be addressed.  Can gentoo do it all or just rehash fancy ways
> of doing `glsa-check`?

I totally agree.  I also think that being a community-based distribution
that doesn't have the resources that many other distributions can
afford, perhaps we should just start implementing what we can.  Would it
really be so bad to just do the -release trees, even if we didn't
provide updates for everything to begin with?  While this might not be
popular with everyone, I am sure there are a number of people who would
use the tree, and just like the -current portage tree that has gained
developers and other things over time, it would *evolve* into an
enterprise style product, rather than us never releasing anything of the
sort due to trying to solve all the problems at once.  Once again I ask,
is it better to try and fail, than to not try at all?  I mean, if we
tried to do this and weren't able to accomplish it, we would be able to
show people exactly why we were unable to do so, rather than give them
all these reasons of why we *think* we can't do it.

After all, in the open source world, you never know what can happen. 
IBM may step up and decide to throw some developers at helping us keep
the -release trees up to date... or Novell... or anybody.  You just
don't know and you can't say that it won't happen because nobody can
tell the future.  Perhaps we'll simply get enough ebuild submissions and
patches from the people using the -release trees that we'll be able to
sustain.  After all, the biggest problem everyone has with the -release
trees is "who's going to maintain it", but it is infinitely easier to
test a patch that someone has provided to solve a problem than it is to
locate the problem, figure out how to fix it, write a patch, and test a
patch.

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

Is your power animal a penguin?

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

Re: [gentoo-dev] Revisiting GLEP 19

[Michael Marineau]

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

Kurt Lieber wrote:
| A while back, I wrote GLEP 19[1] based on some of the needs of the
| gentoo-server project.  For various reasons, the GLEP was tabled at the
| time and never went anywhere.  A number of folks have expressed an interest
| in revitalizing this GLEP, so I'd like to start a new discussion about
| implementing it.  There was a couple of previous threads on this GLEP back
| when it was first introduced that I'll include[2] for your reference.
|
| So, with that said, thoughts, comments and other ideas are welcome.
|
| --kurt
|
| [1] http://glep.gentoo.org/glep-0019.html
| [2] http://thread.gmane.org/gmane.linux.gentoo.devel/15511
|     http://thread.gmane.org/gmane.linux.gentoo.devel/15584 (round 2)

~From the looks of the thread so far people seem to be leaning toward
implimenting this system via profiles rather than the suggested new keyword
system in the GLEP.  I think there are a couple issues with that solution,
maybe someone can clarify this for me.

1. Users dealing with profiles would need to be able to be easily change, and
review the possible profiles via a nice interface so that when that quartly
switch comes, it isn't to hard to understand what is going on.
2. This will require a bit of a paradigm shift in users. At the moment it seems
~ (in the eyes of a normal user) like profiles are something in the background
of the system, but no one other than gentoo devs need know what they are or how
to use them.  This is just my impression.
3. If a profile defines a specific set of packages that should not be upgraded
how are the possible security upgrades handled?  If the profile defines package
versions then the profile would need to be modified.  From my understanding a
stable profile normally should not be modified, but maybe this will change?

- --
Michael Marineau
marineam@engr.orst.edu
Oregon State University
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA/bhoiP+LossGzjARAm3OAJ9kRitfKjHTd7pULZDa8vXzQFGBXQCfcA2H
5WS/WvTVKo8G0F9IFj+YU0s=
=JW6Z
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Dylan Carlson]

On Tuesday 20 July 2004 8:27 pm, Michael Marineau wrote:

> ~From the looks of the thread so far people seem to be leaning toward
> implimenting this system via profiles rather than the suggested new
> keyword system in the GLEP. 

Hopefully nobody is leaning towards anything yet; myself I want all the 
options out on the table, so we can talk about it.   If anything we might 
be eliminating ideas that paint us into a corner, or ones we can't 
reasonably execute sometime in the next 6-12 months.

> 1. Users dealing with profiles would need to be able to be easily
> change, and review the possible profiles via a nice interface so that
> when that quartly switch comes, it isn't to hard to understand what is
> going on.

Interface?  It wouldn't differ from how upgrades are currently performed. 

- Change your profile to a newer one
- emerge -pv system
- emerge -pv world
- modify make.conf, /etc/portage/* to taste
- and so on

> 2. This will require a bit of a paradigm shift in users. At the moment
> it seems ~ (in the eyes of a normal user) like profiles are something in
> the background of the system, but no one other than gentoo devs need
> know what they are or how to use them.  This is just my impression.

Release numbers basically correspond to profiles.  So most people 
understand this, at that level.  Profiles as they are used right now are 
inclusion masks, but do not address the functionality I'm/we're proposing 
in this thread.

> 3. If a profile defines a specific set of packages that should not be
> upgraded how are the possible security upgrades handled?  If the profile
> defines package versions then the profile would need to be modified. 
> From my understanding a stable profile normally should not be modified,
> but maybe this will change?

Depends on how the package is versioned in the profile. E.g.  if you have 
glibc-2.3.2-r2 installed, and your profile has:

=sys-libs/glibc-2.3.2

You will get glibc-2.3.2-r3 and any other updates, but not 2.3.3 or later.   
If, for whatever reason, that release needs to be updated to 2.3.3, the 
profile will need to be changed.  Which is not an issue if there's a valid 
reason why it needs to be done.

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

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Michael Marineau]

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


| Interface?  It wouldn't differ from how upgrades are currently performed.
|
| - Change your profile to a newer one
The above step is the one that I see as unclear in the current system.
| - emerge -pv system
| - emerge -pv world
| - modify make.conf, /etc/portage/* to taste
| - and so on

| Depends on how the package is versioned in the profile. E.g.  if you have
| glibc-2.3.2-r2 installed, and your profile has:
|
| =sys-libs/glibc-2.3.2
|
| You will get glibc-2.3.2-r3 and any other updates, but not 2.3.3 or later.
| If, for whatever reason, that release needs to be updated to 2.3.3, the
| profile will need to be changed.  Which is not an issue if there's a valid
| reason why it needs to be done.
Sounds reasonable to me.
|
| Cheers,
| Dylan Carlson [absinthe@gentoo.org]
| Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F
|
| --
| gentoo-dev@gentoo.org mailing list


- --
Michael Marineau
marineam@engr.orst.edu
Oregon State University
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA/cG5iP+LossGzjARAg/KAJ4klnkIx1yi7+Laa6oQP/6owMv98wCfR7r8
hjgQUbBorkf0ikNyq4uuKo4=
=ynP9
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Dylan Carlson]

On Tuesday 20 July 2004 9:07 pm, Michael Marineau wrote:
> | Interface?  It wouldn't differ from how upgrades are currently
> | performed.
> |
> | - Change your profile to a newer one
>
> The above step is the one that I see as unclear in the current system.

It's documented (though dated) here:
http://www.gentoo.org/doc/en/gentoo-upgrading.xml

That's not procedurally much different than configuring a new kernel.   
(linking /usr/src/linux to whatever kernel version you're using)

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

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Martin Schlemmer]

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

On Wed, 2004-07-21 at 03:07, Michael Marineau wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> | Interface?  It wouldn't differ from how upgrades are currently performed.
> |
> | - Change your profile to a newer one
> The above step is the one that I see as unclear in the current system.
> | - emerge -pv system
> | - emerge -pv world
> | - modify make.conf, /etc/portage/* to taste
> | - and so on
> 
> | Depends on how the package is versioned in the profile. E.g.  if you have
> | glibc-2.3.2-r2 installed, and your profile has:
> |
> | =sys-libs/glibc-2.3.2
> |

Except if anything change, this is wrong - it should be:

 ~sys-libs/glibc-2.3.2

> | You will get glibc-2.3.2-r3 and any other updates, but not 2.3.3 or later.
> | If, for whatever reason, that release needs to be updated to 2.3.3, the
> | profile will need to be changed.  Which is not an issue if there's a valid
> | reason why it needs to be done.
> Sounds reasonable to me.
> |
> | Cheers,
> | Dylan Carlson [absinthe@gentoo.org]
> | Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F
> |
> | --
> | gentoo-dev@gentoo.org mailing list
> 
> 
> - --
> Michael Marineau
> marineam@engr.orst.edu
> Oregon State University
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFA/cG5iP+LossGzjARAg/KAJ4klnkIx1yi7+Laa6oQP/6owMv98wCfR7r8
> hjgQUbBorkf0ikNyq4uuKo4=
> =ynP9
> -----END PGP SIGNATURE-----
> 
> --
> gentoo-dev@gentoo.org mailing list
-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



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

Re: [gentoo-dev] Revisiting GLEP 19

[Marius Mauch]

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

On 07/20/04  Dylan Carlson wrote:

> Depends on how the package is versioned in the profile. E.g.  if you
> have glibc-2.3.2-r2 installed, and your profile has:
> 
> =sys-libs/glibc-2.3.2
> 
> You will get glibc-2.3.2-r3 and any other updates, but not 2.3.3 or
> later.   If, for whatever reason, that release needs to be updated to
> 2.3.3, the profile will need to be changed.  Which is not an issue if
> there's a valid reason why it needs to be done.

Incorrect. The = means exactly that version, to include revisions you
have to use the ~ operator. Unfortunately a value like
~sys-libs/glibc-2.3.2-r9 (to include -r9, -r10, ... but not -r8 or
2.3.3) is invalid.

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: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Revisiting GLEP 19

[Dylan Carlson]

On Wednesday 21 July 2004 12:13 pm, Marius Mauch wrote:
> Incorrect. The = means exactly that version, to include revisions you
> have to use the ~ operator. Unfortunately a value like
> ~sys-libs/glibc-2.3.2-r9 (to include -r9, -r10, ... but not -r8 or
> 2.3.3) is invalid.

Hmmm, well, you're partially correct, it was my mistake.  This should 
follow the operators how they are used in DEPEND/RDEPEND.  I should have 
said:

=sys-libs/glibc-2.3.2* 

(note the asterisk).  Which would include the newest 2.3.2 version, but not 
anything earlier (<=2.3.1) or later (>=2.3.3).   In the case of using ~, 
one would use 

~sys-libs/glibc-2.3.2

not

~sys-libs/glibc-2.3.2-r9.

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

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Chris Gianelloni]

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

On Tue, 2004-07-20 at 20:54, Dylan Carlson wrote:
> Depends on how the package is versioned in the profile. E.g.  if you have 
> glibc-2.3.2-r2 installed, and your profile has:
> 
> =sys-libs/glibc-2.3.2
> 
> You will get glibc-2.3.2-r3 and any other updates, but not 2.3.3 or later.   
> If, for whatever reason, that release needs to be updated to 2.3.3, the 
> profile will need to be changed.  Which is not an issue if there's a valid 
> reason why it needs to be done.

Actually, if =sys-libs/glibc-2.3.2 was in your profile, then 2.3.2-r1
would never install.  Neither would *any* version other than 2.3.2
exactly.

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

Is your power animal a penguin?

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

Re: [gentoo-dev] Revisiting GLEP 19

[Barry Shaw]

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


|
| So, with that said, thoughts, comments and other ideas are welcome.
|

So far most of the discussion seems to center around stable portage as
snapshots of the main tree taken at regular intervals.  These snapshots
contain only packages marked as stable, and only security updates are
applied to the snapshots.

It might be worth considering instead a model where a snapshot is taken
then only security patches are applied, with the exception that should a
particular version of an application become depreciated, it can then
also be upgraded (provided the upgraded version is also considered stable).

This would enable snapshots to last for a longer period (I think four a
year is going to be too much work), it prevents any requirement for
backporting (which I think is a bad idea as it makes ebuild maintainers
into application maintainers) and it would also make the maintenence of
older snapshots more viable as there would be less work to do in general.

Some of the current discussion on the length of time snapshots are
maintained is concerning as production servers, in my experience, remain
in the same state for years - a one year maintenence period is not long
enough (it would be for workstations however as these are easier to take
out of service for an hour or so and upgrade).

In reality, if a application on a production server reaches a state
where it is unmaintained in favour of a newer version, then its likely
that the admins would upgrade the application to the supported version.
~ Most responsible program maintainers provide upgrade paths anyways, so
as long non security related package upgrade wasn't forced on
subscribers to the stable tree, it shouldn't be too bad.  At the least
if such a change could be signalled, people would be prepared.

I guess what I'm describing isn't strictly an enterprise gentoo (which I
don't think the community has the resources to support), more of a
slowed down version of the main portage tree.  In my experience
maintaining a couple of hundred of gentoo machines centrally, its the
rapid pace of change in the main tree that causes problems.  We only
only upgrade packages for security reasons, but whenever we do this, we
are forced to upgrade a multitude of other packages because they've
dropped out of portage.  If we only had to upgrade packages for security
and depreciation reasons it would make for a much more stable
environment for the end users (which is what we're after ultimately) and
~ it would make maintenence more manageable.

Baz


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA/c0gJvZkjpKMF2wRAiZXAKCAngA2ZVztXnGg0zXRmhtaqYGV5ACcDs5m
cO4fxnbFP+5ulb4CHfI6uN4=
=9/gh
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Michael Marineau]

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

Barry Shaw wrote:

| I guess what I'm describing isn't strictly an enterprise gentoo (which I
| don't think the community has the resources to support), more of a
| slowed down version of the main portage tree.  In my experience
| maintaining a couple of hundred of gentoo machines centrally, its the
| rapid pace of change in the main tree that causes problems.  We only
| only upgrade packages for security reasons, but whenever we do this, we
| are forced to upgrade a multitude of other packages because they've
| dropped out of portage.  If we only had to upgrade packages for security
| and depreciation reasons it would make for a much more stable
| environment for the end users (which is what we're after ultimately) and
| ~ it would make maintenence more manageable.
I like this idea.  It fits better with the way Gentoo already runs, and will
work nicely once the pending glsa/emerge integration is complete.  Another
thought on top of this is that it would make sense to throw out the idea of
enterprise snapshots alltogether.  Instead, on the local system never force a
user to install a new version if their current version's ebuild is removed from
portage.  So basicly, use the ebuilds that are already cached as a portage
overly.  This also has a second benifit on the unstable side.  If someone needs
to install an unstable package but that ebuild is later dropped in favor of a
newer unstable version currently on the next emerge sync; emerge -Up world; the
unstable package will be uninstalled and replaced by the current stable version
(unless the issue is first addressed before the update).  This can be
troublesom, especially if someone is to quick and didn't notice that the
package is being downgraded.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA/d61iP+LossGzjARAkrpAJ0bHE9JV56ttk6dL3FM1XVS6LoMcACePNbH
gro06Mifc/j9csS6KMuzlBI=
=0+81
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Daniel Ostrow]

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

All:

Having been a Network Engineer (at 3 different companies) for most of my
professional career so I feel relatively confident that I have a good
picture of what is needed for GLEP 19 to work from the outside
perspective, how it is implemented is another story.

Most of the sys admins I have worked with belong to 2 schools, #1 is fix
security issues only and #2 is fix security issues and bugs. Those who
belong to school #1 generally fix bugs when and only when they directly
affect the operation of the company and then it is a highly scheduled
and highly localized event. Those belonging to school #2 usually have
wider maintenance windows built into their environments so that they can
achieve a more sweeping update. As such I believe that it is very
important to delineate weather a package is being updated in the "stable
tree" for security reasons or to fix a bug, and the changelog for the
package should have detailed information regarding what the security
vulnerability/bug is so that sys admins can pick and choose if need be.
So sys admins also like to be able to do it in one motion so there would
also have to be a way to "emerge security" and/or "emerge bugfix" the
same way that we have a emerge world/system now.

To that end in addition to having a tree that only gets security/bugfix
updates (and yes this can mean whole new versions if an important bugfix
is contained therein) we would need to expand on the stable keyword
concept to allow for the separation of security and bug related updates.
~ This is all contingent on us adopting this methodology which I am by no
means tied to, but I believe that any methodology needs to accommodate
this functionality.

As for retention, all 3 of the companies that I worked for did triannual
updates on the core system of their servers so I think 3 years is a safe
bet, where we are going to get the man power to support that is another
question entirely.

I'll probably think of more later, this is it for now.

Thanks,

Daniel Ostrow
dotrow@gentoo.org
Operational Lead
Gentoo/macos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA/hIbsb0gXCN8LgURAv3wAJ9mPQT06H6uJEOdV76dQPN/D0cYywCeN4dZ
iRnbtBzfQN4z8Q8uhzpWzLw=
=mJtH
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Chris Gianelloni]

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

On Wed, 2004-07-21 at 02:50, Daniel Ostrow wrote:
> Most of the sys admins I have worked with belong to 2 schools, #1 is fix
> security issues only and #2 is fix security issues and bugs. Those who
> belong to school #1 generally fix bugs when and only when they directly
> affect the operation of the company and then it is a highly scheduled
> and highly localized event. Those belonging to school #2 usually have
> wider maintenance windows built into their environments so that they can
> achieve a more sweeping update. As such I believe that it is very
> important to delineate weather a package is being updated in the "stable
> tree" for security reasons or to fix a bug, and the changelog for the
> package should have detailed information regarding what the security
> vulnerability/bug is so that sys admins can pick and choose if need be.
> So sys admins also like to be able to do it in one motion so there would
> also have to be a way to "emerge security" and/or "emerge bugfix" the
> same way that we have a emerge world/system now.

My proposal could work with either camp.  I really don't care either
way, as I simply think we need something implemented "soon" to start the
ball rolling and see what happens.  Better to try and fail than to never
try at all and all that jazz....

We would use emerge world to do the same as an emerge security, since
only security fixes would be added...... or..... We would use emerge
world to update everything, and emerge glsa to do only security fixes.

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

Is your power animal a penguin?

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

Re: [gentoo-dev] Revisiting GLEP 19

[Chris Gianelloni]

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

On Tue, 2004-07-20 at 21:55, Barry Shaw wrote:
> It might be worth considering instead a model where a snapshot is taken
> then only security patches are applied, with the exception that should a
> particular version of an application become depreciated, it can then
> also be upgraded (provided the upgraded version is also considered stable).

I would have no problem with this, provided it was the up-front decision
and we stuck to it.  It would still fit in with my (rather lengthy)
proposal, and would reduce the developer overhead significantly.

> This would enable snapshots to last for a longer period (I think four a
> year is going to be too much work), it prevents any requirement for
> backporting (which I think is a bad idea as it makes ebuild maintainers
> into application maintainers) and it would also make the maintenence of
> older snapshots more viable as there would be less work to do in general.

I think 2 a year with a 2 year retention (4 releases) would be the sweet
spot.  Nothing keeps users from running older releases, just we don't
support them officially any more.

> Some of the current discussion on the length of time snapshots are
> maintained is concerning as production servers, in my experience, remain
> in the same state for years - a one year maintenence period is not long
> enough (it would be for workstations however as these are easier to take
> out of service for an hour or so and upgrade).

What about Red Hat (think RHL, not RHEL)?  They only ever supported I
believe 2 releases back and had a release approximately every six
months.  At the same time, there are many servers out there that still
run 7.3 and even 6.2 and work perfectly fine.  Depending on their
function, they may be completely secure, also.  It is not that difficult
to write an ebuild.  Nothing is stopping a user from importing an ebuild
from the -current tree or any other -release tree into their overlay for
an upgrade.  We simply have to put a limit on how far back we support,
especially as we are a community-based distribution.

> In reality, if a application on a production server reaches a state
> where it is unmaintained in favour of a newer version, then its likely
> that the admins would upgrade the application to the supported version.
> ~ Most responsible program maintainers provide upgrade paths anyways, so
> as long non security related package upgrade wasn't forced on
> subscribers to the stable tree, it shouldn't be too bad.  At the least
> if such a change could be signalled, people would be prepared.

My thinking exactly.  With frozen package versions in the -release
trees, a company could evaluate whether their software operated as
expected on the new release.  Also, since we would be providing a simple
upgrade path, it would ease the workload on administrators using
"Enterprise Gentoo".

> I guess what I'm describing isn't strictly an enterprise gentoo (which I
> don't think the community has the resources to support), more of a
> slowed down version of the main portage tree.  In my experience
> maintaining a couple of hundred of gentoo machines centrally, its the
> rapid pace of change in the main tree that causes problems.  We only
> only upgrade packages for security reasons, but whenever we do this, we
> are forced to upgrade a multitude of other packages because they've
> dropped out of portage.  If we only had to upgrade packages for security
> and depreciation reasons it would make for a much more stable
> environment for the end users (which is what we're after ultimately) and
> ~ it would make maintenence more manageable.

I agree that there is no real need for an Enterprise Gentoo, but rather
fixed releases.

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

Is your power animal a penguin?

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

[gentoo-dev] Re: Revisiting GLEP 19

[Duncan]

Chris Gianelloni posted <1090441261.19552.124.camel@localhost>, excerpted
below,  on Wed, 21 Jul 2004 16:21:01 -0400:

> I think 2 a year with a 2 year retention (4 releases) would be the sweet
> spot.  Nothing keeps users from running older releases, just we don't
> support them officially any more.

First, I'm a personal desktop user who migrated to Gentoo in large part
for its "freshness".  Thus, the very idea of slowing things down seems
counter to the entire Gentoo thing, here, tho I understand the enterprise
need, and the appeal of a Gentoo Linux Enterprise.  If it's going to be
done, in some ways, I think some other name might be more appropriate, tho
if it's based on Gentoo, the other side says it's entirely appropriate.

Anyway.. I replied here in particular, because I wanted to comment on the
point quoted.  From my observation of the commercial distribs and their
reaction to Enterprise, as well as business reaction to their enterprise
products, both the six month window and the two year window are to short. 

If it's to be based on Gentoo Linux with its current quarterly releases*,
it /would/ seem a multiple of that would be a good idea, and an annual one
sounds like just to big a deal, to much invested.  Thus, I'd propose
a tri-release multiple rather than every other release, for a nine-month
Enterprise release cycle rather than six.  The first three months of the
cycle could then be devoted to mostly supporting upgrades.  The second
three months would be focused on choosing and stabilizing a snapshot. 
This would offer a choice of two normal snapshot versions in case one had
been found to be less than optimal, plus the possibility of an intervening
version of individual packages if necessary.  At the six-month point, a
pre-release (aka Gentoo Enterprise Community) would be produced, which
enterprise users could then start validating, with the full release
(Gentoo Enterprise Official) three months later, incorporating any fixes
necessary during the three month early validation period.  This would also
allow a bit more room for vacations and various other short term breaks of
a month or so, where such might crimp a six-month release cycle (and
certainly /does/ crimp the Gentoo three-month cycle =:^( ).

If this sounds a bit like Mandrake's community/official release policy,
that's no accident.  They found there simply wasn't enough testing of the
beta and rc releases, and after a couple "dud" releases, came up with the
community/official release policy.  Enterprises don't like "dud" releases,
and if we start out with something like this, I think it'll improve the
likelihood of Gentoo getting the reputation for solid releases.

With a nine-month release cycle, that would be four releases every three
years.  If Gentoo Enterprise supported four releases back (five releases
total), that would be four years of actual support, including the three
months of "Community" support for verification.  That should be
comfortably enough beyond the three year general upgrade cycle that even
the conservative corporations should be comfortable with it, as it would
allow for three years of actual use, PLUS a comfortable verification and
conversion time at each end.

That would be comfortably more than the competition (save for Debian)
supports, as well.  OTOH, cutting that to four releases total (three back)
would remain an option, and still be reasonable.
...

* RE: the current quarterly releases:

IMO, these might better be three a year since all they are is snapshots
tested and fit for installation anyway, and don't really affect current
users with Gentoo already installed.  This would give the arch teams and
releng a bit more QC time on the snapshots, and allow more ebuild 
maintenance and development time in between releases, instead of the
constant focus on snapshot release stability, getting one out and having
to immediately start focusing on the next, with little time to focus on
just ebuilds/package quality itself, instead of the larger snapshot
quality, between release snapshots.

Or, to put it another way, it'd allow for a problem AND a vacation, in the
same release window, without crowding out individual package attention
entirely. <g>

For Enterprise, this would change the every third release, nine month
spacing, to every other release, eight month spacing, above, three in two
years, six in a four year life cycle (or five, and remain reasonably over
three years).

Of course, that's just my opinion.  I'm not trying to tilt at windmills,
wasn't yet around for the debate behind the quarterly release decision,
and if the current Gentoo Linux quarterly releases work..

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Revisiting GLEP 19

[Chris Gianelloni]

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

On Thu, 2004-07-22 at 05:00, Duncan wrote:
> Chris Gianelloni posted <1090441261.19552.124.camel@localhost>, excerpted
> below,  on Wed, 21 Jul 2004 16:21:01 -0400:
> 
> > I think 2 a year with a 2 year retention (4 releases) would be the sweet
> > spot.  Nothing keeps users from running older releases, just we don't
> > support them officially any more.
> 
> First, I'm a personal desktop user who migrated to Gentoo in large part
> for its "freshness".  Thus, the very idea of slowing things down seems
> counter to the entire Gentoo thing, here, tho I understand the enterprise
> need, and the appeal of a Gentoo Linux Enterprise.  If it's going to be
> done, in some ways, I think some other name might be more appropriate, tho
> if it's based on Gentoo, the other side says it's entirely appropriate.

Who cares what the name would be right now, since nobody's even agreed
on whether to do it or not... ;]

Personally, I don't like the idea of calling it "Enterprise" at all,
simply because it implies a certain amount of support that I don't
believe that we can provide.  I would think our best naming would simply
be to refer to it by the actual release.  The 2005.0 release would be
"Gentoo Linux 2005.0".  There's no need to add any additional moniker to
the name, especially one that would imply a level of enterprise-class
support, such as that provided by Red Hat, SuSE, or Mandrake to their
enterprise customers.  We won't have somebody that can be called up on
the phone.  We won't have that level of support, so we shouldn't give
anyone the impression that we do.

> Anyway.. I replied here in particular, because I wanted to comment on the
> point quoted.  From my observation of the commercial distribs and their
> reaction to Enterprise, as well as business reaction to their enterprise
> products, both the six month window and the two year window are to short. 

We aren't a commercial distribution.  We can't pretend to be one, nor at
like one.  Instead, we should act as we are, a community-based
distribution of volunteers who strive to release the best product that
we can with the resources we're given.

I'm not sure if I agree with the windows being too short, but I'm not
going to discount it, either.  After all, we're simply discussing here.

> If it's to be based on Gentoo Linux with its current quarterly releases*,
> it /would/ seem a multiple of that would be a good idea, and an annual one
> sounds like just to big a deal, to much invested.  Thus, I'd propose
> a tri-release multiple rather than every other release, for a nine-month
> Enterprise release cycle rather than six.  The first three months of the
> cycle could then be devoted to mostly supporting upgrades.  The second
> three months would be focused on choosing and stabilizing a snapshot. 
> This would offer a choice of two normal snapshot versions in case one had
> been found to be less than optimal, plus the possibility of an intervening
> version of individual packages if necessary.  At the six-month point, a
> pre-release (aka Gentoo Enterprise Community) would be produced, which
> enterprise users could then start validating, with the full release
> (Gentoo Enterprise Official) three months later, incorporating any fixes
> necessary during the three month early validation period.  This would also
> allow a bit more room for vacations and various other short term breaks of
> a month or so, where such might crimp a six-month release cycle (and
> certainly /does/ crimp the Gentoo three-month cycle =:^( ).

I could see a 9-month cycle working.  The *only* problem that I see with
this is that we've now extended the life of software well beyond our
current means, and also well beyond what the original authors intended.

> If this sounds a bit like Mandrake's community/official release policy,
> that's no accident.  They found there simply wasn't enough testing of the
> beta and rc releases, and after a couple "dud" releases, came up with the
> community/official release policy.  Enterprises don't like "dud" releases,
> and if we start out with something like this, I think it'll improve the
> likelihood of Gentoo getting the reputation for solid releases.

We would be less likely to have a "dud" release simply because all of
our release material would come from our -current tree, which is pretty
well tested, and where I believe the bulk of Gentoo's users would
remain.

> With a nine-month release cycle, that would be four releases every three
> years.  If Gentoo Enterprise supported four releases back (five releases
> total), that would be four years of actual support, including the three
> months of "Community" support for verification.  That should be
> comfortably enough beyond the three year general upgrade cycle that even
> the conservative corporations should be comfortable with it, as it would
> allow for three years of actual use, PLUS a comfortable verification and
> conversion time at each end.

Companies will tend to run software whether it is supported or not. 
Since we would not be providing a true commercial support anyway, I'm
not sure that our support cycle would really be that important to a
company.  I think the single biggest factor *currently* with Gentoo
being adopted in the Enterprise (or even much, much smaller shops) is
the lack of stability in our releases, with stability meaning a static
tree.

If we provide a static tree that comes from our already tested and
"stable" branch of our -current tree, we should have fewer bugs in it. 
If in the future, we can grow into providing back-ports and even
commercial-grade support, then great, but we're not there now, and I
honestly don't think we will *ever* get there if we don't take some
action to honestly move in that direction.  It's the whole concept of
taking baby steps... learning to crawl before we can walk.

> That would be comfortably more than the competition (save for Debian)
> supports, as well.  OTOH, cutting that to four releases total (three back)
> would remain an option, and still be reasonable.

I think it has always been the idea to go with 4 total (3 back) simply
due to resources.  I guess I wasn't clear on that before.

> * RE: the current quarterly releases:
> 
> IMO, these might better be three a year since all they are is snapshots
> tested and fit for installation anyway, and don't really affect current
> users with Gentoo already installed.  This would give the arch teams and
> releng a bit more QC time on the snapshots, and allow more ebuild 
> maintenance and development time in between releases, instead of the
> constant focus on snapshot release stability, getting one out and having
> to immediately start focusing on the next, with little time to focus on
> just ebuilds/package quality itself, instead of the larger snapshot
> quality, between release snapshots.

We have a team specifically for the releases.  This team does not focus
on ebuilds at all, but the releases themselves.  It is up to the ebuild
maintainers to work on their ebuilds, as Release Engineering does not
dictate to the maintainers what will be included.  We simply do "what is
ready".  This keeps anyone from rushing something out that just isn't
ready for the users, and also keeps pressure on the maintainers low.  We
are all volunteers, after all, and working with Gentoo can be stressful
enough for some of us.

> Or, to put it another way, it'd allow for a problem AND a vacation, in the
> same release window, without crowding out individual package attention
> entirely. <g>

With our current system, if there's a big "problem", then we simply
don't upgrade to the problem package(s) and stick with what worked.  If
the xfree/xorg guys decided to take a vacation for a release, it
wouldn't kill us, as we have a perfectly working set from the last
release.

> For Enterprise, this would change the every third release, nine month
> spacing, to every other release, eight month spacing, above, three in two
> years, six in a four year life cycle (or five, and remain reasonably over
> three years).
> 
> Of course, that's just my opinion.  I'm not trying to tilt at windmills,
> wasn't yet around for the debate behind the quarterly release decision,
> and if the current Gentoo Linux quarterly releases work..

The current release cycle seems to work.  My original proposal was to
start by keeping our current cycle, simply because it has seemed to work
for our normal releases.  Now we're talking about the introduction of a
major change to Gentoo that affects our releases.  I'm a big fan of only
making one big change at a time.  If we find it too hard to work within
the constraints of our quarterly release cycle, then we get together and
discuss a way to make it better.  Right now, "it ain't broke", so we
don't want to fix it... *grin*

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

Is your power animal a penguin?

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

Re: [gentoo-dev] Revisiting GLEP 19

[Stuart Herbert]

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

On Tuesday 20 July 2004 14:14, Kurt Lieber wrote:
> So, with that said, thoughts, comments and other ideas are welcome.

I think we'll end up moving the ChangeLogs over to an XML format as part of 
this work.  This will make it easier to write tools that can filter updates 
based on security alerts and bug fixes.  

Just imagine being able to do:

emerge --show-summaries -u world

and being able to get a list of bugs and security problems fixed by the 
prospective upgrades, with links to the relevant entries in Bugzilla.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
                                                   http://stu.gnqs.org/diary/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] Revisiting GLEP 19

[Daniel Ostrow]

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

Stuart:

Good to know you and I are thinking on the same page :)

Dan

Stuart Herbert wrote:
| On Tuesday 20 July 2004 14:14, Kurt Lieber wrote:
|
|>So, with that said, thoughts, comments and other ideas are welcome.
|
|
| I think we'll end up moving the ChangeLogs over to an XML format as
part of
| this work.  This will make it easier to write tools that can filter
updates
| based on security alerts and bug fixes.
|
| Just imagine being able to do:
|
| emerge --show-summaries -u world
|
| and being able to get a list of bugs and security problems fixed by the
| prospective upgrades, with links to the relevant entries in Bugzilla.
|
| Best regards,
| Stu

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA/mfpsb0gXCN8LgURAuJYAKCL94pl8mnpwTSDhBtQR7aXq2yzUgCg4joR
wtvFpAlYmu9ELWwldGGQ+WA=
=HV03
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Toby Dickenson]

On Wednesday 21 July 2004 13:39, Stuart Herbert wrote:
> On Tuesday 20 July 2004 14:14, Kurt Lieber wrote:
> > So, with that said, thoughts, comments and other ideas are welcome.
> 
> I think we'll end up moving the ChangeLogs over to an XML format as part of 
> this work.  This will make it easier to write tools that can filter updates 
> based on security alerts and bug fixes.  
> 
> Just imagine being able to do:
> 
> emerge --show-summaries -u world
> 
> and being able to get a list of bugs and security problems fixed by the 
> prospective upgrades, with links to the relevant entries in Bugzilla.

No need for imagination here.... you can do much of that today with:

emerge --changelog -p -u world

That sniffs the current Changelog file, and occasionally picks up information 
about more revisions than it really should. An easily parsed format for 
changelogs containing extra change metadata would definitely be nice.

-- 
Toby Dickenson

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Stuart Herbert]

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

On Wednesday 21 July 2004 13:58, Toby Dickenson wrote:
> No need for imagination here.... you can do much of that today with:
>
> emerge --changelog -p -u world

An XML-based ChangeLog adds semantic meaning, making it much more useful.  
It's not too difficult for (most ;-) humans to make sense of our current 
ChangeLogs, but tools are always going to be limited in accuracy and 
capability.

There's also the added side-effect that it would make validating the ChangeLog 
very straight forward through a simple XML Schema.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
                                                   http://stu.gnqs.org/diary/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] Revisiting GLEP 19

[Jason Wever]

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

On Wed, 21 Jul 2004, Stuart Herbert wrote:

> On Wednesday 21 July 2004 13:58, Toby Dickenson wrote:
> > No need for imagination here.... you can do much of that today with:
> >
> > emerge --changelog -p -u world
> 
> An XML-based ChangeLog adds semantic meaning, making it much more useful.  
> It's not too difficult for (most ;-) humans to make sense of our current 
> ChangeLogs, but tools are always going to be limited in accuracy and 
> capability.
> 
> There's also the added side-effect that it would make validating the ChangeLog 
> very straight forward through a simple XML Schema.

I personally would very much like to leave ChangeLogs as they are.  We 
already have tools to make sure they are in the right format (though 
repoman doesn't check for it and yes developers can choose not to use 
these tools).  I think changing them over to XML would be 
more overhead in file size and in required tools to parse them than is 
really necessary.  If the problem is that people can't follow directions, 
then don't punish those of us who do.

Additionally XML is not (despite what many developers may think) easily 
human readable to those who don't understand how markup languages 
generically work.  And even to some of us that know how, it's still (for 
lack of a better phrase) a royal PITA.

While if this was solely a community of developers or technically savvy 
people, then perhaps using XML-based ChangeLogs would be OK.  However 
it isn't  and I think that would be a poor assumption on our part.  Yes 
you could make a tool to make it human readable, but again that's more 
overhead you do not need if you can get developers to correctly input 
their ChangeLog entries now.

Considering the file "ChangeLog" in an of itself is almost an unofficial 
standard that assumes a plain text document, should such a decision be 
made to go with XML-based ChangeLogs, perhaps we should give them another 
name.


But yeah, that's my $0.02/rant 'n' rave.
- -- 
Jason Wever
Gentoo/Sparc Co-Team Lead
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD4DBQFA/nLndKvgdVioq28RAstZAJi6VfQX34lTgrfDsoEbU+x2c6kOAKCX80DK
jg9FctPiw7OSTQzLHCVMxQ==
=7BAm
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Carsten Lohrke]

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

On Wednesday 21 July 2004 15:43, Jason Wever wrote:
> Additionally XML is not (despite what many developers may think) easily
> human readable to those who don't understand how markup languages
> generically work.  And even to some of us that know how, it's still (for
> lack of a better phrase) a royal PITA.
It's not the problem to write something that spits out a plain text version. 
What I'm more interested in, is a speedy workflow: echangelog, "this 
changed", ready - but being obliged to fill in a xml form!?


Carsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA/oH5VwbzmvGLSW8RApqyAJ4tXDT4EakrXzu6s5QoA/xsFrYuYgCfSaj+
jZNs0pm3My6gc9G2V+Tqi88=
=GeQl
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Stuart Herbert]

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

On Wednesday 21 July 2004 15:47, Carsten Lohrke wrote:
> It's not the problem to write something that spits out a plain text
> version. What I'm more interested in, is a speedy workflow: echangelog,
> "this changed", ready - but being obliged to fill in a xml form!?

If we're serious about offering a viable 'fixes-only' tree, we need to be able 
to give better information to our users.  As much as I hate to admit it, an 
XML-based ChangeLog format would be a big step towards that, and if designed 
right it shouldn't be too much trouble to update.  For devs who really hate 
using XML, we could always turn echangelog into a simple form-filling tool to 
walk people through filling out a changelog entry.

Think of it this way.  Good change information, like good QA, is something 
that is part of the professional behaviour reasonably expected of a software 
engineer.  

We've been using XML-based ChangeLogs where I work for over six months now, 
and both staff and customers have found them to be more useful than 
plain-text ChangeLogs.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
                                                   http://stu.gnqs.org/diary/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] Revisiting GLEP 19

[Georgi Georgiev]

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

maillog: 21/07/2004-16:08:09(+0100): Stuart Herbert types
> We've been using XML-based ChangeLogs where I work for over six months now, 
> and both staff and customers have found them to be more useful than 
> plain-text ChangeLogs.

If it is worth anything, I personally find the Changelogs in the portage tree
very hard to read:

- listing lots of filenames on one line clutters the entry and makes it hard to
  distinguish if there is anything of interest on the line
- the filenames of affected ebuilds start after the name of the author of the
  entry, which very often changes the position of the filename and makes it
  hard to jump from entry to entry
- the syntax is not what other packages use, or at least neither vim nor xemacs
  highlight it properly (same goes for the kernel changelog, but at least it is
  readable; removing the indent makes for a better highlighting)
- if there are multiple changes in a single entry, they are hard to
  distringuish because all the text is just thrown there

In case I am way out of line, accept my apologies, because I didn't follow the
thread.

-- 
*)   Georgi Georgiev   *) Don't steal; thou'lt never thus compete      *)
(*    chutz@gg3.net    (* successfully in business. Cheat. --          (*
*)  +81(90)6266-1163   *) Ambrose Bierce                               *)

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

Re: [gentoo-dev] Revisiting GLEP 19

[Ciaran McCreesh]

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

On Thu, 22 Jul 2004 00:45:34 +0900 Georgi Georgiev <chutz@gg3.net>
wrote:
| - the syntax is not what other packages use, or at least neither vim
| nor xemacs
|   highlight it properly (same goes for the kernel changelog, but at
|   least it is readable; removing the indent makes for a better
|   highlighting)

That at least is easily fixable. Aron and I have been idly talking about
fixing vim to like Gentoo changelogs for a while now, but we've never
quite gotten around to it :)

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Revisiting GLEP 19

[Carsten Lohrke]

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

On Wednesday 21 July 2004 17:08, Stuart Herbert wrote:
>For devs who
> really hate using XML, we could always turn echangelog into a simple
> form-filling tool to walk people through filling out a changelog entry.

I implied this. I won't edit such xml files by hand on a regular basis. Even 
with such a tool it will need quite a bit more time, depending on what you 
want to put in these xml files. Regarding security vs bugfixes: For security 
we have glsa-check already and important bugfixes are handled via a marked 
stable -rX, so I don't see the problem here, beside that there is no 
extensive information given, which someone would need to write.

I mean, we are not even able to fix all the metadata.xml files. A lot are 
simply missing, a lot name retired devs* as maintainer and quite a few list 
bug-wranglers or no-herd in it. Unless we do not have more developers it is 
not a good idea to force more overhead on us as necessary.

*devrel isn't even able to provide a complete list of retired devs


Carsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA/qS2VwbzmvGLSW8RAmVTAJ4oRql7ab45p0mIE4/pjgZy7CTIXACgjxE+
w+pfMbDLPPbfRjRge/3VR10=
=LFmP
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Andrew Cowie]

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

On Wed, 2004-07-21 at 16:08 +0100, Stuart Herbert wrote:
> Think of it this way.  Good change information, like good QA, is something 
> that is part of the professional behaviour reasonably expected of a software 
> engineer.

Someone else alluded to this, and I'd just like to reinforce the point:
in terms of assessing the risk of a potential upgrade, some sense of
what has changed is necessary.

Unfortunately, the typical ChangeLog in portage is:

  18 Feb 2004; David Holm <dholm@gentoo.org> db-4.2.52_p1.ebuild:
  Added to ~ppc.

and

  *evolution-1.4.6 (22 Mar 2004)

  22 Mar 2004; Alastair Tse <liquidx@gentoo.org> evolution-1.4.6.ebuild:
  version bump

the trouble is especially evident in the second example. What are the
changes between evo 1.4.5 and evo 1.4.6?

That, of course, is answered by the contents of the upstream ChangeLog,
which there usually is one. In this case it is:

  http://developer.ximian.com/projects/evolution/release_notes/1.4.6.html

Which is actually what I, in an enterprise deployment manager role, need
to know about before I can make an upgrade decision. The stuff about
arches being marked stable, etc, is, while internally important, not
terribly interesting compared to this.

It would be fantastic if we can find a way to include such information.
After all, the developer doing the version bump (or better yet, the user
making the bug report) probably at least had a look at the changes list,
where ever it is to be found. That information should at least be
hyperlinked, and, far better - (especially if we're switching to an XML
format) included in Gentoo's ChangeLogs.

Cheers,

AfC

-- 
Andrew Frederick Cowie

OPERATIONAL DYNAMICS
Operations Consultants and Infrastructure Engineers

http://www.operationaldynamics.com/

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

Re: [gentoo-dev] Revisiting GLEP 19

[Chris Gianelloni]

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

On Wed, 2004-07-21 at 10:47, Carsten Lohrke wrote:
> It's not the problem to write something that spits out a plain text version. 
> What I'm more interested in, is a speedy workflow: echangelog, "this 
> changed", ready - but being obliged to fill in a xml form!?

What makes you think you would have to fill it out manually?  Why
couldn't using: echangelog "I changed this to fix bug #69" simply do the
XML for you?  Is there a reason why you think it couldn't?  It might
change slightly, but I don't see that things would go to hand-writing
xml any time soon.

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

Is your power animal a penguin?

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

Re: [gentoo-dev] Revisiting GLEP 19

[Carsten Lohrke]

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

On Wednesday 21 July 2004 22:51, Chris Gianelloni wrote:
> What makes you think you would have to fill it out manually?  Why
> couldn't using: echangelog "I changed this to fix bug #69" simply do the
> XML for you?  Is there a reason why you think it couldn't?  It might
> change slightly, but I don't see that things would go to hand-writing
> xml any time soon.

I never assumed to write xml by hand - Stuarts email sound a bit like it - but 
even "field1"<enter>, "field2"<enter>, ... would be annoying. If echangelog 
would be smart and parse the input, that would be ok. Maybe I got it wrong, 
but I was under the impression that there would be at least one new field be 
introduced, indicating the importance of a bug fix; And a increasing number 
of fields wouldn't make parsing input simpler. If using xml doesn't 
complicate writing the ChangeLog I'm all for it.


Carsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA/5hXVwbzmvGLSW8RAvx/AKCbtRwzCnQIM6s61rcpHawNx/gpSQCdHlpP
Fv00d3oZiBaQOulj3zEk5ts=
=4D8R
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Chris Gianelloni]

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

On Thu, 2004-07-22 at 06:34, Carsten Lohrke wrote:
> I never assumed to write xml by hand - Stuarts email sound a bit like it - but 
> even "field1"<enter>, "field2"<enter>, ... would be annoying. If echangelog 
> would be smart and parse the input, that would be ok. Maybe I got it wrong, 
> but I was under the impression that there would be at least one new field be 
> introduced, indicating the importance of a bug fix; And a increasing number 
> of fields wouldn't make parsing input simpler. If using xml doesn't 
> complicate writing the ChangeLog I'm all for it.

What about something like:

echangelog <text> <bug> <foo> <bar>

Then you make echangelog a bit smart.  You could use it in several ways.

echangelog "text here" for changes that are made without a bug attached
or any additional information.

echangelog "text here" "69" for changes that are made to close bug #69.

But what if you want to enter <foo> but not a bug?  Then you would use
echangelog "text here" "" "foo" (just an idea).

All of this would keep echangelog from getting too complex, while still
giving it flexibility.  Any better ideas are definitely welcome... =]

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

Is your power animal a penguin?

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

Re: [gentoo-dev] Revisiting GLEP 19

[Carsten Lohrke]

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

On Thursday 22 July 2004 15:06, Chris Gianelloni wrote:
> What about something like:
>
> echangelog <text> <bug> <foo> <bar>

These are fields, separated by spaces, too. What about when I type (take in 
account my second nick name is typo):

echangelog had to touch this <beeep> ebuild the 4 th time because of 
continuing problems with bug 0815 and 4711 - thanks to joe helpful et al

How does echangelog know which of these numbers refer to bug reports?


Carsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBAR4yVwbzmvGLSW8RAk5gAJ4yyplSLuzWrDlo1q0Y/Vjxi+ecjQCfUmBz
MBVVrRcOcFBd0+oq2tzVDCU=
=l/Jx
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Chris Gianelloni]

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

On Fri, 2004-07-23 at 10:18, Carsten Lohrke wrote:
> > echangelog <text> <bug> <foo> <bar>
> 
> These are fields, separated by spaces, too. What about when I type (take in 
> account my second nick name is typo):
> 
> echangelog had to touch this <beeep> ebuild the 4 th time because of 
> continuing problems with bug 0815 and 4711 - thanks to joe helpful et al
> 
> How does echangelog know which of these numbers refer to bug reports?

Actually, it would throw an error to begin with since you're not using
the desired input format.

You would need to input something like:

echangelog "had to touch this <beeep> ebuild the 4 th time because of
continuing problems with bug 0815 and 4711" "815 4711" "joe helpful"

It would take the bugs from the "bugs" field.  It shouldn't parse the
text field at all.  That's the whole point that I think everyone is
trying to make with xml'izing the ChangeLog.  Instead, you would do
something more like this:

echangelog "Modified src_unpack to add the fix-bug-0815.patch and also
the fix-bug-4711.patch to the ebuild" "815 4711" "Joe Helpful, Johnny
Patchmaker, Bob User"

...and of course, anything but the first field is optional, so for most
changes, nothing would change as far as the developer is concerned.  The
whole point is to *allow* for better data handling, not to force more
work on every developer.

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

Is your power animal a penguin?

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

Re: [gentoo-dev] Revisiting GLEP 19

[aeriksson]

weeve@gentoo.org said:
> I personally would very much like to leave ChangeLogs as they are.
> We  already have tools to make sure they are in the right format
> (though  repoman doesn't check for it and yes developers can choose
> not to use  these tools).  I think changing them over to XML would
> be  more overhead in file size and in required tools to parse them
> than is  really necessary.  If the problem is that people can't
> follow directions,  then don't punish those of us who do. 

I second that feeling. If what we're trying to achieve is to have a
way to signal to the sysadmins that a security update is present, why
not just add a [S] entry to 'emerge -pv'? That way the community
packaging gentoo can stay on step with the development of the upstream
project (low cost), and the sysadmin was to decide (and take the cost)
for doing the upgrade of his installed packages with security holes.

Doing this would put some stress on the ability to run different
packages from different eras together on the same box. The flexible
dependency system we have today _should_ prove useful to make that
happen, and if there are packages with too tight requirements on
versions of other packages it uses, we should bring that issue up with
the upstream project. Taking it upon ourselves to do backports etc is
just to costly, imho.

/A


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Stuart Herbert]

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

On Wednesday 21 July 2004 16:25, aeriksson@fastmail.fm wrote:
> I second that feeling. If what we're trying to achieve is to have a
> way to signal to the sysadmins that a security update is present, why
> not just add a [S] entry to 'emerge -pv'? 

Two things.  First off, I'd hope to achieve a lot more than just adding a [S] 
entry to emerge -pv.

Secondly, where do you think Portage will get the information from to decide 
whether or not to add the [S]?  Right now, the design of the glsa toolset is 
to bolt this information onto the side.  With XML-based changelogs, the 
information could be stored where it belongs - in the list of what has 
changed and why.

> That way the community 
> packaging gentoo can stay on step with the development of the upstream
> project (low cost), and the sysadmin was to decide (and take the cost)
> for doing the upgrade of his installed packages with security holes.

Done well (ie, providing a tool so that devs don't *have* to hack XML files by 
hand), XML Changelogs should add no extra cost.  They would also make 
third-party GUIs like Porthole and packages.gentoo.org much simpler to write 
and maintain.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
                                                   http://stu.gnqs.org/diary/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] Revisiting GLEP 19

[aeriksson]

> On Wednesday 21 July 2004 16:25, aeriksson@fastmail.fm wrote:
> > I second that feeling. If what we're trying to achieve is to have a
> > way to signal to the sysadmins that a security update is present, why
> > not just add a [S] entry to 'emerge -pv'?
> 
> Two things.  First off, I'd hope to achieve a lot more than just adding a 
> [S] entry to emerge -pv.

Care to elaborate? "It's nifty for the future" is a bad argument. Far
too many times have I came across people who thinks all problems goes
away if the solution is implemented using xml (I'm NOT saying you're
one of them). Present the problems you want to fix, and we'll discuss
them.


>> Secondly, where do you think Portage will get the information from
>> to decide whether or not to add the [S]?  Right now, the design of 
the
>> glsa toolset is to bolt this information onto the side.  With 
XML-based
>> changelogs, the information could be stored where it belongs - in 
the
>> list of what has changed and why.
 

Why not add that bit of info the the ebuild which incorporates the
fix? "SECURITYFIX=url1 url2 http://www.gentoo.org/GLSA1234whatever"
would be all need. 

For a sysadmin who's not into updating every day for the fun of it,
the stream of new ebuilds _with_ SECURITYFIX clauses would constitute
'vertual dependecies" he like to depend on. So from his pow, it's
legit ebuild information. Or put the other way around, why not move
all the other headers in ebuilds to xml, and use xml-aware tools to
execute on them? (joke)

BR,

/Anders



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Stuart Herbert]

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

On Wednesday 21 July 2004 17:34, aeriksson@fastmail.fm wrote:
> > Two things.  First off, I'd hope to achieve a lot more than just adding a
> > [S] entry to emerge -pv.
>
> Care to elaborate? "It's nifty for the future" is a bad argument. Far
> too many times have I came across people who thinks all problems goes
> away if the solution is implemented using xml (I'm NOT saying you're
> one of them). Present the problems you want to fix, and we'll discuss
> them.

Let's deal with the XML vs plain text argument first.

I'm not an XML-everywhere person, but I do believe that XML is *the* right 
technology when you want to add meaning to structured data - meaning that can 
be re-used in software tools.  It's nowhere near as difficult to use as 
ASN.1, not as clumbsy as the plain-text markups in common-use, and if you do 
read the raw XML in a text editor, most people can follow what the file says.

You *can* do everything I'm suggesting below using a plain text file - 
provided everyone follows the same conventions.  You might even be successful 
in getting everyone to keep to the conventions.  But using XML for the job 
gives your tool-writers instant access to rich libraries for parsing, 
manipulating, and verifying the data.  These libraries are available to 
programmers in all the major languages (except bash alas ... perhaps it's 
time for someone to change that? ;-)  Tools that work on XML data are much 
easier to write, and much easier to maintain.

Our changelogs are supposed to contain the following information:

- package version affected
- list of changed files
- reason for change
- bug(s) addressed by the change (inc security issues announced through GLSAs)
- developer who made the change
- user(s) who originally suggested the change (credit for patches, ebuilds, 
and the like)

Let's look at what we could do with this sort of data.

Now, if I'm reading a changelog, if I want to see what issues are fixed, the 
changelog isn't normally enough.  Why?  Because it's very common for the 
changelog to only contain a bug number and not a description.  Normally, you 
have to open up a browser, and search for each bug in turn on 
bugs.gentoo.org.  It's not exactly hard work, but we could make a better 
experience.

There's no reason why the changelog couldn't contain both the bug id and the 
summary line from bugzilla.  There's no reason why a GUI tool like Porthole - 
or even the command-line based emerge - couldn't provide you with a [more] 
link to go and get the full discussion from bugzilla.  Instead of unconnected 
data stored in different places, we now have connected data and a means to 
connect them.  That idea - of making it possible for tools to connect the 
data - of making it possible for the tools to understand the data - is where 
the real value of XML lies.

If we were really wanting to take this further, for those packages that 
provide a list of upstream bugs that are fixed in a release, we could store 
that list in the changelogs too, with summaries and click-throughs.  That's a 
bit more work, and not everyone's idea of fun, but it could be done.  At the 
very least we could provide a link to the upstream changelog.

That's just looking at one aspect of bugs and changes.  Being able to say 
whether a bug fix is security-related or not is another aspect.  That's just 
another type of change information.  It shouldn't have to be stored and 
treated as a special case - which is where the glsa-check tool seems to be 
going.

Let's look at the reasons why a new version of a package is added to Portage.  
I believe 'version bump' will prove the most popular in our changelogs right 
now.  Is it to address serious bugs?  Is it for security reasons?  We could 
standardise that into a choice of one or more reasons.  That's information 
that can then be used by GUIs such as Porthole and packages.gentoo.org.  
That's information that users could search on.  

Where is the upstream changelog?  Something else that can be added.  If you 
write your tools correctly, you can introduce new types of information into 
your XML data without having to change your tools.

I'm in the information business.  I work on publishing tools for developers.  
I work on a CMS tool (yes, it's XML based).  I write about my work.  I work 
with information probably more than I work with code.  Most information just 
doesn't exist in isolation.  Most information is really just information 
about yet more information, information that people don't read because it 
isn't served to them on a plate.

It's not about getting left behind.  I didn't buy that argument during the 
dotcom boom, and I definitely don't buy it now.  What it's about is making a 
lot more of what we already have, by making it more available.  To make it 
more available to people, you have to make it more available to the tools 
first.

I'm not looking for problems to fix.  "It ain't broke, so don't fix it" isn't 
always the best advice.  Sometimes, the thing to do is to look at what is 
possible, rather than just accept what you're stuck with today.

Now, maybe this information should be part of the metadata for an ebuild 
instead of being in a 'ChangeLog' - as Weeve was aluding to earlier in this 
thread.  From an SCM point of view, it's all configuration information 
related to a change, whether you want to call it a 'ChangeLog' or 
'metadata.xml' file or whatever.

> Why not add that bit of info the the ebuild which incorporates the
> fix? "SECURITYFIX=url1 url2 http://www.gentoo.org/GLSA1234whatever"
> would be all need.

That's one way to do it.  Build another special case into ebuilds and into 
Portage.  It'll work.  But if the information was somewhere in XML, it'd be 
an easier change to introduce.  All you'd have to do would be to update an 
XML schema.  You shouldn't have to update tools.

> Or put the other way around, why not move
> all the other headers in ebuilds to xml, and use xml-aware tools to
> execute on them? (joke)

That's a topic that keeps cropping up.  If you look at our GLEPs, there's one 
currently open with people chomping at the bit to make that happen, at least 
for some of the information.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
                                                   http://stu.gnqs.org/diary/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] Revisiting GLEP 19

[Marius Mauch]

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

On 07/21/04  Stuart Herbert wrote:

> On Wednesday 21 July 2004 17:34, aeriksson@fastmail.fm wrote:
> > > Two things.  First off, I'd hope to achieve a lot more than just
> > > adding a[S] entry to emerge -pv.
> >
> > Care to elaborate? "It's nifty for the future" is a bad argument.
> > Far too many times have I came across people who thinks all problems
> > goes away if the solution is implemented using xml (I'm NOT saying
> > you're one of them). Present the problems you want to fix, and we'll
> > discuss them.
> 
> Let's deal with the XML vs plain text argument first.
> 
> I'm not an XML-everywhere person, but I do believe that XML is *the*
> right technology when you want to add meaning to structured data -
> meaning that can be re-used in software tools.  It's nowhere near as
> difficult to use as ASN.1, not as clumbsy as the plain-text markups in
> common-use, and if you do read the raw XML in a text editor, most
> people can follow what the file says.

I'm not completely opposed to XML although I see little use here, but I
see the big show stopper: Transition. We have a live tree as well as a
dozen tools (estimated) using the Changelogs, some of them aren't even
under our control (gentoo-portage.com and porthole are popular
examples). How do you plan to change the format in such an environment?
Without an answer to that question the whole issue is academic.

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: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Revisiting GLEP 19

[Donnie Berkholz]

Marius Mauch said:
> I'm not completely opposed to XML although I see little use here, but I
> see the big show stopper: Transition. We have a live tree as well as a
> dozen tools (estimated) using the Changelogs, some of them aren't even
> under our control (gentoo-portage.com and porthole are popular
> examples). How do you plan to change the format in such an environment?
> Without an answer to that question the whole issue is academic.

Wouldn't a new file called ChangeLog.xml solve this? If it exists, use it.
If not, default to the old plain-text ChangeLog.



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Marius Mauch]

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

On 07/21/04  Donnie Berkholz wrote:

> Marius Mauch said:
> > I'm not completely opposed to XML although I see little use here,
> > but I see the big show stopper: Transition. We have a live tree as
> > well as a dozen tools (estimated) using the Changelogs, some of them
> > aren't even under our control (gentoo-portage.com and porthole are
> > popular examples). How do you plan to change the format in such an
> > environment? Without an answer to that question the whole issue is
> > academic.
> 
> Wouldn't a new file called ChangeLog.xml solve this? If it exists, use
> it. If not, default to the old plain-text ChangeLog.

Not really. 
How do you make sure a dev adds new entries the XML version if it
exists? (in the case of multiple/no maintainers or arch maintainers)
Tools would have to merge the logs internally to be useful.
Supporting both formats will be a real PITA.

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: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Revisiting GLEP 19

[Donnie Berkholz]

Marius Mauch said:
> On 07/21/04  Donnie Berkholz wrote:
>> Wouldn't a new file called ChangeLog.xml solve this? If it exists, use
>> it. If not, default to the old plain-text ChangeLog.
>
> Not really.
> How do you make sure a dev adds new entries the XML version if it
> exists? (in the case of multiple/no maintainers or arch maintainers)
> Tools would have to merge the logs internally to be useful.
> Supporting both formats will be a real PITA.

Only allow one of the two to exist for a given package. We'd need a tool
to migrate, echangelog would need to get smarter (as already mentioned)
and repoman would need to enforce this. Could provide a way to
autogenerate a plain-text ChangeLog from a ChangeLog.xml also.



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Chris Gianelloni]

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

On Wed, 2004-07-21 at 20:24, Marius Mauch wrote:
> > Wouldn't a new file called ChangeLog.xml solve this? If it exists, use
> > it. If not, default to the old plain-text ChangeLog.
> 
> Not really. 
> How do you make sure a dev adds new entries the XML version if it
> exists? (in the case of multiple/no maintainers or arch maintainers)
> Tools would have to merge the logs internally to be useful.
> Supporting both formats will be a real PITA.

You design your layout for the new ChangeLog.xml, extend echangelog to
support the new style, then add it to gentoolkit-dev and bump.  As
people start using it, it outputs *both* style ChangeLog files, until
such time that we've gone through and cleaned up the tree (or a set
deadline, whatever we decide), then you remove the "old" style
functionality from the tool.  Now it only outputs the new XML
ChangeLog.xml and it's all done.

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

Is your power animal a penguin?

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

Re: [gentoo-dev] Revisiting GLEP 19

[Chris Gianelloni]

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

On Wed, 2004-07-21 at 18:55, Marius Mauch wrote:
> I'm not completely opposed to XML although I see little use here, but I
> see the big show stopper: Transition. We have a live tree as well as a
> dozen tools (estimated) using the Changelogs, some of them aren't even
> under our control (gentoo-portage.com and porthole are popular
> examples). How do you plan to change the format in such an environment?
> Without an answer to that question the whole issue is academic.

Use the -release trees...  "For 2005.0, we've decided to switch to an
XML-based ChangeLog system.  The -current tree will continue to have
both styles of ChangeLogs, with the plain-text ChangeLog being
depracated, until 2005.1 is released, at which time the plain-text
ChangeLog will be dropped from the -current tree in favor of the new
XML-based format."

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

Is your power animal a penguin?

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

Re: [gentoo-dev] Revisiting GLEP 19

[Lina Pezzella]

aeriksson@fastmail.fm wrote:

>
>weeve@gentoo.org said:
>  
>
>>I personally would very much like to leave ChangeLogs as they are.
>>We  already have tools to make sure they are in the right format
>>(though  repoman doesn't check for it and yes developers can choose
>>not to use  these tools).  I think changing them over to XML would
>>be  more overhead in file size and in required tools to parse them
>>than is  really necessary.  If the problem is that people can't
>>follow directions,  then don't punish those of us who do. 
>>    
>>
>
>I second that feeling. If what we're trying to achieve is to have a
>way to signal to the sysadmins that a security update is present, why
>not just add a [S] entry to 'emerge -pv'? That way the community
>packaging gentoo can stay on step with the development of the upstream
>project (low cost), and the sysadmin was to decide (and take the cost)
>for doing the upgrade of his installed packages with security holes.
>
>Doing this would put some stress on the ability to run different
>packages from different eras together on the same box. The flexible
>dependency system we have today _should_ prove useful to make that
>happen, and if there are packages with too tight requirements on
>versions of other packages it uses, we should bring that issue up with
>the upstream project. Taking it upon ourselves to do backports etc is
>just to costly, imho.
>
>/A
>
>
>--
>gentoo-dev@gentoo.org mailing list
>
>  
>
I agree completely with this suggestion.  Personally at my workplace, my 
boss was considering going with debian because you could specify to only 
update for security reasons (through only placing security repositories 
in sources.list).  Fortunately for me, he had a few bad experiences with 
debian developers and went with gentoo despite the lack of the 
security-updates-only option.  Adding an [S] option to emerge -pv would 
certainly make our lives easier here, and at many corporations who don't 
see the need to update regularly.

-j4

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Dylan Carlson]

On Wednesday 21 July 2004 11:38 am, Lina Pezzella wrote:

> I agree completely with this suggestion.  Personally at my workplace, my
> boss was considering going with debian because you could specify to only
> update for security reasons (through only placing security repositories
> in sources.list).  Fortunately for me, he had a few bad experiences with
> debian developers and went with gentoo despite the lack of the
> security-updates-only option.  Adding an [S] option to emerge -pv would
> certainly make our lives easier here, and at many corporations who don't
> see the need to update regularly.
>

Friends, making Gentoo enterprise-ready is bigger in scope than just 
handling security updates.  If all you want to do is to check for security 
updates, merge gentoolkit and use 'glsa-check'.

It would be good to clarify what the goals are here, and what the specific 
issues are that need addressing.

For the many of the IT shops who need more than a way to isolate security 
updates, I'll try to summarize with one word (I think) fits:  predictable.   
That means:

- knowing what each release contains (in detail, with version #s)
- understanding what pkgs will get enhancements, and which ones will only 
get security updates & major bugfixes.
- having enough information to know what a change specifically contains
- a regular, time-based release schedule (such as every six months); thus 
an organization can time & plan its infrastructure changes with expected 
OS updates.
- knowing that Gentoo does regression testing of security updates & major 
bugfixes back through old (but supported) releases before committing.

... and etc, etc.  This isn't a quick tweak to 'emerge', or a gentoolkit 
utility.  I wish it were that simple.  It involves improving Gentoo's 
practices and procedures, as well as enhancing portage to accommodate the 
necessary functions an enterprise customer receives currently with other 
operating systems, and expects ... (short of having paid commercial 
support).

There are some things we can do-- because of Portage itself-- that set us 
apart from other distributions.   Minimize the need for paid support.  
That should be, IMO, the underlying goal of this effort -- to give the 
users the enterprise tools they need to be self-reliant (i.e., not shoot 
one's self in the foot).

Beyond that we need to start looking helping sites with large numbers of 
Gentoo machines with deployment and administration tools.  No need to 
write our own stuff, the tools are already out there.  We just need to 
package and integrate them with how we do things in Gentoo, and write 
enough supporting documentation.

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

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[FRLinux]

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

On Wed, 2004-07-21 at 17:26, Dylan Carlson wrote:
> Friends, making Gentoo enterprise-ready is bigger in scope than just 
> handling security updates.  If all you want to do is to check for security 
> updates, merge gentoolkit and use 'glsa-check'.

agreed but still, having such a feature straight on emerge is nice, i've
gone the debian way mainly because of this.

> - understanding what pkgs will get enhancements, and which ones will only 
> get security updates & major bugfixes.

Both aree important to me. I have a small environment of Debian boxes,
about 10 Debian servers (ranging from woody to sarge) and about 15
Debian workstations all using sarge (but the latter is out of scope in
this discussion). Knowing that without reinstalling, i could install
much more recent (but still stable) software would be a nice added
value.

> - knowing that Gentoo does regression testing of security updates & major 
> bugfixes back through old (but supported) releases before committing.

Does this mean that security updates will take longer to get into the
server version of gentoo ?

I'll be following that GLEP and see what can be done, i'm willing to
dedicate some time on helping that project to see the light :)

Steph
-- 
This mail was sent under Gentoo 2004.1 - Gnome & Kernel 2.6nptl
http://frlinux.net - Site d'aide aux Debutants sous Linux
Public key : http://frlinux.net/files/frlinux_public_key.asc

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

Re: [gentoo-dev] Revisiting GLEP 19

[Christian Birchinger]

On Wed, Jul 21, 2004 at 02:15:45PM +0100, Stuart Herbert wrote:
> On Wednesday 21 July 2004 13:58, Toby Dickenson wrote:
> > No need for imagination here.... you can do much of that today with:
> >
> > emerge --changelog -p -u world
> 
> An XML-based ChangeLog adds semantic meaning, making it much more useful.  
> It's not too difficult for (most ;-) humans to make sense of our current 
> ChangeLogs, but tools are always going to be limited in accuracy and 
> capability.

And i don't think XML was invented to be edited by a human. It's
a format which gets created an changed by programms. It's a pain
for people no matter how cool the syntax highliting might be.
 
> There's also the added side-effect that it would make validating the ChangeLog 
> very straight forward through a simple XML Schema.

XML is fine as long as i don't have to edit it by hand. Almost
every other format is nice to handle by people with normal
editors. And reading is even worse. Now you a tool to read a
Changelog. Ok, maybe i'm the last person which prefers to read
such things with less or cat or whatever.

Metadata is acceptable it's almost only used by apps which parse
it. But a Changelog is something people read with a pager or
editor. I'm no fan of using tools for simple stuff like reading
logs.


Christian

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Revisiting GLEP 19

[Chris Gianelloni]

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

On Wed, 2004-07-21 at 08:39, Stuart Herbert wrote:
> I think we'll end up moving the ChangeLogs over to an XML format as part of 
> this work.  This will make it easier to write tools that can filter updates 
> based on security alerts and bug fixes.  
> 
> Just imagine being able to do:
> 
> emerge --show-summaries -u world
> 
> and being able to get a list of bugs and security problems fixed by the 
> prospective upgrades, with links to the relevant entries in Bugzilla.

I love that idea.  The only problem I see is the need to add xml-parsing
ability to portage, but the QA tool that was posted to this list a while
back and the metadata xml parser, shows that it isn't impossible.

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

Is your power animal a penguin?

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

Re: [gentoo-dev] Revisiting GLEP 19

[Stuart Herbert]

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

On Wednesday 21 July 2004 21:42, Chris Gianelloni wrote:
> I love that idea.  The only problem I see is the need to add xml-parsing
> ability to portage, but the QA tool that was posted to this list a while
> back and the metadata xml parser, shows that it isn't impossible.

Plus robbat2 is working on some python modules for hacking XML too.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
                                                   http://stu.gnqs.org/diary/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] Revisiting GLEP 19

[Lars Weiler]

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

* Kurt Lieber <klieber@gentoo.org> [04/07/20 13:14 +0000]:
> So, with that said, thoughts, comments and other ideas are welcome.

First I have to say that it is a good choice not using
branching or tagging in CVS.  Although CVS is purposed for
such things, it has ever been a pain maintaining another
branch (check out the other branch, do the changes, check
in, check out the HEAD-branch etc... -- and don't try to
check in a file to a branch which has been edited on another
branch...).

So the proposed KEYWORD-addition is a good deal.  But you
should think about its name.  'stable' is quite bad, as we
name our current KEYWORDS without a ~ stable.  So it would
confuse both users and devs.  Another name would fit better,
like 'enterprise:' or something like this.  This also shows
for what purpose it has been introduced.

Regards, Lars

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