[gentoo-desktop-research] test

[gentoo-desktop-research] test

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 158 bytes --]


This message should be the first on the research list

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-desktop-research] test

[Gerald J. Normandin Jr.]

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

test :-D
Just making sure it works....

On Mon, 2003-10-06 at 14:59, Paul de Vrieze wrote:
> This message should be the first on the research list
-- 
GnuGP key id# C1DBDF81 available from http://pgp.mit.edu
Key Fingerprint = 2215 37C2 30EB B42D CC60  972E FC3C 749E C1DB DF81

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

Re: [gentoo-desktop-research] test

[Luca Barbato]

Seems working fine.
anybody had already a roadmap to discuss?

some point that come to mind in random order are:
- ethernet/wify quickswitch gui
- cpufreq gui
the others that come up on irc were a unified backend for configuration 
with multple front-ends (console,X,fb?), guided installer, menu 
integration and other freedesktop.org proposed infrastructure.
Did I forgot anything
(already 2 test message done, I want to make a third with something 
inside just to start discussions)

lu

Gerald J. Normandin Jr. wrote:
> test :-D
> Just making sure it works....
> 
> On Mon, 2003-10-06 at 14:59, Paul de Vrieze wrote:
> 
>>This message should be the first on the research list


-- 
Luca Barbato
Developer
Gentoo Linux				http://www.gentoo.org/~lu_zero




--
gentoo-desktop-research@gentoo.org mailing list

Re: [gentoo-desktop-research] test

[Tiemo Kieft]

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

Works fine :)

As I already said in #gentoo-desktop I am currently creating a set of
graphical configuration tools for gentoo. I started this project long
before I heard of the Desktop/research project, but I think it fits in
fine. So I'll give a short description of it, and maybe you can give me
some input.
Well the primary goal is the make a couple of GUI tools to administrate
Gentoo Linux boxes. The tools I had in mind are
- A runlevel editor, which is already in a working state.
- Portage manager, which enables a users to control the settings in his
/etc/make.conf. It has builtin use var browser, and mirrorselet.
- User editor, to manage user accounts on a system
- GUI frontend to ebuild.

Currently only the runlevel editor is working. You can take a look at
the project page at http://gct.sf.net, and you can take a look at
screenshot: http://blubber.student.utwente.nl/~blubber/gct.png

Well, let me now what you think :)

Greetings,
Blubber
 


-- 
Gentoo developer
Tiemo Kieft <blubber@gentoo.org>
http://dev.gentoo.org/~blubber/

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

Re: [gentoo-desktop-research] test

[dams]

Paul de Vrieze <pauldv@gentoo.org> said:

> This message should be the first on the research list


Paul de Vrieze <pauldv@gentoo.org> said:

> This message should be the first on the research list

It is.

I think the first task (
http://www.gentoo.org/proj/en/desktop/research/index.xml ) can be considerd as
finished. I have updated the members list.

Now the next steps should be :

- find a better formulation for the main goal (which is not good enough imo)
- discuss about what wil be a usuall desktop research task
- set up guidelines to be able to describe, follow, document, advertize the
  task
- find some global different directions of research
- begin work on these directions, opening precises tasks, and start working.

I kind of like organized things, like maintaining a task list with end date and
milestone. I whish the discussion about guidelines keep that as main concern,
to avoid tons of good ideas to be unknown or forgotten.

About this mailing list, I think we could use it for brainstorming and also for
task handling/discussion. We could think about some formated topic to specify
the task. Like :

[gentoo-desktop-research] [Task #n] Task title

wdyt? any stuff I missed?

Of course we can start brainstorming like others already did.

PS : sorry for my mail address (@idm), but it seemed a little pb with mu
subscription onf the mailing list appeared, and also with my 2 mails (@gentoo
and @idm). Anyway, I'm still the same dams, even with different address.

-- 
dams

--
gentoo-desktop-research@gentoo.org mailing list

Re: [gentoo-desktop-research] test

[dams]

Tiemo Kieft <blubber@gentoo.org> said:

> Works fine :)
>
> As I already said in #gentoo-desktop I am currently creating a set of
> graphical configuration tools for gentoo. I started this project long
> before I heard of the Desktop/research project, but I think it fits in
> fine. So I'll give a short description of it, and maybe you can give me
> some input.
> Well the primary goal is the make a couple of GUI tools to administrate
> Gentoo Linux boxes. The tools I had in mind are
> - A runlevel editor, which is already in a working state.
> - Portage manager, which enables a users to control the settings in his
> /etc/make.conf. It has builtin use var browser, and mirrorselet.
> - User editor, to manage user accounts on a system
> - GUI frontend to ebuild.
>
> Currently only the runlevel editor is working. You can take a look at
> the project page at http://gct.sf.net, and you can take a look at
> screenshot: http://blubber.student.utwente.nl/~blubber/gct.png
>
> Well, let me now what you think :)

