1 |
Karl Trygve Kalleberg wrote: |
2 |
> Hi gang. |
3 |
> |
4 |
> I just like to voice my opinion about issues that should be addressed |
5 |
> before the release of Gentoo Linux 1.0 (hurrah!) |
6 |
> |
7 |
> While I can to a large degree accept that the distro itself is technically |
8 |
> ready enough to be released, our development team is in no way prepared to |
9 |
> handle the influx of new users. |
10 |
> |
11 |
> At minimum, we should have the following points fixed: |
12 |
> 1) A proper bug-reporting system. We simply won't be able to keep track of |
13 |
> the issues cropping up in gentoo-{dev,users,ebuild,whatever} given the |
14 |
> current developer situation. |
15 |
|
16 |
bugzilla _could_ handle this, but while it is technically ready enough |
17 |
our development team is in no way prepared to handle the influx of new |
18 |
users that would find it a pain in the neck to use. |
19 |
|
20 |
> 2) A flawless installation guide. This means that we should do the |
21 |
> installation of the 1.0 version in a handful of different configurations |
22 |
> and make certain the installation guide is not only correct, but succinct |
23 |
> and unambiguous. This is tricky, but every hour we spend fixing it before |
24 |
> final release, will save us tenfold down the line. |
25 |
|
26 |
Personally, I was surprised at the quality of the 1.0_rc6 install from |
27 |
source guide. Could be some improvements, but it is a nice place to |
28 |
start from. |
29 |
|
30 |
> 3) Verify that all our ebuilds actually work as advertised. Some ebuilds |
31 |
> seem to be more error-prone than others (minicom, koffice). The ones that |
32 |
> have any problems whatsoever should be masked out until we know that they |
33 |
> really work. |
34 |
|
35 |
A good way for ebuild to handle apps that dont flag/opt well would be |
36 |
nice, other than hard coding everything :) Like if a build is known to |
37 |
spark out when a given portion is compiled -O3, knock it down to -O2 |
38 |
(IOW ebuild parses out flags in make.conf and handles wisely, according |
39 |
to the writers instructions.) |
40 |
|
41 |
> 4) In a related note, we should have a |
42 |
> "grace-period"/"codeslush"/"codefreeze" of at least one week where we do |
43 |
> not add new stuff, and do nothing but bug-squashing. We should verify that |
44 |
> *all* ebuilds have been tested, preferrably with *all* their optional USE |
45 |
> arguments. |
46 |
|
47 |
You are out of your mind. One week? DUDE! This is a 1.0 release of |
48 |
what could be a major mainstream linux distribution. One week? |
49 |
|
50 |
> 5) We should have a release plan on the web, a task-list if you will, |
51 |
> where we check off items as we progress along to 1.0. This will hopefully |
52 |
> work as a great motivator once we're over half-way ;) |
53 |
|
54 |
Yes, and the idea is that up until the very minute that feature freeze |
55 |
goes into effect, anything and everything goes on that list. Someone |
56 |
gets the slightest little notion of something that'd be cool and POOF!, |
57 |
on the list. Just that stuff more whimish than others would be in a |
58 |
diff priority class for obvious reasons. |
59 |
|
60 |
> 6) We should officially nominate a Release Manager (I guess this will be |
61 |
> drobbins, but it would be nice for everybody, including non-developers, ie |
62 |
> hardcore Gentoo testers to know who's neck is on the block ;). |
63 |
|
64 |
> 7) Perhaps we even should have a release team that acted as drobbins' |
65 |
> elven helpers and make certain that all the items on the task-list are |
66 |
> addressed in a timely fashion. Perhaps all the developers should just act |
67 |
> as elven helpers.. |
68 |
|
69 |
Who is in charge of evangelism and propoganda right now? |
70 |
|
71 |
> |
72 |
> Hope this sets thoughts churning. If we want 1.0 to be stable and good, we |
73 |
> will have to put a lot of effort into it, and do so in a structured |
74 |
> fashion. The all-nighter "throw code at it until it works" is NOT an |
75 |
> option. |
76 |
> |
77 |
|
78 |
It's not? awwwwwwwww. ;P |