Gentoo Archives: gentoo-dev

From: Chris Gianelloni <wolf31o2@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: [gentoo-core] [RFC] New metastructure proposal
Date: Wed, 11 Apr 2007 15:22:07
Message-Id: 1176304730.8755.64.camel@inertia.twi-31o2.org
In Reply to: [gentoo-dev] Re: [gentoo-core] [RFC] New metastructure proposal by Alon Bar-Lev
1 On Wed, 2007-04-11 at 00:05 +0300, Alon Bar-Lev wrote:
2 > I don't think this is the reason people are leaving.
3
4 Agreed.
5
6 > I think people are leaving because a lack of direction.
7
8 I also agree here, but only to an extent.
9
10 > I am not aware of any goal Gentoo distribution wish to acquire. For
11 > example: Do we wish to use a mainstream distribution? Do we aim to a
12 > specific user community? Or Do we develop distribution for our use?
13
14 Currently, we do not have any real global goals set out.
15
16 > If you wish to be (And I think we should be) mainstream distribution,
17 > we should derive targets, such as QA level, response times and
18 > content.
19
20 I agree that we should definitely have some measurable goals.
21
22 > Being more modular is one technical feature to achieve better
23 > stability. But we should discuss the basics first.
24
25 Being modular in the sense of being able to easily replace code, sure.
26 Being modular in the sense stated by Alexandre, I'm not sure. I just
27 don't see how making everybody entirely independent will help us work
28 together. It just seems so counter-productive to the idea of
29 cooperation to artificially separate people off into smaller
30 territories.
31
32 > I hear a lot that open source project with unpaid developers cannot be
33 > committed to deadlines or requirements from its developers, but I
34 > disagree. There can be an open source project with high quality
35 > products and dead lines, if these properly defined.
36
37 Agreed. It works quite well within our own ranks, even, with Release
38 Engineering. The only time we really miss deadlines are due to
39 technical reasons (security, things being broken, etc) that are
40 unforeseen.
41
42 > I must disclose that in my view whenever a large group of people are
43 > doing something together, some kind of hierarchy must be in place. And
44 > I am not talking about current council, it seems that current council
45 > does not LEAD Gentoo anywhere.
46
47 I agree that we need a formal hierarchy, but must protest that the
48 current Council doesn't lead. The problem is that every time we *try*
49 to lead, we get a ton of developer backlash, which leads to things like
50 this proposal to try to reduce the Council's ability to lead. So which
51 is it? Do people want the Council to lead or not? If the answer is no,
52 then why do we even *have* a Council?
53
54 > I read that sometime in history there was an effort to impose
55 > structural format on the community, but then Daniel Robbins left?
56
57 It was the structure that we had between Daniel leaving and the current
58 Council, and it was pretty much a disaster. The ineffectual nature of
59 that structure is what led us to the current structure.
60
61 > If we wish to be a major distribution, we must grow. If we to grow we
62 > must organize our-self better, and work toward a common goal. Common
63 > goal forces decision making. Decision making forces leadership.
64 > Leadership forces vision.
65
66 I tend to think that a "common goal" isn't necessarily something that we
67 need. We do need direction, but I don't think that everyone needs to be
68 working towards the same goals, especially when we have projects that
69 are "at odds" with each other. If we focus on being the best desktop
70 distribution, what happens to embedded? Instead, we need several
71 directions, based on functional differences.
72
73 Via this sort of breakdown I could see the following:
74
75 Core system
76 Desktop
77 Server/Hardened
78 Embedded
79 Documentation
80 Release Engineering
81
82 Even these are not static. They could be changed fairly easily. These
83 groupings are done entirely by function. If we were to think of this as
84 a client/provider relationship, there would be certain functional
85 dependencies. Everybody would depend on the Core system group.
86 Everybody would depend on documentation. Release Engineering would
87 depend on everyone else. Each of these different groups would easily be
88 able to have their own goals and visions, just like divisional units
89 within a company can have different goals. Core system would be
90 interested in solidifying and stabilizing the core of Gentoo. Desktop
91 would be working towards making Gentoo more friendly to desktop users.
92 While the goals aren't necessarily mutually exclusive, they're
93 different. The same could be said for any of the other groups.
94
95 > Is there any vision?
96
97 Of course there is some vision. The Council has plenty of ideas and
98 lots of ways where we can lead Gentoo. Why don't we? Because, quite
99 frankly, we're sick of the miles of bullshit attached to every single
100 minor decision made. I'm speaking not for every member of the Council,
101 but from my own perceptions and from the grumblings I've heard from many
102 other Council members during conversations.
103
104 > Now, for your idea.
105 > When I written something similar in the past, someone told me that it
106 > was already suggested... I don't know why it wasn't accepted.
107
108 I still think it's a fairly good idea for how Gentoo should be
109 organized. I just don't see how changing our organization will solve
110 our most pressing current issues. I'd rather clean the house up a bit
111 before we decide to try to remodel it.
112
113 <snip>
114
115 The ideas of having differing metrics for different packages is really a
116 good one. It doesn't require overlays to accomplish, either. The only
117 real problem I see with it is determining how to rate the packages.
118
119 > But I believe we should first discuss the community goals, then derive
120 > a technical solution.
121
122 Agreed.
123
124 --
125 Chris Gianelloni
126 Release Engineering Strategic Lead
127 Alpha/AMD64/x86 Architecture Teams
128 Games Developer/Council Member/Foundation Trustee
129 Gentoo Foundation

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies