1 |
<special note to new readers> |
2 |
|
3 |
I wonder if anyone else on this list cares to give input. (Hint: |
4 |
maintainers who really know what this is all about, drobbins, etc.). |
5 |
|
6 |
</special note> |
7 |
|
8 |
On Sat, 2002-03-30 at 00:02, Troy Dack wrote: |
9 |
> On Sat, 30 Mar 2002 10:40, Chris Johnson got a bunch of monkeys together |
10 |
> and come up with: |
11 |
> |
12 |
> http://relentless.org:8000/gentoo/forum/message?message_id=6584&forum_id=6581 |
13 |
|
14 |
<snip> |
15 |
|
16 |
> Fair enough... I realise that the -rx designations are there, however I |
17 |
> have had -rx .ebuilds fail on numerous occassions because there was simply |
18 |
> not enough testing before the ebuild was submitted to CVS. |
19 |
> |
20 |
> This is fine if you already have a package installed ... simply file a bug, |
21 |
> or slap the ebuild maintainer on IRC and in a few hours (a day or two at |
22 |
> most) the ebuild is fixed and away you go. |
23 |
> |
24 |
|
25 |
See, this whole "waiting on the maintainer" bit is what my proposal |
26 |
avoids. In general, the idea is whenever *someone* gets it to work |
27 |
right, their ebuild rises up into cvs to be tested by anyone running in |
28 |
"10 stable installs or less" mode, which will be a sizeable portion of |
29 |
the group. (My already stated threshold is in this category, e.g. if I |
30 |
saw a single successful install of OpenOffice, I'd try it!--already |
31 |
have, unsuccessfully.) |
32 |
|
33 |
> The problem comes when a new user is trying to build their system and they |
34 |
> get all these errors. We don't want to discourage newcomers by having a |
35 |
> tree of ebuilds that is not 100% stable for their first installation. |
36 |
|
37 |
In this case, the default will be to install in "more than {50|choose a |
38 |
big number} successful installs" mode, i.e. very tested versions of each |
39 |
package. Then, in the "Desktop guide" or other documents, it can be made |
40 |
clear how to get the *latest* builds by changing one's make.conf to set |
41 |
the "{10|20|50} successful installs or less" mode. |
42 |
|
43 |
> That was my main reason for suggesting seperate CVS branch(es). |
44 |
|
45 |
I'm trying to avoid branching, because that ultimately brings duplicated |
46 |
effort and communication problems, not to mention contributes to the |
47 |
slowness already alluded to (i.e "slap the maintainer on IRC to fix" |
48 |
becomes "slap the maintainer on IRC to test it and bump it to |
49 |
'stable'"). |
50 |
|
51 |
On George's scale of terms, I'm arguing for an _active system, passive |
52 |
users_ as much as possible. I don't enjoy spending my whole day |
53 |
bothering 50 maintainers to fix their packages, esp. when it's *easier* |
54 |
to fix them myself. It's just that I'm frustrated when I make a fix--and |
55 |
it goes nowhere, helps no one, and then I have to slog through web pages |
56 |
to submit a bug that gets looked at a week later... yawn. |
57 |
|
58 |
> I agree that Gentoo is not targeted at the "I've never seen linux before |
59 |
> and thought I'd give it a go" type of user (that's what RH & MDK do), but I |
60 |
> don't think we should make new users jump through too many hoops simply |
61 |
> because an ebuild maintainer has hastily submitted an ebuild -- |
62 |
> particularly for core packages (baselayout is one that comes to mind). |
63 |
|
64 |
Agreed. Baselayout/bootstrap + core systems are "maintained"; the rest |
65 |
are "free float". Besides, if what I'm saying could be implemented, |
66 |
then ebuilds with high success rates tend to stick in cvs, and ones that |
67 |
are not successful in the field get demoted and replaced. Automatically. |
68 |
|
69 |
> Perhaps a comprimise .... |
70 |
> |
71 |
> A stable/install CVS branch that is only used during the initial |
72 |
> bootstrap/build process and afterwards portage defaults to using the |
73 |
> regular CVS tree? |
74 |
|
75 |
Why a need for seperate trees: only allow the "freefloat" system to |
76 |
affect non-core packages, and when doing an install only use packages |
77 |
that have ratings of "100 successful installs or greater|'STABLE' |
78 |
blessing". This seems to solve the problem. |
79 |
|
80 |
> Still it is a refreshing way to get my linux "fix"! |
81 |
> |
82 |
> -- |
83 |
> Troy Dack |
84 |
> http://linuxserver.tkdack.com |
85 |
> |
86 |
|
87 |
Me too! Thanks for your response and participation! How can we measure |
88 |
if this conversation will be fruitfull? |
89 |
|
90 |
Chris |