I think it's a good work, but that needs to be more integrated. The main
problem of config tools is that they are most of the time "one shot" programs,
that have one User Interface, works for one version, and is built from scratch
(even using GUI toolkits).

I propose that config tools relies on libconf, which provide powerfull feature
to change config datas, respect software version (behave differently for samba
2 and samba 3), permits data validation (make sure an IP field is valid...) and
- maybe the most interesting- provides UI widget corresponding to the best way
to represent some information. For exemple, for the brwsable property of a
samba share, because it can only be yes or no, libconf will give you a
checkbox. For the 'remote announce' field of the smb.conf file, it's a list of
IP or mask informations. libconf will provide a complete widget presenting a
list of entries that can be added, modified, deleted, and that will only accept
data conforming to the IP/MASK type.

libconf can do other usefull things. A config tools based on libconf benefits
of the ease of use of config files interaction, GUI generation, data
validation, and config information. libconf is also distro independant
(although configuration for other distro is not available for now). So that
your config tools should be portable without any effort.

Now the drawbacks :)
- It's only pure perl for now, I need to develop python and C connection.
- data validation is long to write for config tools with enormous different
fields like samba.
- It only provide gtk2 widget for perl-gtk (but the C or python connection
should not difficult to do)
- The console GUI should be done using cursed-Gtk, but it's still been tested.


-- 
dams

--
gentoo-desktop-research@gentoo.org mailing list

Re: [gentoo-desktop-research] test

[Luca Barbato]

Gerald J. Normandin Jr. wrote:
> Well, I think first.. a policy should be that all devs who send mails on
> this list be signed with a key, so as to maintain the integrity of
> comments on the list.
gpg?
> 
> 
> Main Goal in my mind, should be research on the various positive aspects
> of other distros (integration, configuration, various others) and
> attempt at recommending ways to improve those, and incorporate them into
> the Gentoo Distribution.Other than that, the goal mentioned suits well. 
> 

I suggest to think about the problems first, see how the other distro 
solved them and then find a solution that takes in account what the 
other did but also what they fail to accomplish.

so Research fields should be, IMHO, problems&solution from the others,

> Usual Desktop Research Task:
> 1. Research	  (Self Explanatory)
> 2. Evaluation	  (Discussion, of the topic, or research)
> 3. Recommendation (Recommended course of action)
> 4. Proposal (The actual paper outlining the above, to be sent to the
> appropriate personnel)
> 

Instead of paper proposal I'd like to have prototypes or test concepts, 
if possible.

lu

-- 
Luca Barbato
Developer
Gentoo Linux				http://www.gentoo.org/~lu_zero




--
gentoo-desktop-research@gentoo.org mailing list

Re: [gentoo-desktop-research] test

[Gerald J. Normandin Jr.]

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

Well, I think first.. a policy should be that all devs who send mails on
this list be signed with a key, so as to maintain the integrity of
comments on the list.


Main Goal in my mind, should be research on the various positive aspects
of other distros (integration, configuration, various others) and
attempt at recommending ways to improve those, and incorporate them into
the Gentoo Distribution.Other than that, the goal mentioned suits well. 

Usual Desktop Research Task:
1. Research	  (Self Explanatory)
2. Evaluation	  (Discussion, of the topic, or research)
3. Recommendation (Recommended course of action)
4. Proposal (The actual paper outlining the above, to be sent to the
appropriate personnel)

