[gentoo-dev] Enterprise Installer [was "LWE Aftermath" on -core]

[gentoo-dev] Enterprise Installer [was "LWE Aftermath" on -core]

[Joshua J. Berry]

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

Hi all --

I just got back from LWE, and there was some discussion about needing an
automated installer for lots of machines running the same configuration.  For
lack of a better subject line, I'm calling this "Enterprise Installer" ... but
feel free to smack me with a wet fish if that's not a good name. ;)

I had lots of people come up to me and ask about features such as:

- Automated setup and install (a la Solaris' Jumpstart).  This involves several
  aspects, such as the creation of a custom profile, precompiling binaries,
  automatic partitioning/formatting, automatic configuration, tying into
  Catalyst to create an appropriate boot CD to run the install, ...

- Configuration management across many machines ... how can one easily handle
  changes to files in /etc, and propagate them to clients?

- Allow users to create and maintain a custom Portage tree (derived from our own
  base tree) which they can use to administer their other machines.

- Probably something else I forgot. ;)

While most of these are possible with shell scripts and the like, there are no
official Gentoo tools to do this.  I think it would be great for Gentoo to
create some, because I think this is one area in which we can really shine.

I should re-emphasize that there is quite a lot of demand for this, especially
in mid to larger companies which have hundreds or thousands of machines that
they'd like to put Gentoo on, but can't because the setup process is so
involved.  I don't remember exactly how many people asked me about it at
LinuxWorld, but enough did to make me remember. :)

So ... what are your thoughts on this?

On a related note, avenj did mention the Installer project to me, and gave me a
link to their CVS, but it hasn't been touched in a few months.  Anyone know what
their status is, and what specifically they're trying to accomplish?

-- Josh

-----------------------------------------
Joshua J. Berry

"I haven't lost my mind -- it's backed up on tape somewhere."
    -- /usr/games/fortune

NOTE: Please do not submit this email address to any mailing
lists or websites without prior permission.  Thank you.

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

Re: [gentoo-dev] Enterprise Installer [was "LWE Aftermath" on -core]

[FRLinux]

On Fri, 2004-08-06 at 19:06, Joshua J. Berry wrote:
> I had lots of people come up to me and ask about features such as:
> So ... what are your thoughts on this?

Another cool feature would be the possibility to install from a remote
server which already had compiled packages ready for a generic network
node (say all compiled for 686 by instance on my network) so it could be
pushed like Debian FAI.

Steph


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Enterprise Installer [was "LWE Aftermath" on -core]

[Chris Gianelloni]

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

On Fri, 2004-08-06 at 14:06, Joshua J. Berry wrote:
> - Automated setup and install (a la Solaris' Jumpstart).  This involves several
>   aspects, such as the creation of a custom profile, precompiling binaries,
>   automatic partitioning/formatting, automatic configuration, tying into
>   Catalyst to create an appropriate boot CD to run the install, ...

In most cases, a profile is not needed.  The profile only specifies the
"system" portion and default virtuals.  While I can see how some would
want it, I don't think it would be a requirement.  The pre-compiled
binaries are a must.  I could see this working in many ways, all of
which would need to be discussed.  A proper "rollout" tool would not
require a CD, so there would be no need to involve catalyst for such a
task, though there's no reason to not allow it.  I would instead see
catalyst taking the role of creating the binaries.  Installing new
machines would be carried out using industry standard methods, such as
PXE to boot an image that downloads from TFTP and loads up a NFS root
with an installer image.  The configuration would be decided before
install by the script, with possibly a final "setup" step after first
boot to complete a very small number of configuration options.

> - Configuration management across many machines ... how can one easily handle
>   changes to files in /etc, and propagate them to clients?

How does one do this in Red Hat?  SuSE?

Currently, there just isn't anybody really doing this well.  Having this
capability would definitely position Gentoo as a leader in the area of
workstation and server management.

> - Allow users to create and maintain a custom Portage tree (derived from our own
>   base tree) which they can use to administer their other machines.

This is too simple.  We already provide everything a user would want to
be able to do this.  Perhaps I am missing something.  Could you
enlighten us a bit more on this?

> - Probably something else I forgot. ;)

A stable portage tree for each release would be a requirement.

> While most of these are possible with shell scripts and the like, there are no
> official Gentoo tools to do this.  I think it would be great for Gentoo to
> create some, because I think this is one area in which we can really shine.

I agree.  At the same time, I realize that Gentoo is still very young,
and we have a long way to go and a lot of growing up to do.  The main
thing I notice about a lot of people is they want to take Gentoo and to
turn it into some huge enterprise solution, but they don't want to
invest the money nor manpower to do so.  Red Hat has capital.  They have
employees.  Every single one of us are volunteers, and honestly, until
that changes, there is no way we will ever be able to meet the needs of
the enterprise, simply because corporate customers will want things from
us that are not fun nor interesting, which means they will not be things
we will want to do.

I believe that to achieve these goals, we have to start by taking baby
steps.  Perhaps we should bring up some things at the next manager's
meeting?  To be honest, it looks like the first steps are going to be
the easiest, and at the same time the hardest.  We have to decide where
we want to go and lay out a plan.  The hardest part is we have to stick
to that plan and not falter.

> I should re-emphasize that there is quite a lot of demand for this, especially
> in mid to larger companies which have hundreds or thousands of machines that
> they'd like to put Gentoo on, but can't because the setup process is so
> involved.  I don't remember exactly how many people asked me about it at
> LinuxWorld, but enough did to make me remember. :)

There was a lot of demand for it at LWCE NYC, yet nothing really came
about from it.  I encourage anyone interested in the possibility of
growing up from a "hacker" distribution and into something the corporate
world respects to try to work together on this and make something
happen.

> So ... what are your thoughts on this?

We need to move on it, and not talk about it, then let the topic die off
and forget about it as has been going on for months now.

> On a related note, avenj did mention the Installer project to me, and gave me a
> link to their CVS, but it hasn't been touched in a few months.  Anyone know what
> their status is, and what specifically they're trying to accomplish?

I believe their charter was to create a nice installer that could be
used to install Gentoo in various fashion, using GRP as a base and
allowing for rapid deployment of servers and workstations based on
pre-defined criteria.

-- 
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] Enterprise Installer [was "LWE Aftermath" on -core]

