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

[Chris Gianelloni <wolf31o2@gentoo.org>]

[-- 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 --]