I agree with all of fosers posts. I don't think there is enough support
to pull off an installer project at the moment. It would be better to
focus energy on the configuration tools mentioned at the last meeting.
Config interfaces should come before an installer anyways. Users who
make it through the current install will be welcomed with some nice
looking and well designed tools to make configuration of the system a
bit easier. If we somehow got a graphical installer up and running, the
users that it was ment for will become frustrated when there are no
tools available to configure different aspects of their systems.Plus as
foser said, configuration tools would be of everyday use where as an
installer is used once and then never seen again. Hopefully a project
involving the devlopment of new tools will gain momentum and draw new
developers and spill over into an installer project.
I know blubber had already been working on a run-script tool that looks
pretty nice. http://gct.sourceforge.net/ I believe there is also a gtk2/
python portage front end being developed called porthole. Since it seems
there are currently more developers interested in developing these type
of tools rather than an installer, maybe this would be a better
direction to move in for now.
On Wed, 2004-01-21 at 01:07 +0100, foser wrote:
> On Tue, 2004-01-20 at 18:53, Brandon Hale wrote:
> > Installalling a desktop is a major part of the use experience between distributions. Having a GUI installer is what I see to the the most requested feature from our users, who imo should have a large drive in our development.
> Yeah and the Gentoo installation is quite smooth. You don't spiff up
> hours of compiling much with cool spinning sandbox mouse cursors. It's a
> one time thing. The experience comes from using Gentoo mostly, not
> installing it (most users enjoy the 'hands on' nature of Gentoo
> installation anyway).
> And no, as I've said several times, I'm not against an installer for who
> cares about it, I'm concerned this project is too high profile for this
> team at this time and outside of its scope.
> > Also, I simply asked for desktop research to discuss this topic at the meeting,
> > they chose it as a topic for further review without me present. I asked it to
> > be clear that I was not aiming for the actual coding of the installer as an immediate atainable goal, this has happened and failed several times already.
> Well, it got stated more like a necessity thing, everything else being
> of secondary nature and that coming from someone formerly not even a
> member of the research team to my knowledge. Why the sudden interest to
> influence what D&R should be doing ? You must understand that you do
> have an automatic greater influence as chosen DTL lead and should be
> careful not to mold projects to your own needs instead of letting them
> > What I asked is for this excellent research team
> Isn't it a bit preliminary using such superlatives without any
> achievements to show for it?
> > to draw up clear expectations for the installer, what we want it to do, and create a roadmap for realistic completion. This will allow us to find the skilled resources needed to reach milestones, rather than isolated developers w/ their own incompatible visions of the installer.
> A good plan gets made by the skilled developers, you don't attract them
> with it. So the first step is to get the developers lined up and what i
> see in the logs that was sort of a problem to start with.
> > I believe this matches the creed of the group, in fact. Create realistic plans for a project, an idea of how it could be done, and detail this completely in a new GLEP. This is simply a first step in a Gentoo-wide installer project.
> Again, i don't say there shouldn't be an installer or something, it's
> the overemphasis that is given to it at this time. Here we have a new
> project : "let's go do something" "yeah i know something let's do this
> cool thing an installer" "so many have tried and failed and we will
> accomplish all" "all these other projects are of inferior nature, let's
> work on this till we drop".
> Why don't we pick up a few simple achievable projects to start with, it
> may not be as earth shattering but at least shows what the team can do.
> Later on when the team has worked together, got it's act up (we're all
> experimenting here) we can take a look at bigger projects.
> > WRT the menu system:
> > I believe this is also a very good initiative,
> Well, it would be hard to deny that.
> > and its scope and goals have already been sufficiently laid out.
> Pretty much.
> > There is little "research" left to be done here, what is needed is approval and implementation.
> Have you even read the GLEP ? There's little research done. It all stays
> on the level 'this would be nice and we could probably do it like that',
> but it doesn't get much further than that (no offence to the writer). It
> would be ideal to see what exactly was needed in terms of resources,
> changes in the tree, upstream support, etc. This could be done mostly
> without any coding. This GLEP can be enormously improved trough
> Anyway, I'm merely giving at as a possible reasonably achievable goal
> with direct benefits for the desktop. It's just a fact that there's too
> little resources to do this with one or two devs, it should be done by
> the desktop as a whole. In terms used earlier, it's a way to define how
> desktop research, DTL and all it's subprojects should interact to get a
> project done. And no i don't think a UI installer will be able to have
> this pilot function in a reasonable time frame.
> > Spyderous and myself will be reviewing this GLEP soon, and I am fairly confident that it will be approved and we will push for *optional* implementation in various desktop projects.
> It's a GLEP, it's not a D&R project at this time. That means it's not
> really up to you. Anyway, as DTL leads you shouldn't be reviewing and
> implied veto-ing this, you should be discussing this with all the
> relevant subprojects, give feedback, hand out possible tasks to
> subprojects and work from there. The DTL leads role in the management
> would be to support the GLEP in the management to get approval (although
> i think in this case that won't be a problem). DTL is a mediator, not a
> And then there's the issue (again have you read the GLEP ?) that it is
> not optional. We either do it or we don't. And it can only be done (read
> : approved by management) when what there is going to be is assumable
> better than what is.
> Anyway concerning this GLEP, we either hop on the bandwagon now and are
> early adopters of the technology (which sounds like the Gentoo i know -
> oh i hate myself for using such reasoning ;)-), can prove Gentoo to be a
> 'bleeding-edge' distro once again and help upstream developers getting
> this integrated as well or we hang on and eventually get there anyway.
> That's possible too. But this is how the desktop menu wise is going to
> be, that's not much of a question to me (nor should it be to you ?).
> - foser
> email@example.com mailing list
firstname.lastname@example.org mailing list