[Joshua J. Berry]

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

On Fri, Aug 06, 2004 at 03:00:31PM -0400, Chris Gianelloni wrote:
> On Fri, 2004-08-06 at 14:06, Joshua J. Berry wrote:
> > - Automated setup and install (a la Solaris' Jumpstart).  This involves several
> >   aspects, such as the creation of a custom profile, precompiling binaries,
> >   automatic partitioning/formatting, automatic configuration, tying into
> >   Catalyst to create an appropriate boot CD to run the install, ...
> 
> In most cases, a profile is not needed.  The profile only specifies the
> "system" portion and default virtuals.  While I can see how some would
> want it, I don't think it would be a requirement. 

No, a profile a la Gentoo's Portage profile probably isn't ... I just used the
term "profile" to mean a specific set of installed packages and configuration
options (e.g. have a "mailserver" profile, a "webserver" profile and perhaps a
"workstation" profile).

You could certainly use Portage profiles for that purpose though, and I think it
might be a good place to start, at least until requirements dictate we find
something better.

> The pre-compiled
> binaries are a must.  I could see this working in many ways, all of
> which would need to be discussed.  A proper "rollout" tool would not
> require a CD, so there would be no need to involve catalyst for such a
> task, though there's no reason to not allow it.  I would instead see
> catalyst taking the role of creating the binaries.

I guess I don't quite understand what Catalyst's purpose is then.  Is it not to
create boot CDs for installation?

> Installing new
> machines would be carried out using industry standard methods, such as
> PXE to boot an image that downloads from TFTP and loads up a NFS root
> with an installer image. 

I like this idea better than a boot CD, but never having tried it myself, I
don't know how it would be setup or how practical it would be for users that are
just interested in setting up, say, a few machines at their small business in
this way.

...

> > - Allow users to create and maintain a custom Portage tree (derived from our own
> >   base tree) which they can use to administer their other machines.
> 
> This is too simple.  We already provide everything a user would want to
> be able to do this.  Perhaps I am missing something.  Could you
> enlighten us a bit more on this?

Some admins may wish to perform their own QA on the Portage tree before pushing
things out to their userbase, or perhaps create custom ebuilds for proprietary
software they have purchased and want to run on Gentoo.

Some people have also requested the ability to deliver a stripped-down version
of the tree (e.g. removing server-ish ebuilds from trees that will only be used
with workstations), so that it's harder for those of their end users who have
root to do something silly like install a DHCP server on a workstation.

Also, stripped down Portage trees are easier for them to distribute internally,
especially if the distribution is happening over a WAN as it might in larger
companies.

> 
> > - Probably something else I forgot. ;)
> 
> A stable portage tree for each release would be a requirement.

By "stable", are you talking about the snapshots a la Gentoo Enterprise?  (i.e.
Take a stable snapshot every N months and release it.)  I think we would
probably be OK without this, at least for those admins who choose to do their
own QA.  After all, staying fairly consistently up-to-date is another advantage
to Gentoo which some may wish to take advantage of.

> 
> > While most of these are possible with shell scripts and the like, there are no
> > official Gentoo tools to do this.  I think it would be great for Gentoo to
> > create some, because I think this is one area in which we can really shine.
> 
> I agree.  At the same time, I realize that Gentoo is still very young,
> and we have a long way to go and a lot of growing up to do.  The main
> thing I notice about a lot of people is they want to take Gentoo and to
> turn it into some huge enterprise solution, but they don't want to
> invest the money nor manpower to do so. 

I have no money, but I do have time (at least during the summer), and I have a
certain amount of personal interest.  (I'd like my school to start using Gentoo,
and I think having a tool like this might convince them.)

If enough people are willing to work on this, we should start (yet) a(nother)
project.

> Red Hat has capital.  They have
> employees.  Every single one of us are volunteers, and honestly, until
> that changes, there is no way we will ever be able to meet the needs of
> the enterprise, simply because corporate customers will want things from
> us that are not fun nor interesting, which means they will not be things
> we will want to do.

This means--and this has been brought up repeatedly before--there needs to be
some sort of for-profit company, separate from the non-profit, that has at least
a few full-time Gentoo devs on its staff.  Or so it seems to me.

There may even be (and probably are) a set of people out there offering Gentoo
to their clients as part of their business.  Perhaps we should start keeping a
list of these people.

> 
> I believe that to achieve these goals, we have to start by taking baby
> steps.  Perhaps we should bring up some things at the next manager's
> meeting?  To be honest, it looks like the first steps are going to be
> the easiest, and at the same time the hardest.  We have to decide where
> we want to go and lay out a plan.  The hardest part is we have to stick
> to that plan and not falter.

The first step is always to figure out where you want to go ... I think we're
doing that now.  Then we just need to break the problem down into small pieces.

If anyone is interested, I can perhaps draft up some thoughts/the beginnings of
a raodmap for getting this done.

> > So ... what are your thoughts on this?
> 
> We need to move on it, and not talk about it, then let the topic die off
> and forget about it as has been going on for months now.

OK.  Let's go. :)

> 
> > On a related note, avenj did mention the Installer project to me, and gave me a
> > link to their CVS, but it hasn't been touched in a few months.  Anyone know what
> > their status is, and what specifically they're trying to accomplish?
> 
> I believe their charter was to create a nice installer that could be
> used to install Gentoo in various fashion, using GRP as a base and
> allowing for rapid deployment of servers and workstations based on
> pre-defined criteria.

That sounds like it's the first (big) step then.  Let's get an installer
working.

-- 

-----------------------------------------
Joshua J. Berry

"I haven't lost my mind -- it's backed up on tape somewhere."
    -- /usr/games/fortune

NOTE: Please do not submit this email address to any mailing
lists or websites without prior permission.  Thank you.

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

Re: [gentoo-dev] Enterprise Installer [was "LWE Aftermath" on -core]

[Chris Gianelloni]

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

On Fri, 2004-08-06 at 15:26, Joshua J. Berry wrote:
> No, a profile a la Gentoo's Portage profile probably isn't ... I just used the
> term "profile" to mean a specific set of installed packages and configuration
> options (e.g. have a "mailserver" profile, a "webserver" profile and perhaps a
> "workstation" profile).

You mean something more of an installation type, rather than a "profile"
then... Make sure we don't re-use terminology that could be ambiguous in
meaning.

> You could certainly use Portage profiles for that purpose though, and I think it
> might be a good place to start, at least until requirements dictate we find
> something better.

Not really... unless you wanted everything in your "profile" to be
considered the "system".

> > The pre-compiled
> > binaries are a must.  I could see this working in many ways, all of
> > which would need to be discussed.  A proper "rollout" tool would not
> > require a CD, so there would be no need to involve catalyst for such a
> > task, though there's no reason to not allow it.  I would instead see
> > catalyst taking the role of creating the binaries.
> 
> I guess I don't quite understand what Catalyst's purpose is then.  Is it not to
> create boot CDs for installation?

Catalyst can be used for many things.  It makes GRP sets, LiveCD's, and
a tinderbox.  A LiveCD does not have to be an installation CD.  In fact,
I am working now to extend catalyst to create a GameCD.

I guess I am saying the process to create a LiveCD is a bit more
involved than needed for most cases.  Using a network boot method plus
some scripts would be much quicker and cleaner.  It also wouldn't
require lugging around a CD, which means the CD must be kept up-to-date
with changes and other such problems.  Definitely not the best way for
the enterprise to go about it.

> > Installing new
> > machines would be carried out using industry standard methods, such as
> > PXE to boot an image that downloads from TFTP and loads up a NFS root
> > with an installer image. 
> 
> I like this idea better than a boot CD, but never having tried it myself, I
> don't know how it would be setup or how practical it would be for users that are
> just interested in setting up, say, a few machines at their small business in
> this way.

This isn't designed for the guy wanting a few machines, though he would
be able to utilize it.  It would probably still be quicker than creating
a custom boot CD.  Especially since if we were to create it, we would
make it simple for the user.  It would probably end up no harder than
creating a catalyst .spec file to begin with, so why take the time to
make a CD out of it?

Also, stick with scope here.  Are we talking the guy with 10 machines or
are we talking the ENTERPRISE where we're considering hundreds or
thousands of machines.  Having to go to each of a thousand machines with
a CD can be tedious.

> Some admins may wish to perform their own QA on the Portage tree before pushing
> things out to their userbase, or perhaps create custom ebuilds for proprietary
> software they have purchased and want to run on Gentoo.

What makes this different than one of several methods:

- The admin runs his own rsync mirror with only his "QA certified"
ebuilds in it.
- The admin NFS mounts his "QA certified" portage tree.
- The admin pushes out his "QA certified" portage tree as an overlay.

Personally, I think the first is the best.  Remember, the admin does not
have to offer up *our* tree for rsync.  If he decides to standardize on
KDE and doesn't want anyone running games, he can rm -rf
/usr/portage/gnome-* and /usr/portage/games-* and even add them to his
RSYNC_EXCLUDES.


> Some people have also requested the ability to deliver a stripped-down version
> of the tree (e.g. removing server-ish ebuilds from trees that will only be used
> with workstations), so that it's harder for those of their end users who have
> root to do something silly like install a DHCP server on a workstation.

See above.  We have not denied this ability since the introduction of
the SYNC variable.

> By "stable", are you talking about the snapshots a la Gentoo Enterprise?  (i.e.
> Take a stable snapshot every N months and release it.)  I think we would
> probably be OK without this, at least for those admins who choose to do their
> own QA.  After all, staying fairly consistently up-to-date is another advantage
> to Gentoo which some may wish to take advantage of.

Installing a Gentoo "release" should be the same no matter when you
install it.  The versions should be the same.  The admin should know
what to expect from our distribution.  If you follow my thread (way back
a couple weeks ago) about having a set of -release trees and a -current
tree, you'll see what I mean.  At no point are we limiting the user's
choice by offering a frozen -release tree for each release.  In fact, we
are giving the user more options.

> I have no money, but I do have time (at least during the summer), and I have a
> certain amount of personal interest.  (I'd like my school to start using Gentoo,
> and I think having a tool like this might convince them.)

I'm not sure you understand the scale of such a project.  Something like
this would require an enormous dedication and a very far-reaching plan. 
To be honest, even if you're just starting school, I wouldn't expect to
see this even at a remotely close to completed stage by the time you
graduate without some serious financial and manpower backing.

> If enough people are willing to work on this, we should start (yet) a(nother)
> project.

Instead, what needs to be done rather than start yet another project
which will go dormant in 6 months, is to get everyone interested
involved, including any other projects that would be encompassed, such
as the installer guys, and actually put something together and stick
with it.  The real problem is that these sort of things are pretty
boring to bring about.  Interest wanes quite easily when working on a
project of such a scope.  Rather than come up with these huge, elaborate
plans, what needs to be done is baby steps need to be achieved.  Take
everything step by step.

I still think our first step should be the creation of a -release tree
and that's it.  Forget claiming support on it or any of that nonsense,
since we can't do it and we know it.  We won't even claim to back port
any fixes, because we probably won't.  We can add fixes that *are* back
ported, but we won't guarantee any availability on them.  What this
does, is it creates a definitive itch for people to scratch.

> This means--and this has been brought up repeatedly before--there needs to be
> some sort of for-profit company, separate from the non-profit, that has at least
> a few full-time Gentoo devs on its staff.  Or so it seems to me.

Gentoo Linux is run by a not-for-profit company for a reason.  We do not
want corporate interests guiding us.

What would need to be done, is a separate entity would need to be
established.  This entity could be owned by the Gentoo Foundation, or
completely separate.  It could be manned by Gentoo devs, or just users,
it doesn't matter.  The main problem with doing this and PAYING people
to work on the system is the sheer amount of capital that would be
required to operate such a venture.  I would guess that you would be
paying the entire staff for at least 2 years just to get to the point of
being able to offer a supportable product.  After all, every single bit
of the supported tree would require developers to back port fixes.

More than likely, only a certain subset of the tree would be supported,
as attempting to support the entire thing would be a daunting task. 
Perhaps a group of people simply willing to support all of the packages
offered via GRP, including back porting fixes, would be a good start.

> There may even be (and probably are) a set of people out there offering Gentoo
> to their clients as part of their business.  Perhaps we should start keeping a
> list of these people.

I think we should.  I know there are people using Gentoo for this sort
of thing.

I still like the idea that was proposed of some form of support coop.

