From: foser <foser@gentoo.org>
To: gentoo-desktop-research@lists.gentoo.org
Subject: Re: [gentoo-desktop-research] Report of the desktop-research meeting.
Date: Wed, 21 Jan 2004 01:07:33 +0100 [thread overview]
Message-ID: <1074643653.19556.50.camel@rivendell> (raw)
In-Reply-To: <20040120175334.GA17282@y0shi>
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
evolve.
> 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
research.
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
legislator.
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
--
gentoo-desktop-research@gentoo.org mailing list
next prev parent reply other threads:[~2004-01-21 0:07 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-20 8:54 [gentoo-desktop-research] Report of the desktop-research meeting Paul de Vrieze
2004-01-20 9:12 ` Mario Udina
2004-01-20 10:11 ` Paul de Vrieze
2004-01-20 10:40 ` foser
2004-01-20 10:48 ` Tiemo Kieft
2004-01-20 12:23 ` Donnie Berkholz
2004-01-20 13:47 ` foser
2004-01-20 14:21 ` Donnie Berkholz
2004-01-20 17:53 ` Brandon Hale
2004-01-20 19:33 ` dams
2004-01-20 19:36 ` dams
2004-01-21 0:07 ` foser [this message]
2004-01-20 19:39 ` Joe McCann
2004-01-21 10:06 ` dams
2004-01-20 12:55 ` Paul de Vrieze
2004-01-20 14:00 ` foser
2004-01-20 17:30 ` Tom Hosiawa
2004-01-21 19:57 ` Seemant Kulleen
2004-01-21 20:01 ` Donnie Berkholz
2004-01-21 22:58 ` foser
2004-01-22 0:13 ` Alastair Tse
2004-01-22 9:11 ` dams
2004-01-22 9:25 ` dams
2004-01-22 9:28 ` dams
2004-01-22 17:02 ` [gentoo-desktop-research] Installer Donnie Berkholz
2004-01-22 17:47 ` Tiemo Kieft
2004-01-22 20:45 ` Paul de Vrieze
2004-01-22 18:38 ` Scott Koch
2004-01-23 0:07 ` Tiemo Kieft
2004-01-23 15:57 ` foser
2004-01-23 17:18 ` dams
2004-01-23 19:14 ` [gentoo-desktop-research] Installer's Target user group Scott Koch
2004-01-24 0:47 ` foser
2004-01-23 20:18 ` Scott Koch
2004-01-24 14:55 ` foser
2004-01-25 0:07 ` Nathaniel McCallum
2004-01-24 19:19 ` Tom Hosiawa
2004-01-25 0:29 ` lukas
2004-01-25 1:00 ` Nathaniel McCallum
2004-01-25 1:12 ` lukas
2004-01-24 1:26 ` Steve Barnhart
2004-01-24 15:04 ` foser
2004-01-24 10:45 ` Paul de Vrieze
2004-01-24 14:50 ` foser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1074643653.19556.50.camel@rivendell \
--to=foser@gentoo.org \
--cc=gentoo-desktop-research@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox