1 |
----- Original Message ----- |
2 |
From: "Christian Parpart" <cparpart@×××××××××.net> |
3 |
To: <gentoo-server@l.g.o> |
4 |
Sent: Tuesday, September 07, 2004 8:09 PM |
5 |
Subject: Re: [gentoo-server] Portage Maintenance |
6 |
|
7 |
On Tuesday 07 September 2004 6:40 pm, Kurt Lieber wrote: |
8 |
> On Tue, Sep 07, 2004 at 09:29:18AM -0700 or thereabouts, Mark Rudholm |
9 |
wrote: |
10 |
> > What I wanted to do was understand what the problem is. I can't decide |
11 |
> > how to respond unless I understand something about the problem first. |
12 |
> > And if the problem is a shortage of developers, as seems to be the |
13 |
> > consensus, then I have my answer. I'd be interested in hearing |
14 |
> > discussion on how that can be addressed (as a trend, not on an |
15 |
individual |
16 |
> > basis), but if we can't get past the "well, you should contribute!" |
17 |
> > stage, then obviously that discussion can't be had here. |
18 |
> |
19 |
> Speaking about ebuild upgrades, specifically, that is a problem that may |
20 |
> have a different solution. Previously, I have suggested (in other |
21 |
> channels) having a fourth tier of ebuilds in the tree (right now, we have |
22 |
> hard masked, arch masked and stable). The fourth tier would be "totally |
23 |
> untested and unsupported" and would/could consist of user-contributed |
24 |
> ebuilds. There would/could be a feedback process for these ebuilds and, |
25 |
> after a certain threshold had been reached, a fourth-tier ebuild could be |
26 |
> automatically moved into ~arch status. |
27 |
> |
28 |
> Now, whenever I bring up this idea, people tend to get too focused on the |
29 |
> implementation details and refuse to debate the idea as just that, an |
30 |
idea. |
31 |
> They want to debate what the threshold would be for automatic inclusion in |
32 |
> ~arch or what language the script should be written in. That's generally |
33 |
> when I get frustrated and move on to other things. |
34 |
> |
35 |
> So, I think there is a possibility of some sort of automated process |
36 |
> whereby users can contribute ebuilds and get them into the tree in *some* |
37 |
> fashion. However, it needs someone to take charge and try and get some |
38 |
> traction around the idea. Probably also means writing a GLEP, debating |
39 |
the |
40 |
> finer points of the implementation, etc. That person is not me. If you |
41 |
> (meaning the collective you) want to take the idea and run with it, please |
42 |
> feel free. |
43 |
> |
44 |
> OK, there's today's random thought. |
45 |
|
46 |
i watched this thread with much interest and i even wanted to reply a few |
47 |
times. |
48 |
it seems to me that the truth is somewhere in the middle. here is how i see |
49 |
it: |
50 |
|
51 |
- if an ebuild is important many users need it so there is a greater |
52 |
chance someone will contribute it. |
53 |
if a package is not that popular to be on the todo list of many ebuild |
54 |
makers, then probably we are waiting for someone to need it strong enough to |
55 |
take the initiative and build the ebuild for himself (and for the |
56 |
community). you may be that person. if you decide you are not, you don't |
57 |
need that ebuild that bad. that is exactly what applies to me :) |
58 |
|
59 |
- at first sight, the ideea of a new (and worse) tier of ebuilds seems |
60 |
appealing. but i think it would be really really a wrong move to make. if an |
61 |
ebuild is good enough it will make it to one of the other tiers, if it's |
62 |
not, you probably shouln't use it anyway so why make it available. why not ? |
63 |
because many beginners will be tempted to use it if they think they need the |
64 |
package and they will choose the "easy" way and use the "declared bad" |
65 |
ebuild. and when that will mess things up (and it probably will), who will |
66 |
be asked to offer support for the problems? yes, the developers. and instead |
67 |
of focusing on aproving "popular" ebuilds that will help the majority they |
68 |
will be stuck in the forums with problems that should not happen anyway. |
69 |
|
70 |
i must say that i am only running gentoo for my servers but believe, when i |
71 |
need a piece of software for my servers it's there, or there's a better |
72 |
option for it. |
73 |
"amateur" developers that don't have write acces to contribute to portage |
74 |
will continue to post their "home made" ebuilds on the forums and moderators |
75 |
will notice them. that's how some developers are born i guess. |
76 |
|
77 |
is there a problem with the portage tree ? maybe. but the question is not |
78 |
always only "what do we do about it?" but sometimes is this: "is this more |
79 |
important than other stuff that needs attention?" |
80 |
|
81 |
to get back on track from the theory, i am asking the author of this thread |
82 |
a question: what are those packages that were outdated for you? because we |
83 |
are on gentoo-server mailing list and we may help by aproaching the matter |
84 |
differently here. |
85 |
|
86 |
since this is my first post on any of the mailing lists i must apologize for |
87 |
my english (for this and future messages) and i fell i should also state |
88 |
that i am very happy with gentoo running on my servers. |
89 |
|
90 |
radu |