> > I believe that to achieve these goals, we have to start by taking baby
> > steps.  Perhaps we should bring up some things at the next manager's
> > meeting?  To be honest, it looks like the first steps are going to be
> > the easiest, and at the same time the hardest.  We have to decide where
> > we want to go and lay out a plan.  The hardest part is we have to stick
> > to that plan and not falter.
> 
> The first step is always to figure out where you want to go ... I think we're
> doing that now.  Then we just need to break the problem down into small pieces.

We figured out where we wanted to go the last time this came up... and
the time before that... and the time before that... and the....

I've given a good starting point, a frozen tree.  Since such a thing
would require buy-in from -releng (not a problem), -infra and the mirror
admins, and the management, it needs to be brought up at a manager's
meeting and voted on, preferably with some idea of the additional mirror
space and some initial feedback from all the parties involved.

> If anyone is interested, I can perhaps draft up some thoughts/the beginnings of
> a raodmap for getting this done.
> 
> > > So ... what are your thoughts on this?
> > 
> > We need to move on it, and not talk about it, then let the topic die off
> > and forget about it as has been going on for months now.
> 
> OK.  Let's go. :)
> 
> > 
> > > On a related note, avenj did mention the Installer project to me, and gave me a
> > > link to their CVS, but it hasn't been touched in a few months.  Anyone know what
> > > their status is, and what specifically they're trying to accomplish?
> > 
> > I believe their charter was to create a nice installer that could be
> > used to install Gentoo in various fashion, using GRP as a base and
> > allowing for rapid deployment of servers and workstations based on
> > pre-defined criteria.
> 
> That sounds like it's the first (big) step then.  Let's get an installer
> working.

What would the installer *do* exactly?  That is a VERY large step to
take... or at least I think so.  Does the installer perform a stage1
install? stage3? GRP? GRP + more packages?  Does it use the portage
snapshot each arch lead makes for his release?

Wouldn't it be easier to do with a frozen -release tree? (In case you're
not getting it, I want a frozen tree... *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] Enterprise Installer [was "LWE Aftermath" on -core]

[Joshua J. Berry]

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

On Fri, Aug 06, 2004 at 05:05:12PM -0400, Chris Gianelloni wrote:
> On Fri, 2004-08-06 at 15:26, Joshua J. Berry wrote:
> > No, a profile a la Gentoo's Portage profile probably isn't ... I just used the
> > term "profile" to mean a specific set of installed packages and configuration
> > options (e.g. have a "mailserver" profile, a "webserver" profile and perhaps a
> > "workstation" profile).
> 
> You mean something more of an installation type, rather than a "profile"
> then... Make sure we don't re-use terminology that could be ambiguous in
> meaning.

No, I do mean a profile-ish thing ... install is just the first step in maintenance.
Suppose you have a bunch of preinstalled workstations and you want to push out
another app.  How do you do it?  Add it to the profile-ish thing.

> I guess I am saying the process to create a LiveCD is a bit more
> involved than needed for most cases.  Using a network boot method plus
> some scripts would be much quicker and cleaner.  It also wouldn't
> require lugging around a CD, which means the CD must be kept up-to-date
> with changes and other such problems.  Definitely not the best way for
> the enterprise to go about it.

You're right.

> This isn't designed for the guy wanting a few machines, though he would
> be able to utilize it.  It would probably still be quicker than creating
> a custom boot CD.  Especially since if we were to create it, we would
> make it simple for the user.  It would probably end up no harder than
> creating a catalyst .spec file to begin with, so why take the time to
> make a CD out of it?

The point I was trying to make is, we should--eventually--support both options.
We don't need to do it immediately, of course, but it should be there.

> Also, stick with scope here.  Are we talking the guy with 10 machines or
> are we talking the ENTERPRISE where we're considering hundreds or
> thousands of machines.  Having to go to each of a thousand machines with
> a CD can be tedious.

Enterprise, for now, which can eventually be scaled down to work with the guy
who has 10 machines and want to use it at home.

> > Some admins may wish to perform their own QA on the Portage tree before pushing
> > things out to their userbase, or perhaps create custom ebuilds for proprietary
> > software they have purchased and want to run on Gentoo.
> 
> What makes this different than one of several methods:
> 
> - The admin runs his own rsync mirror with only his "QA certified"
> ebuilds in it.
> - The admin NFS mounts his "QA certified" portage tree.
> - The admin pushes out his "QA certified" portage tree as an overlay.
> 
> Personally, I think the first is the best.  Remember, the admin does not
> have to offer up *our* tree for rsync.  If he decides to standardize on
> KDE and doesn't want anyone running games, he can rm -rf
> /usr/portage/gnome-* and /usr/portage/games-* and even add them to his
> RSYNC_EXCLUDES.

The first is pretty much what I was suggesting.

I realize this can be done now, but there should--eventually--be tools to make
management of custom trees easier.

> I'm not sure you understand the scale of such a project. 

I think I do.  I explored this idea (on a more limited scope, of course) when I
was working for Cal Poly's CSC dept last year.

> Something like this would require an enormous dedication and a very
> far-reaching plan.  To be honest, even if you're just starting school, I
> wouldn't expect to see this even at a remotely close to completed stage by the
> time you graduate without some serious financial and manpower backing.

I understand that.  But if we don't start somewhere, such a project will never
be completed.

> > If enough people are willing to work on this, we should start (yet) a(nother)
> > project.
> 
> Instead, what needs to be done rather than start yet another project
> which will go dormant in 6 months, is to get everyone interested
> involved, including any other projects that would be encompassed, such
> as the installer guys, and actually put something together and stick
> with it. 

How is this different from creating a project?

> The real problem is that these sort of things are pretty boring to bring
> about.  Interest wanes quite easily when working on a project of such a scope.
> Rather than come up with these huge, elaborate plans, what needs to be done is
> baby steps need to be achieved.  Take everything step by step.

Portage wasn't written in a day.  I understand your point about baby steps, but
how do you expect to get anywhere if you have no idea of where you're going?

> > This means--and this has been brought up repeatedly before--there needs to be
> > some sort of for-profit company, separate from the non-profit, that has at least
> > a few full-time Gentoo devs on its staff.  Or so it seems to me.
> 
> Gentoo Linux is run by a not-for-profit company for a reason.  We do not
> want corporate interests guiding us.
> 
> What would need to be done, is a separate entity would need to be
> established.  This entity could be owned by the Gentoo Foundation, or
> completely separate.  It could be manned by Gentoo devs, or just users,
> it doesn't matter. 