What is meant by "find some global different directions of research"?

On Tue, 2003-10-07 at 03:28, dams@idm.fr wrote:
> Paul de Vrieze <pauldv@gentoo.org> said:
> 
> > This message should be the first on the research list
> 
> 
> Paul de Vrieze <pauldv@gentoo.org> said:
> 
> > This message should be the first on the research list
> 
> It is.
> 
> I think the first task (
> http://www.gentoo.org/proj/en/desktop/research/index.xml ) can be considerd as
> finished. I have updated the members list.
> 
> Now the next steps should be :
> 
> - find a better formulation for the main goal (which is not good enough imo)
> - discuss about what wil be a usuall desktop research task
> - set up guidelines to be able to describe, follow, document, advertize the
>   task
> - find some global different directions of research
> - begin work on these directions, opening precises tasks, and start working.
> 
> I kind of like organized things, like maintaining a task list with end date and
> milestone. I whish the discussion about guidelines keep that as main concern,
> to avoid tons of good ideas to be unknown or forgotten.
> 
> About this mailing list, I think we could use it for brainstorming and also for
> task handling/discussion. We could think about some formated topic to specify
> the task. Like :
> 
> [gentoo-desktop-research] [Task #n] Task title
> 
> wdyt? any stuff I missed?
> 
> Of course we can start brainstorming like others already did.
> 
> PS : sorry for my mail address (@idm), but it seemed a little pb with mu
> subscription onf the mailing list appeared, and also with my 2 mails (@gentoo
> and @idm). Anyway, I'm still the same dams, even with different address.
-- 
GnuGP key id# C1DBDF81 available from http://pgp.mit.edu
Key Fingerprint = 2215 37C2 30EB B42D CC60  972E FC3C 749E C1DB DF81

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

Re: [gentoo-desktop-research] test

[Paul de Vrieze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 09 October 2003 01:08, Luca Barbato wrote:
>
> I suggest to think about the problems first, see how the other distro
> solved them and then find a solution that takes in account what the
> other did but also what they fail to accomplish.
>
> so Research fields should be, IMHO, problems&solution from the others,
>

I do not think that we should focus on what other distro's do. We should focus 
on identifying problems that are there. After such a problem is identified we 
should try to determine whether we think this problem needs to be solved by 
gentoo (keeping the gentoo and desktop-research goals in mind). After that we 
need to look at the solution to the problem. At this stage comes looking at 
solutions by other distros.

This solving process has a number of stages. The first one being the 
identification of possible solutions, and their costs (how much work are 
they, and how "beautiful" are they etc.). Then we choose one solution to 
implement and test. This involves trying to get approval by the people from 
the projects that will be involved when it is actually put into gentoo. After 
the test is successful, we are going to put it into the main tree, and put it 
into action. Putting it into action involves making sure that our solution 
will be maintained, if necessary by creating a team to do that maintenance.

However before we can think of finding problems, we first need to have a 
policy on the following points:
- - Which problems do we handle? We only handle desktop problems, but when does
  a problem qualify as being desktop.
- - How do we handle problems? Basically, do we follow the process described
  above, or some other process.
- - What are the conditions for a solution to be acceptable.
- - Will we have a seperate cvs testing tree (overlay)?
- - How are we going to make sure that the solutions get out of the testing
  tree, and in to the main distribution? Will we use GLEP's?

Paul

ps. I know it is nicer to think of solutions than of problems, and nicer to 
think of problems than of procedures, but first things should go first. And 
procedure comes first.

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/hRv7bKx5DBjWFdsRAlt0AJ497K4aJ0OsqeDCkZ5WyU3Y2RWj0QCgl6y+
/z0FjWITQ519n12vLFBPyCw=
=3UH4
-----END PGP SIGNATURE-----


--
gentoo-desktop-research@gentoo.org mailing list

Re: [gentoo-desktop-research] test

[dams]

[ sorry my mails are not yet signed, but will be soon ]

Paul de Vrieze <pauldv@gentoo.org> said:

> On Thursday 09 October 2003 01:08, Luca Barbato wrote:
>>
>> I suggest to think about the problems first, see how the other distro
>> solved them and then find a solution that takes in account what the
>> other did but also what they fail to accomplish.
>>
>> so Research fields should be, IMHO, problems&solution from the others,
>>
>
> I do not think that we should focus on what other distro's do. We should focus 
> on identifying problems that are there. After such a problem is identified we 
> should try to determine whether we think this problem needs to be solved by 
> gentoo (keeping the gentoo and desktop-research goals in mind). After that we 
> need to look at the solution to the problem. At this stage comes looking at 
> solutions by other distros.

I agree with that process.

>
> This solving process has a number of stages. The first one being the 
> identification of possible solutions, and their costs (how much work are 
> they, and how "beautiful" are they etc.). Then we choose one solution to 
> implement and test. This involves trying to get approval by the people from 
> the projects that will be involved when it is actually put into gentoo. After 
> the test is successful, we are going to put it into the main tree, and put it 
> into action. Putting it into action involves making sure that our solution 
> will be maintained, if necessary by creating a team to do that maintenance.
>
> However before we can think of finding problems, we first need to have a 
> policy on the following points:
> - Which problems do we handle? We only handle desktop problems, but when does
>   a problem qualify as being desktop.

For me, a desktop problem is not always a problem wich involve window managers,
or graphical interface.

I would tend to say that desktop means workstation for private use, client
side. That is, everything UI oriented. That includes windows manager, but also
config programs, installation problems, software installations, and simple
(client-side personal use) system managment. By client side I mean everything
that does not use servers. So setting internet/lan connection is desktop, but
setting a ftp server is not.

Maybe you have an other vision?


> - How do we handle problems? Basically, do we follow the process described
>   above, or some other process.

I think the above process is not bad at all. So that could be :

- define the problem
- look if it has not being resolved, or if nobody is working on it, inside gentoo
- look for similar problem inside gentoo
- look for similar problems outside gentoo (official software author, other
  distro)
- find a way to solve it, by discussing it here or #irc (taht would be the
  Evaluation part of gerrynjr)
- allocate people on it, plan the solving time.
- write proposal/recommendations to gentoo main
- fo the main inclusion, I have no precise ideas.

> - What are the conditions for a solution to be acceptable.
doesn't break things, gentoo way of thinking/developping compliant, doesn't
break the desktop taste.

The gentoo desktop taste is something we might want to describe. It can be
vanilla desktop plus some little not much visible features, or (waht I
prefer), vanilla desktop with pluggable features that changes the
appearence/feel. We'll have to make technical coice on it

> - Will we have a seperate cvs testing tree (overlay)?

I don't know, what do you think?

> - How are we going to make sure that the solutions get out of the testing
>   tree, and in to the main distribution? Will we use GLEP's?

why not, but maybe new ebuilds/doc, with official maintainers could suffice?


>
> Paul
>
> ps. I know it is nicer to think of solutions than of problems, and nicer to 
> think of problems than of procedures, but first things should go first. And 
> procedure comes first.

100% agreed on that, but I don't want to enforce anybody :)

-- 
dams

--
gentoo-desktop-research@gentoo.org mailing list

Re: [gentoo-desktop-research] test

[foser]

On Thu, 2003-10-09 at 15:00, dams@idm.fr wrote:
> [ sorry my mails are not yet signed, but will be soon ]

Humm, isn't this a bit weird requirement ? Is this a closed list or not
? I'm not much of a signer.

> I think the above process is not bad at all. So that could be :
> 
> - define the problem
> - look if it has not being resolved, or if nobody is working on it, inside gentoo
> - look for similar problem inside gentoo
> - look for similar problems outside gentoo (official software author, other
>   distro)
> - find a way to solve it, by discussing it here or #irc (taht would be the
>   Evaluation part of gerrynjr)
> - allocate people on it, plan the solving time.
> - write proposal/recommendations to gentoo main

Should go trough DTL (whatever it turns out to be) first.

> - fo the main inclusion, I have no precise ideas.

> > - Will we have a seperate cvs testing tree (overlay)?
> 
> I don't know, what do you think?

implementation details..  this is not something that should be solver on
a per project basis, but distro wide.

> > - How are we going to make sure that the solutions get out of the testing
> >   tree, and in to the main distribution? Will we use GLEP's?
> 
> why not, but maybe new ebuilds/doc, with official maintainers could suffice?

No question we should use GLEPs, that's what they are for.

- foser


--
gentoo-desktop-research@gentoo.org mailing list

Re: [gentoo-desktop-research] test

[Paul de Vrieze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 09 October 2003 15:00, dams@idm.fr wrote:
> [ sorry my mails are not yet signed, but will be soon ]
>
> For me, a desktop problem is not always a problem wich involve window
> managers, or graphical interface.
>
> I would tend to say that desktop means workstation for private use, client
> side. That is, everything UI oriented. That includes windows manager, but
> also config programs, installation problems, software installations, and
> simple (client-side personal use) system managment. By client side I mean
> everything that does not use servers. So setting internet/lan connection is
> desktop, but setting a ftp server is not.
>
> Maybe you have an other vision?

No I agree. This would imho also involve things like the soundsystem etc.

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/hWGgbKx5DBjWFdsRAqsIAJ48rc58sY3EUmFdLsN9q8uWuMhkMACdG8G4
No5iVk/ekw02oDKqZUnP+Dc=
=iwIO
-----END PGP SIGNATURE-----


--
gentoo-desktop-research@gentoo.org mailing list

Re: [gentoo-desktop-research] test

[Paul de Vrieze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 09 October 2003 15:15, foser wrote:
> On Thu, 2003-10-09 at 15:00, dams@idm.fr wrote:
> > [ sorry my mails are not yet signed, but will be soon ]
>
> Humm, isn't this a bit weird requirement ? Is this a closed list or not
> ? I'm not much of a signer.
>

I sign, but have no problem at all if people don't. For me it is not necessary 
to require it.

> > - define the problem
> > - look if it has not being resolved, or if nobody is working on it,
> > inside gentoo - look for similar problem inside gentoo
> > - look for similar problems outside gentoo (official software author,
> > other distro)
> > - find a way to solve it, by discussing it here or #irc (taht would be
> > the Evaluation part of gerrynjr)
> > - allocate people on it, plan the solving time.
> > - write proposal/recommendations to gentoo main
>
> Should go trough DTL (whatever it turns out to be) first.

I think indeed a solution proposal should go through the desktop lead. I do 
however see no need if we decide that a problem is not really a problem at 
all, so it should come somewhere near the place where we choose a solution 
that is to be implemented. Maybe give some notice beforehand to get 
confirmation that the destop lead indeed finds it a problem worthy of 
solving.

>
> implementation details..  this is not something that should be solver on
> a per project basis, but distro wide.

There are ideas floating around to do this distro wide. However if no-one 
pushes for it, it will happen "sometime".

>
> No question we should use GLEPs, that's what they are for.

Ok, I agree. This also automatically gives the desktop lead a place.

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/hWOFbKx5DBjWFdsRAscmAKCeurFkWFnds4IWbEWmD350r0QPSACgk7st
dOmYWMZ0nL2jr6arjtvRujw=
=td+2
-----END PGP SIGNATURE-----


--
gentoo-desktop-research@gentoo.org mailing list

Re: [gentoo-desktop-research] test

[dams]

Paul de Vrieze <pauldv@gentoo.org> said:

> On Thursday 09 October 2003 15:15, foser wrote:
>> On Thu, 2003-10-09 at 15:00, dams@idm.fr wrote:
>> > [ sorry my mails are not yet signed, but will be soon ]
>>
>> Humm, isn't this a bit weird requirement ? Is this a closed list or not
>> ? I'm not much of a signer.
>>
>
> I sign, but have no problem at all if people don't. For me it is not necessary 
> to require it.

Ok, neither for me it is. I didn't required it, gerrynjr asked it :) I'll try
to sign mine for other reasons.

>
>> > - define the problem
>> > - look if it has not being resolved, or if nobody is working on it,
>> > inside gentoo - look for similar problem inside gentoo
>> > - look for similar problems outside gentoo (official software author,
>> > other distro)
>> > - find a way to solve it, by discussing it here or #irc (taht would be
>> > the Evaluation part of gerrynjr)
>> > - allocate people on it, plan the solving time.
>> > - write proposal/recommendations to gentoo main
>>
>> Should go trough DTL (whatever it turns out to be) first.
>

what's a DTL ?

> I think indeed a solution proposal should go through the desktop lead. I do 
> however see no need if we decide that a problem is not really a problem at 
> all, so it should come somewhere near the place where we choose a solution 
> that is to be implemented. Maybe give some notice beforehand to get 
> confirmation that the destop lead indeed finds it a problem worthy of 
> solving.

agreed. what should be the notice then? GLEP proposal to desktop lead?

>
>>
>> implementation details..  this is not something that should be solver on
>> a per project basis, but distro wide.
>
> There are ideas floating around to do this distro wide. However if no-one 
> pushes for it, it will happen "sometime".
>
>>
>> No question we should use GLEPs, that's what they are for.
>
> Ok, I agree. This also automatically gives the desktop lead a place.

ok then, go for it

-- 
dams

--
gentoo-desktop-research@gentoo.org mailing list

Re: [gentoo-desktop-research] test

[dams]

Paul de Vrieze <pauldv@gentoo.org> said:

> On Thursday 09 October 2003 15:00, dams@idm.fr wrote:
>> [ sorry my mails are not yet signed, but will be soon ]
>>
>> For me, a desktop problem is not always a problem wich involve window
>> managers, or graphical interface.
>>
>> I would tend to say that desktop means workstation for private use, client
>> side. That is, everything UI oriented. That includes windows manager, but
>> also config programs, installation problems, software installations, and
>> simple (client-side personal use) system managment. By client side I mean
>> everything that does not use servers. So setting internet/lan connection is
>> desktop, but setting a ftp server is not.
>>
>> Maybe you have an other vision?
>
> No I agree. This would imho also involve things like the soundsystem etc.

yes that's right, bringing hardware to work for home user is also part of the
job.

-- 
dams

--
gentoo-desktop-research@gentoo.org mailing list

Re: [gentoo-desktop-research] test

[foser]

On Thu, 2003-10-09 at 15:55, dams@idm.fr wrote:
> what's a DTL ?

Desktop TopLevel

> 
> > I think indeed a solution proposal should go through the desktop lead. I do 
> > however see no need if we decide that a problem is not really a problem at 
> > all, so it should come somewhere near the place where we choose a solution 
> > that is to be implemented. Maybe give some notice beforehand to get 
> > confirmation that the destop lead indeed finds it a problem worthy of 
> > solving.
> 
> agreed. what should be the notice then? GLEP proposal to desktop lead?

Hmm no, proposal to DTL, then write a GLEP, if it gets rejected already
there's work done for nothing. In practice this could already be the
GLEP outline in it's raw form.

- foser


--
gentoo-desktop-research@gentoo.org mailing list

Re: [gentoo-desktop-research] test

[dams]

foser <foser@gentoo.org> said:

> On Thu, 2003-10-09 at 15:55, dams@idm.fr wrote:
>> what's a DTL ?
>
> Desktop TopLevel
>
>> 
>> > I think indeed a solution proposal should go through the desktop lead. I do 
>> > however see no need if we decide that a problem is not really a problem at 
>> > all, so it should come somewhere near the place where we choose a solution 
>> > that is to be implemented. Maybe give some notice beforehand to get 
>> > confirmation that the destop lead indeed finds it a problem worthy of 
>> > solving.
>> 
>> agreed. what should be the notice then? GLEP proposal to desktop lead?
>
> Hmm no, proposal to DTL, then write a GLEP, if it gets rejected already
> there's work done for nothing. In practice this could already be the
> GLEP outline in it's raw form.

ok, sorry for the misunderstanding

-- 
dams

--
gentoo-desktop-research@gentoo.org mailing list