Gentoo Archives: gentoo-desktop-research

From: Joe McCann <Joe@××××××××××××.com>
To: gentoo-desktop-research@l.g.o
Subject: Re: [gentoo-desktop-research] Report of the desktop-research meeting.
Date: Wed, 21 Jan 2004 01:39:29
Message-Id: 1074627566.4725.8.camel@locahost
In Reply to: Re: [gentoo-desktop-research] Report of the desktop-research meeting. by foser
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