Yes.  This is pretty much what I was suggesting.

> The main problem with doing this and PAYING people
> to work on the system is the sheer amount of capital that would be
> required to operate such a venture.  I would guess that you would be
> paying the entire staff for at least 2 years just to get to the point of
> being able to offer a supportable product.  After all, every single bit
> of the supported tree would require developers to back port fixes.

I don't know enough about how companies work, or how much it would take to get
the Portage tree into a "supportable" state.  If this is the case, then perhaps
creating a separate for-profit company wouldn't be feasible, and the list of 3rd
party supporters is a better idea.

> > The first step is always to figure out where you want to go ... I think we're
> > doing that now.  Then we just need to break the problem down into small pieces.
> 
> We figured out where we wanted to go the last time this came up... and
> the time before that... and the time before that... and the....

Where's the plan, then?  Has anybody written up a coherent plan, broken the
tasks down into small steps, and posted it somewhere?

> I've given a good starting point, a frozen tree.  Since such a thing
> would require buy-in from -releng (not a problem), -infra and the mirror
> admins, and the management, it needs to be brought up at a manager's
> meeting and voted on, preferably with some idea of the additional mirror
> space and some initial feedback from all the parties involved.

I certainly don't have a problem with a frozen tree; I think it's a good idea.

But I guess I'm not entirely sure how a frozen tree would help us here ... I
think we might be talking about two different things.  I was talking mainly
about providing a way for large sites to painlessly configure/install/maintain
Gentoo on lots of machines.

> > > > On a related note, avenj did mention the Installer project to me, and gave me a
> > > > link to their CVS, but it hasn't been touched in a few months.  Anyone know what
> > > > their status is, and what specifically they're trying to accomplish?
> > > 
> > > I believe their charter was to create a nice installer that could be
> > > used to install Gentoo in various fashion, using GRP as a base and
> > > allowing for rapid deployment of servers and workstations based on
> > > pre-defined criteria.
> > 
> > That sounds like it's the first (big) step then.  Let's get an installer
> > working.
> 
> What would the installer *do* exactly?  That is a VERY large step to
> take... or at least I think so.  Does the installer perform a stage1
> install? stage3? GRP? GRP + more packages?  Does it use the portage
> snapshot each arch lead makes for his release?

Well, it is a big step.  We're not really ready to start doing that yet.  

Like you said, we need to take baby steps.  Let's get/make a list of those for
the installer.

> Wouldn't it be easier to do with a frozen -release tree? (In case you're
> not getting it, I want a frozen tree... *grin*)

OK, so let's make a frozen tree.  But that doesn't have much to do with
configuration/installation/maintenance of lots of machines. ;)

-----------------------------------------
Joshua J. Berry

"I haven't lost my mind -- it's backed up on tape somewhere."
    -- /usr/games/fortune

NOTE: Please do not submit this email address to any mailing
lists or websites without prior permission.  Thank you.

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

Re: [gentoo-dev] Enterprise Installer [was "LWE Aftermath" on -core]

[Chris Gianelloni]

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

On Fri, 2004-08-06 at 17:34, Joshua J. Berry wrote:
> No, I do mean a profile-ish thing ... install is just the first step in maintenance.
> Suppose you have a bunch of preinstalled workstations and you want to push out
> another app.  How do you do it?  Add it to the profile-ish thing.

So you mean something like Red Hat's channel subscriptions?  Honestly,
they have a good idea.  Have you ever played with their Satellite Server
product?  It is essentially a local copy of RHN which also allows you to
create custom channels to subscribe systems to and also allows you to
easily manage your kickstart configurations for building new systems.

> > This isn't designed for the guy wanting a few machines, though he would
> > be able to utilize it.  It would probably still be quicker than creating
> > a custom boot CD.  Especially since if we were to create it, we would
> > make it simple for the user.  It would probably end up no harder than
> > creating a catalyst .spec file to begin with, so why take the time to
> > make a CD out of it?
> 
> The point I was trying to make is, we should--eventually--support both options.
> We don't need to do it immediately, of course, but it should be there.

I don't think I am following you.  What is "the little guy" option?  At
what point does it become easier to not use DHCP and PXE?  Is it even
worth the effort to "deploy" on that number of machines, or are you
speaking more of a simple installer?  The installer is within the scope
of the enterprise product.  Nothing is stopping someone from using it,
even on a single machine.

> > Also, stick with scope here.  Are we talking the guy with 10 machines or
> > are we talking the ENTERPRISE where we're considering hundreds or
> > thousands of machines.  Having to go to each of a thousand machines with
> > a CD can be tedious.
> 
> Enterprise, for now, which can eventually be scaled down to work with the guy
> who has 10 machines and want to use it at home.

There's nothing stopping the person with 10 machines from using the
product as intended.  I don't think there's any need to "scale down" any
properly designed product.  Instead, it should be usable on anything
from 2 machines (one server and one client) on up, to only a single
machine if only using the installer and none of the "kickstart" type of
deployment tools.

> The first is pretty much what I was suggesting.
> 
> I realize this can be done now, but there should--eventually--be tools to make
> management of custom trees easier.

I'm not sure how much easier it can be that copying an ebuild, but I'm
with you.  If you see a need and it is something that should be managed,
then by all means lets do it.

> > I'm not sure you understand the scale of such a project. 
> 
> I think I do.  I explored this idea (on a more limited scope, of course) when I
> was working for Cal Poly's CSC dept last year.

Well, understand that Gentoo is very very big and very very diverse.  We
extend from Argentina to Alaska and everywhere in between.  Our users
speak every imaginable language and have any number of wants and
desires.  We also provide an enormous amount of software via portage,
which needs to be managed.

> > Something like this would require an enormous dedication and a very
> > far-reaching plan.  To be honest, even if you're just starting school, I
> > wouldn't expect to see this even at a remotely close to completed stage by the
> > time you graduate without some serious financial and manpower backing.
> 
> I understand that.  But if we don't start somewhere, such a project will never
> be completed.

I agree.  I also think that it is a long and painful road and am simply
not rushing into anything with a fool's hope that it will be easy.

> > > If enough people are willing to work on this, we should start (yet) a(nother)
> > > project.
> > 
> > Instead, what needs to be done rather than start yet another project
> > which will go dormant in 6 months, is to get everyone interested
> > involved, including any other projects that would be encompassed, such
> > as the installer guys, and actually put something together and stick
> > with it. 
> 
> How is this different from creating a project?

Creating a project does nothing but give something a name.  We already
have a Gentoo Server project and a Gentoo Enterprise project, not to
mention at least one GLEP which all fall under the scope of creating a
corporate-friendly Gentoo.

> > The real problem is that these sort of things are pretty boring to bring
> > about.  Interest wanes quite easily when working on a project of such a scope.
> > Rather than come up with these huge, elaborate plans, what needs to be done is
> > baby steps need to be achieved.  Take everything step by step.
> 
> Portage wasn't written in a day.  I understand your point about baby steps, but
> how do you expect to get anywhere if you have no idea of where you're going?

I'm still fairly new as a developer, but I have seen tons of great ideas
brought up with much fever and passion behind it, only to watch it
fizzle out and die a few weeks later once it runs out of everyone's
minds.  Having grand plans is great if you're planning on exploring
Egypt.  For a software project, the best course of action is to decide
where you want to go and implement a plan.

I definitely don't have the answers here.  I just see things that work
and like to point them out... *grin*

> > The main problem with doing this and PAYING people
> > to work on the system is the sheer amount of capital that would be
> > required to operate such a venture.  I would guess that you would be
> > paying the entire staff for at least 2 years just to get to the point of
> > being able to offer a supportable product.  After all, every single bit
> > of the supported tree would require developers to back port fixes.
> 
> I don't know enough about how companies work, or how much it would take to get
> the Portage tree into a "supportable" state.  If this is the case, then perhaps
> creating a separate for-profit company wouldn't be feasible, and the list of 3rd
> party supporters is a better idea.

It could be feasible, provided there was enough financial interest to
understand that they would be losing their a** for the first couple
years, seeing little to no returns on their investment.  The portage
tree isn't in a sad shape at all, but we rely on our ability to move to
newer versions and technologies quickly to help us overcome problems
such as security, rather than spending lots of developer time fixing
things from upstream.  I am not trying to belittle anyone's efforts,
because everyone works so hard.  What I mean is that sometimes (most
times?) it is easier to upgrade from foo-1.0 to foo-1.1 than to fix
foo-1.0's flaws.  This doesn't jive well with corporate interests, which
generally want as little change as possible.

> > We figured out where we wanted to go the last time this came up... and
> > the time before that... and the time before that... and the....
> 
> Where's the plan, then?  Has anybody written up a coherent plan, broken the
> tasks down into small steps, and posted it somewhere?

Nobody ever got that far.  Instead there was lots of "great ideas" and
"let's do that" and then as soon as the thread died on -dev (or -core)
it was out of everyone's minds.

> I certainly don't have a problem with a frozen tree; I think it's a good idea.

Great!  Should we bring it up at an upcoming manager's meeting?

> But I guess I'm not entirely sure how a frozen tree would help us here ... I
> think we might be talking about two different things.  I was talking mainly
> about providing a way for large sites to painlessly configure/install/maintain
> Gentoo on lots of machines.

How do you install/maintain/configure a large number of machines when
your base is ever changing?  Install a machine using the 2004.2 CD right
now.  Wait 2 hours, then install another machine.  Are the package
versions the same?  Why not?  If the versions are the same, then 5
months from now someone can install from that CD and get the same
results.  Reproducible results are a necessity for companies planning
for their infrastructure.  It also makes things a lot easier to support
when you know what to expect.

> > What would the installer *do* exactly?  That is a VERY large step to
> > take... or at least I think so.  Does the installer perform a stage1
> > install? stage3? GRP? GRP + more packages?  Does it use the portage
> > snapshot each arch lead makes for his release?
> 
> Well, it is a big step.  We're not really ready to start doing that yet.  
> 
> Like you said, we need to take baby steps.  Let's get/make a list of those for
> the installer.

Honestly, I don't see the installer as a first step, but that is totally
up for discussion.  I tend to think that management tools would be a
better place to focus, along with working to implement ideas that have
already been proposed.  We should be able to have a complete binary
install of Gentoo done using GRP in about 20-30 minutes, but it takes
almost an hour due to the number of manual steps required, and compiling
a kernel.  There is a GLEP for the introduction of compiled kernels. 
Would that not be beneficial for an installer and an enterprise Gentoo?

> > Wouldn't it be easier to do with a frozen -release tree? (In case you're
> > not getting it, I want a frozen tree... *grin*)
> 
> OK, so let's make a frozen tree.  But that doesn't have much to do with
> configuration/installation/maintenance of lots of machines. ;)

It doesn't really.  It just lays a strong framework to build upon.

I don't have intentions for even starting a frozen tree by the next
release, but I would like to shoot for 2005.0, if we can get buy-in from
management and developers.

I definitely would love to see more work being done in making Gentoo
easier to install and use in an enterprise.

-- 
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] Enterprise Installer [was "LWE Aftermath" on -core]

[Joshua J. Berry]

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

On Fri, Aug 06, 2004 at 08:08:32PM -0400, Chris Gianelloni wrote:
> On Fri, 2004-08-06 at 17:34, Joshua J. Berry wrote:
> > No, I do mean a profile-ish thing ... install is just the first step in maintenance.
> > Suppose you have a bunch of preinstalled workstations and you want to push out
> > another app.  How do you do it?  Add it to the profile-ish thing.
> 
> So you mean something like Red Hat's channel subscriptions?  Honestly,
> they have a good idea.  Have you ever played with their Satellite Server
> product?  It is essentially a local copy of RHN which also allows you to
> create custom channels to subscribe systems to and also allows you to
> easily manage your kickstart configurations for building new systems.

I haven't ... I stopped using Red Hat myself sometime around RH8, and I never
did use their RHN system.

> > The point I was trying to make is, we should--eventually--support both options.
> > We don't need to do it immediately, of course, but it should be there.
> 
> I don't think I am following you.  What is "the little guy" option?  At
> what point does it become easier to not use DHCP and PXE?  Is it even
> worth the effort to "deploy" on that number of machines, or are you
> speaking more of a simple installer?  The installer is within the scope
> of the enterprise product.  Nothing is stopping someone from using it,
> even on a single machine.

