Gentoo Archives: gentoo-dev

From: Raymond Jennings <shentino@×××××.com>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Empty project: Desktop
Date: Sat, 13 Aug 2016 04:15:40
Message-Id: CAGDaZ_rntmBmWr31RxbWtJHv_ZXaEB=1RhzpyYDEuAMhrZ_RWA@mail.gmail.com
In Reply to: Re: [gentoo-dev] Empty project: Desktop by Pacho Ramos
1 I think that a superproject can serve as a good rubber-band grouping
2 construct, personlaly
3
4 On Thu, Aug 11, 2016 at 11:19 AM, Pacho Ramos <pacho@g.o> wrote:
5
6 > El jue, 11-08-2016 a las 13:15 +0300, Mart Raudsepp escribió:
7 > > [...]
8 > > It should be kept for the purposes of coordination between different
9 > > specific desktop projects and the grouping of them it provides as
10 > > subprojects.
11 > > However that doesn't mean it should have any packages in the tree
12 > > that
13 > > the desktop projects maintains itself personally, instead of one of
14 > > its
15 > > subprojects.
16 > >
17 > > One of my gentoo plans, when I have time, has been in reviving such
18 > > desktop-wide coordinations, possibly under the desktop project
19 > > banner.
20 > > E.g my started USE=gui and toolkit threads when I had time.
21 > >
22 > > Frankly, it would be weird to not have a project that broadly manages
23 > > all the desktop stuff.
24 > > We should manage this all better under a broad desktop project that
25 > > manages documentation, some policies, etc, but doesn't necessarily
26 > > have
27 > > any packages that it maintains in tree.
28 > >
29 > > If we need a new lead election per GLEP 39, I'm sure we have some
30 > > volunteers from the subprojects to throw their name in, that are
31 > > interested in having a good desktop-wide organization going on.
32 > > Myself
33 > > included.
34 > >
35 > >
36 > > Mart
37 > >
38 >
39 > Apart of me not understanding why are we reviving this that was already
40 > discussed when killing the old freedesktop-bugs herds in favor of the
41 > correct project, I don't think it makes sense to keep this concrete
42 > dead project for that potential and hypothetical changes that could
43 > benefit from it in the far future.
44 >
45 > Maybe when something of that is finally going to be done, we need that
46 > project and, in that case, you will be able of course to create your
47 > Project following the standard policy that allows to do that to any
48 > developers.
49 >
50 >
51 >