1 |
On Tuesday 22 April 2003 15:59, Frantz Dhin wrote: |
2 |
> I feel that this is one of the |
3 |
> reasons that we have an unstable branch, or maybe we could make a new |
4 |
> keyword? x86 for stable, ~x86 for unstable, and ^x86 for lunatic? :) |
5 |
|
6 |
Just a quick note (without addressing your main point). ~arch is _not_ |
7 |
"unstable". It is not supposed to be unstable in the literal meaning of the |
8 |
word. It is 'testing', or 'works for me'. Developers can _not_ commit things, |
9 |
or leave things, unmasked in ~x86 that have known issues, or that are |
10 |
alpha-quality releases from upstream. (This doesn't apply directly to what |
11 |
you were saying, I just don't like to see it called unstable...) |
12 |
|
13 |
---- |
14 |
|
15 |
Now to the main issue. The main reason why submitted ebuilds aren't getting |
16 |
into portage easily and quckly is not the need for testing before committing. |
17 |
It is that the person committing that ebuild, or _some_ other developer, will |
18 |
have to maintain it later on. That means being responsible for problems with |
19 |
it (and there are always some problems eventually), and processing future |
20 |
updates/bureports/feature requests etc. |
21 |
|
22 |
These require that developer to be well acquianted with the ebuild. If the app |
23 |
is nontrivial, and there are several such under this developer's care, it can |
24 |
get quite troublesome. And remember this developer generally does not use |
25 |
these apps himself - or he would have added an ebuild without waiting for a |
26 |
user submission. |
27 |
|
28 |
The points you and other people make in this thread are known and acknowledged |
29 |
by us. We are busily working towards a setup that solves these problems. The |
30 |
first step is the upcoming (I hope) reorganization of the gentoo internal |
31 |
development model so that every ebuild has explicit maintainer(s). The second |
32 |
will facilitate quick acceptance of user-submitted ebuilds in some way - |
33 |
probably drawing upon the submitters in one way or another. |
34 |
|
35 |
The implementation of this second step depends (imo) on the first, which is |
36 |
being busily discussed for the past week. Please give us time to put it into |
37 |
place before we move into the second phase, which is when user opinions/ideas |
38 |
will be heard properly. |
39 |
|
40 |
-- |
41 |
Dan Armak |
42 |
Gentoo Linux developer (KDE) |
43 |
Matan, Israel |
44 |
Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key |