mmm.  You're probably right.  It's been a while since I looked at PXE myself, so
I may be remembering it as harder/more daunting than it really is.

> > The first is pretty much what I was suggesting.
> > 
> > I realize this can be done now, but there should--eventually--be tools to make
> > management of custom trees easier.
> 
> I'm not sure how much easier it can be that copying an ebuild, but I'm
> with you.  If you see a need and it is something that should be managed,
> then by all means lets do it.

Except it's not just copying the ebuild, it's copying the ebuild, managing the
digests, copying the patches ... ;)

> > > Something like this would require an enormous dedication and a very
> > > far-reaching plan.  To be honest, even if you're just starting school, I
> > > wouldn't expect to see this even at a remotely close to completed stage by the
> > > time you graduate without some serious financial and manpower backing.
> > 
> > I understand that.  But if we don't start somewhere, such a project will never
> > be completed.
> 
> I agree.  I also think that it is a long and painful road and am simply
> not rushing into anything with a fool's hope that it will be easy.

Oh no, I never said it would be easy.  Just that we should do it. ;)

> > > The real problem is that these sort of things are pretty boring to bring
> > > about.  Interest wanes quite easily when working on a project of such a scope.
> > > Rather than come up with these huge, elaborate plans, what needs to be done is
> > > baby steps need to be achieved.  Take everything step by step.
> > 
> > Portage wasn't written in a day.  I understand your point about baby steps, but
> > how do you expect to get anywhere if you have no idea of where you're going?
> 
> I'm still fairly new as a developer, but I have seen tons of great ideas
> brought up with much fever and passion behind it, only to watch it
> fizzle out and die a few weeks later once it runs out of everyone's
> minds.  Having grand plans is great if you're planning on exploring
> Egypt.  For a software project, the best course of action is to decide
> where you want to go and implement a plan.

I've seen that happen quite a bit as well.  I don't really have any solution
other than find some way to keep it interesting so people will work on it.

I myself am guilty of this (there haven't been too many GLSAs with my name on
them recently :( ).  If I find a solution to this I'll let everyone know. ;P

> > I don't know enough about how companies work, or how much it would take to get
> > the Portage tree into a "supportable" state.  If this is the case, then perhaps
> > creating a separate for-profit company wouldn't be feasible, and the list of 3rd
> > party supporters is a better idea.
> 
> It could be feasible, provided there was enough financial interest to
> understand that they would be losing their a** for the first couple
> years, seeing little to no returns on their investment.  The portage
> tree isn't in a sad shape at all, but we rely on our ability to move to
> newer versions and technologies quickly to help us overcome problems
> such as security, rather than spending lots of developer time fixing
> things from upstream.  I am not trying to belittle anyone's efforts,
> because everyone works so hard.  What I mean is that sometimes (most
> times?) it is easier to upgrade from foo-1.0 to foo-1.1 than to fix
> foo-1.0's flaws.  This doesn't jive well with corporate interests, which
> generally want as little change as possible.

My experience, at least with security bugs, has been that upstream developers in
general tend to keep maintenance releases and new feature releases separate.
Oftentimes there will be an upgrade to a package that contains only the security
fixes, and no other new code.  Of course, this isn't true for all packages, but
it is true for most of the ones I've worked on.

Sometimes the security team will backport fixes (e.g. the rsync vulnerability
that came out not too long ago) because we don't want to push a later version
out for stability reasons.  But again, that's just security, I don't know how
others handle it.

> > > We figured out where we wanted to go the last time this came up... and
> > > the time before that... and the time before that... and the....
> > 
> > Where's the plan, then?  Has anybody written up a coherent plan, broken the
> > tasks down into small steps, and posted it somewhere?
> 
> Nobody ever got that far.  Instead there was lots of "great ideas" and
> "let's do that" and then as soon as the thread died on -dev (or -core)
> it was out of everyone's minds.

There's the first problem.  Nobody's even really explored the feasibility of
doing something like this ... what exactly--and by exactly, I mean right down to
the baby steps--would need to be done?

> > I certainly don't have a problem with a frozen tree; I think it's a good idea.
> 
> Great!  Should we bring it up at an upcoming manager's meeting?

Go for it.  I'm not a manager but FWIW you have my moral support. :)

> > But I guess I'm not entirely sure how a frozen tree would help us here ... I
> > think we might be talking about two different things.  I was talking mainly
> > about providing a way for large sites to painlessly configure/install/maintain
> > Gentoo on lots of machines.
> 
> How do you install/maintain/configure a large number of machines when
> your base is ever changing?

You use your own internal-QA-approved Portage tree.

> Install a machine using the 2004.2 CD right
> now.  Wait 2 hours, then install another machine.  Are the package
> versions the same?  Why not?  If the versions are the same, then 5
> months from now someone can install from that CD and get the same
> results.  Reproducible results are a necessity for companies planning
> for their infrastructure.  It also makes things a lot easier to support
> when you know what to expect.

I agree, which is why I think frozen trees, or site-specific Portage trees are a
good idea.

> Honestly, I don't see the installer as a first step, but that is totally
> up for discussion.  I tend to think that management tools would be a
> better place to focus, along with working to implement ideas that have
> already been proposed.

Well, the installer is a management tool of sorts.

But really, the first step is finding out what the first step is. ;)

> We should be able to have a complete binary
> install of Gentoo done using GRP in about 20-30 minutes, but it takes
> almost an hour due to the number of manual steps required, and compiling
> a kernel.  There is a GLEP for the introduction of compiled kernels. 
> Would that not be beneficial for an installer and an enterprise Gentoo?

Yes, it would, in the same way that frozen trees are good.  I don't know how
feasible this would be, though ... how do you handle all the different hardware
configurations?  We could very easily end up with bloated kernels a la the
binary distributions.

I think I would prefer that each site compile one kernel for each set of
machines it needs, and the compiled kernels get installed separately.  I have no
idea how this would work, however. :)

> I definitely would love to see more work being done in making Gentoo
> easier to install and use in an enterprise.

So let's at least start a plan, and see where we can go from there.

-----------------------------------------
Joshua J. Berry

"I haven't lost my mind -- it's backed up on tape somewhere."
    -- /usr/games/fortune

NOTE: Please do not submit this email address to any mailing
lists or websites without prior permission.  Thank you.

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

