Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation

[Chris Gianelloni]

On Tue, 2005-11-22 at 15:42 -0500, Alec Joseph Warner wrote:
> I'd point out that this was not well executed as a major change should
> have been.  We talked of major package changes, apache config changes,
> of package breakage.  Then one day you up and remove what some consider
> a vital part of installing with no warning.  Announcements earlier
> noting the pending removal of tarballs to say, g-announce and this list

*sigh*

Please read the thread you're responding to before making accusations.
Nobody has removed any tarballs.

> would probably have stifled much of the complains ( see the news hit
> gentoo-wiki, gentoo-portage, and the community ).  Otherwise yeah, you
> will get a knee-jerk reaction, many users think you just screwed them
> out of something.  Nevermind the fact that they are wrong and uninformed
> ( in most cases ) you did a crappy job of conveying the message of what
> when and why.

No, we changed some text in the Handbook to basically say "If you want
stages 1 or 2, go here" with a link to the new location.

> Personally if releng is already making stages 1 and 2 for the liveCD's I
> see no reason not to give that work away to the community.  Stick it in
> some unsupported/ section on the mirrors and tell people so.  Why throw
> away the work you did making the liveCD?  Can you quantify the number of
> bugs here?

We don't put out the livecd-stage1 portions of our CD building process,
either.  Why not?  It isn't necessary and it really has no point.

As for quantifying the number of bugs, I could do so by searching
bugzilla, but so could you.  What I cannot quantify, because I haven't
even tried to keep track, is the number of times a user has hit a
circular dependency in #gentoo or on the forums, or by coming and asking
in #gentoo-releng.  I cannot quantify the number of times a person has
asked what is so broken with our releases when they cannot bootstrap due
to some issue where a new USE flag has snuck into the dependency tree
for "system" and is now wanting kernel sources, or has pulled in a MTA
or cron daemon that wasn't the one they wanted.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux