1 |
I agree with all of fosers posts. I don't think there is enough support |
2 |
to pull off an installer project at the moment. It would be better to |
3 |
focus energy on the configuration tools mentioned at the last meeting. |
4 |
Config interfaces should come before an installer anyways. Users who |
5 |
make it through the current install will be welcomed with some nice |
6 |
looking and well designed tools to make configuration of the system a |
7 |
bit easier. If we somehow got a graphical installer up and running, the |
8 |
users that it was ment for will become frustrated when there are no |
9 |
tools available to configure different aspects of their systems.Plus as |
10 |
foser said, configuration tools would be of everyday use where as an |
11 |
installer is used once and then never seen again. Hopefully a project |
12 |
involving the devlopment of new tools will gain momentum and draw new |
13 |
developers and spill over into an installer project. |
14 |
|
15 |
I know blubber had already been working on a run-script tool that looks |
16 |
pretty nice. http://gct.sourceforge.net/ I believe there is also a gtk2/ |
17 |
python portage front end being developed called porthole. Since it seems |
18 |
there are currently more developers interested in developing these type |
19 |
of tools rather than an installer, maybe this would be a better |
20 |
direction to move in for now. |
21 |
On Wed, 2004-01-21 at 01:07 +0100, foser wrote: |
22 |
> On Tue, 2004-01-20 at 18:53, Brandon Hale wrote: |
23 |
> |
24 |
> > 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. |
25 |
> |
26 |
> Yeah and the Gentoo installation is quite smooth. You don't spiff up |
27 |
> hours of compiling much with cool spinning sandbox mouse cursors. It's a |
28 |
> one time thing. The experience comes from using Gentoo mostly, not |
29 |
> installing it (most users enjoy the 'hands on' nature of Gentoo |
30 |
> installation anyway). |
31 |
> |
32 |
> And no, as I've said several times, I'm not against an installer for who |
33 |
> cares about it, I'm concerned this project is too high profile for this |
34 |
> team at this time and outside of its scope. |
35 |
> |
36 |
> > Also, I simply asked for desktop research to discuss this topic at the meeting, |
37 |
> > they chose it as a topic for further review without me present. I asked it to |
38 |
> > 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. |
39 |
> |
40 |
> Well, it got stated more like a necessity thing, everything else being |
41 |
> of secondary nature and that coming from someone formerly not even a |
42 |
> member of the research team to my knowledge. Why the sudden interest to |
43 |
> influence what D&R should be doing ? You must understand that you do |
44 |
> have an automatic greater influence as chosen DTL lead and should be |
45 |
> careful not to mold projects to your own needs instead of letting them |
46 |
> evolve. |
47 |
> |
48 |
> > What I asked is for this excellent research team |
49 |
> |
50 |
> Isn't it a bit preliminary using such superlatives without any |
51 |
> achievements to show for it? |
52 |
> |
53 |
> > 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. |
54 |
> |
55 |
> A good plan gets made by the skilled developers, you don't attract them |
56 |
> with it. So the first step is to get the developers lined up and what i |
57 |
> see in the logs that was sort of a problem to start with. |
58 |
> |
59 |
> > 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. |
60 |
> |
61 |
> Again, i don't say there shouldn't be an installer or something, it's |
62 |
> the overemphasis that is given to it at this time. Here we have a new |
63 |
> project : "let's go do something" "yeah i know something let's do this |
64 |
> cool thing an installer" "so many have tried and failed and we will |
65 |
> accomplish all" "all these other projects are of inferior nature, let's |
66 |
> work on this till we drop". |
67 |
> |
68 |
> Why don't we pick up a few simple achievable projects to start with, it |
69 |
> may not be as earth shattering but at least shows what the team can do. |
70 |
> Later on when the team has worked together, got it's act up (we're all |
71 |
> experimenting here) we can take a look at bigger projects. |
72 |
> |
73 |
> > WRT the menu system: |
74 |
> > I believe this is also a very good initiative, |
75 |
> |
76 |
> Well, it would be hard to deny that. |
77 |
> |
78 |
> > and its scope and goals have already been sufficiently laid out. |
79 |
> |
80 |
> Pretty much. |
81 |
> |
82 |
> > There is little "research" left to be done here, what is needed is approval and implementation. |
83 |
> |
84 |
> Have you even read the GLEP ? There's little research done. It all stays |
85 |
> on the level 'this would be nice and we could probably do it like that', |
86 |
> but it doesn't get much further than that (no offence to the writer). It |
87 |
> would be ideal to see what exactly was needed in terms of resources, |
88 |
> changes in the tree, upstream support, etc. This could be done mostly |
89 |
> without any coding. This GLEP can be enormously improved trough |
90 |
> research. |
91 |
> |
92 |
> Anyway, I'm merely giving at as a possible reasonably achievable goal |
93 |
> with direct benefits for the desktop. It's just a fact that there's too |
94 |
> little resources to do this with one or two devs, it should be done by |
95 |
> the desktop as a whole. In terms used earlier, it's a way to define how |
96 |
> desktop research, DTL and all it's subprojects should interact to get a |
97 |
> project done. And no i don't think a UI installer will be able to have |
98 |
> this pilot function in a reasonable time frame. |
99 |
> |
100 |
> > 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. |
101 |
> |
102 |
> It's a GLEP, it's not a D&R project at this time. That means it's not |
103 |
> really up to you. Anyway, as DTL leads you shouldn't be reviewing and |
104 |
> implied veto-ing this, you should be discussing this with all the |
105 |
> relevant subprojects, give feedback, hand out possible tasks to |
106 |
> subprojects and work from there. The DTL leads role in the management |
107 |
> would be to support the GLEP in the management to get approval (although |
108 |
> i think in this case that won't be a problem). DTL is a mediator, not a |
109 |
> legislator. |
110 |
> |
111 |
> And then there's the issue (again have you read the GLEP ?) that it is |
112 |
> not optional. We either do it or we don't. And it can only be done (read |
113 |
> : approved by management) when what there is going to be is assumable |
114 |
> better than what is. |
115 |
> |
116 |
> Anyway concerning this GLEP, we either hop on the bandwagon now and are |
117 |
> early adopters of the technology (which sounds like the Gentoo i know - |
118 |
> oh i hate myself for using such reasoning ;)-), can prove Gentoo to be a |
119 |
> 'bleeding-edge' distro once again and help upstream developers getting |
120 |
> this integrated as well or we hang on and eventually get there anyway. |
121 |
> That's possible too. But this is how the desktop menu wise is going to |
122 |
> be, that's not much of a question to me (nor should it be to you ?). |
123 |
> |
124 |
> - foser |
125 |
> |
126 |
> |
127 |
> -- |
128 |
> gentoo-desktop-research@g.o mailing list |
129 |
|
130 |
|
131 |
-- |
132 |
gentoo-desktop-research@g.o mailing list |