Re: [gentoo-dev] Enterprise Installer [was "LWE Aftermath" on -core]

[Blackace]

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

Shh!

CondorDes, Chris: go to the Installer Project page and read :)

http://www.gentoo.org/proj/en/releng/installer/index.xml

And both of you go read GLEP 19 and please stop talking implementation
when there are already people working on these things, instead read
about what is already happening and ask questions, but leave the
answering to the people who have already invested their time in these
projects.

Thanks ;)
-- 
Blackace
Gentoo Linux
Infrastructure Developer

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

Re: [gentoo-dev] Enterprise Installer [was "LWE Aftermath" on -core]

[Sven Vermeulen]

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

On Fri, Aug 06, 2004 at 08:08:32PM -0400, Chris Gianelloni wrote:
> Creating a project does nothing but give something a name.  We already
> have a Gentoo Server project and a Gentoo Enterprise project, not to
> mention at least one GLEP which all fall under the scope of creating a
> corporate-friendly Gentoo.

These projects are good examples of "baby step" evolution. Good ideas but
little resources provide no succes. If Gentoo wants to become a major market
player, we should focus on our current projects and make those of high
quality. 

Why would we be able to become a major player if we can't keep some of our
current projects alive? I'm talking about a minority of projects here, most
of our projects are very vivid and provide good quality. But, for some
reason, those projects that I am talking about have to do with the road we
are talking about here.

> > I certainly don't have a problem with a frozen tree; I think it's a good idea.
> Great!  Should we bring it up at an upcoming manager's meeting?

If I'm not mistaken it has already been brought up. The issue then was that
we didn't have enough resources to maintain the frozen tree. If you believe
this has changed, please do so.

But remember that, if you bring this up without a decent plan, the meeting
will probably tell you to write up a plan. Don't expect the manager meeting
to discuss and provide one for you. A short discussion (1 ~ 2 hours) is far 
too little to mention every possible aspect.

Wkr,
      Sven Vermeulen


-- 
 Bent Hindrup Andersen, Danish MEP, about the Software Patent Directive:
    The approach of the Commission and Council in this directive is shocking. 
    They are making full use of all the possibilities of evading democracy that 
    the current Community Law provides.     <http://lwn.net/Articles/84009/>

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

Re: [gentoo-dev] Enterprise Installer [was "LWE Aftermath" on -core]

[Michiel de Bruijne]

>
> Wouldn't it be easier to do with a frozen -release tree? (In case you're
> not getting it, I want a frozen tree... *grin*)

-----

I totally agree with Chris. It's difficult for software providers to support 
Gentoo because it's a moving target. 

I have seen two statements about a frozen tree;
1 - administrators can use there own QA approved internal tree;
this is true, however this takes a lot of effort to maintain those trees. They 
need to keep up with GLSA's and backport necessary ebuilds, digest, patches, 
etc. to their tree. But most importantly software providers don't know about 
these trees and are not able to QA their software on that tree.

2 - it takes a lot of resources to maintain those trees; this is true if your 
goal is to provide ultimate stable and secure trees. Then it takes indeed a 
lot of effort because you need to test changes against every tree. There are 
other less ambitious scenarios possible;
- just branch in cvs (2004.x) and do nothing with this branch. You have at 
least accomplished one big thing and that's predictability. It takes no extra 
resources at all to maintain these branches. Software providers can test 
their products against a tree and say their products works fine on Gentoo 
<release>.
- create a branch in cvs and develop a tool that automatically backport GLSA's 
in the trees. This may not give us ultimate stable trees but at least we have 
secure and predictable trees.

I agree that Gentoo Enterprise needs to form in small steps. I believe 
creating frozen trees takes very small amount of effort but gives us huge 
gains we can build on in the future.


I suggest to take the following steps;
- create frozen trees (gain predictability)
- make Gentoo (portage) tree aware
- extend GLSA tool to automatically backport GLSA's and their fixes to the 
trees
- if financial and/or developer resources become available in the future 
backport stability fixes in the trees.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Enterprise Installer [was "LWE Aftermath" on -core]

[Michiel de Bruijne]

From the outside the installer project seems on a very long hiatus. If there 
is indeed a lot of work done behind the scene then let the world (at least 
gentoo-dev or gentoo-installer) know. The project page hasn't been updated 
since February. There was a meeting on 15 July and logs were promised but 
altough I have requested the logs several times I still haven't seen 
anything.

Managing a project isn't only about creating good software but also 
communicating with other people. With zero communication you can't blame 
other people to talk about starting an(other) installer project.


-----

On Saturday 07 August 2004 05:06, Blackace wrote:
> Shh!
>
> CondorDes, Chris: go to the Installer Project page and read :)
>
> http://www.gentoo.org/proj/en/releng/installer/index.xml
>
> And both of you go read GLEP 19 and please stop talking implementation
> when there are already people working on these things, instead read
> about what is already happening and ask questions, but leave the
> answering to the people who have already invested their time in these
> projects.
>
> Thanks ;)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Enterprise Installer [was "LWE Aftermath" on -core]

[Joshua J. Berry]

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

I've already seen that page.  The installer is merely one component in the
system I've been discussing.

After you install, you need to maintain.  I don't see anything on the installer
page to indicate that the installer project addresses that concern, or that it
addresses the option of maintaining one's own tree.

Besides which, there hasn't been a commit to the installer tree in 2 months.  If
there are people working on this, where are they and why haven't they stepped
out of the woodwork yet? ;)

On Fri, Aug 06, 2004 at 08:06:02PM -0700, Blackace wrote:
> Shh!
> 
> CondorDes, Chris: go to the Installer Project page and read :)
> 
> http://www.gentoo.org/proj/en/releng/installer/index.xml
> 
> And both of you go read GLEP 19 and please stop talking implementation
> when there are already people working on these things, instead read
> about what is already happening and ask questions, but leave the
> answering to the people who have already invested their time in these
> projects.
> 
> Thanks ;)
> -- 
> Blackace
> Gentoo Linux
> Infrastructure Developer

-----------------------------------------
Joshua J. Berry

"I haven't lost my mind -- it's backed up on tape somewhere."
    -- /usr/games/fortune

NOTE: Please do not submit this email address to any mailing
lists or websites without prior permission.  Thank you.

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