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@g.o]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@g.o mailing list