1 |
On Tue, 2004-02-03 at 14:39, Paul de Vrieze wrote: |
2 |
> Basically when one maintains a farm of computers with many users that use it |
3 |
> for various purposes there are a number of issues at play: |
4 |
> - New versions could introduce new bugs that some of the users might hit |
5 |
> (going back is often a problem) |
6 |
> - New versions could remove or change features that particular users want. In |
7 |
> any case any non-bug-fix release will create some level of user confusion |
8 |
> - Install's are often image based. While it is possible to have a few changes |
9 |
> be propagated after mirror installation, bigger changes need to be included |
10 |
> on new images with all the needed testing etc. |
11 |
> - Many company policies demand new rounds of testing before a new version of |
12 |
> any package is released. The smaller the change (security fix only, usually |
13 |
> a patch of less than 30 lines), the less testing is needed. |
14 |
> - Each and every change often needs to be manually reviewed. If there is just |
15 |
> a security patch there will be no changed dependencies and less effort |
16 |
> needed for the review. |
17 |
|
18 |
I think this is a good start on documenting the various issues that we |
19 |
are trying to address. However, I think we need *specific* examples of |
20 |
these issues so we can analyze them and make sure that whatever solution |
21 |
that is chosen is indeed the best one. This all needs to be documented |
22 |
in the GLEP so that we all understand exactly what problems we are |
23 |
trying to solve. The goal must be clear. |
24 |
|
25 |
The steps we should follow are: |
26 |
|
27 |
1) document the specific issues (real examples experienced by real |
28 |
people) that we are trying to address. Document expectations that users |
29 |
have for Gentoo in a production environment. |
30 |
|
31 |
2) define requirements that need to be met for any implementation. |
32 |
|
33 |
3) have different implementations proposed by developers, users. Have |
34 |
these proposals reviewed and commented on, possibly refined. |
35 |
|
36 |
4) choose the implementation that solves the problems and best meets the |
37 |
requirements. |
38 |
|
39 |
5) develop an implementation roadmap |
40 |
|
41 |
6) implement the solution |
42 |
|
43 |
People are jumping to step #4, but I don't think that we've even |
44 |
completed step #1 yet... certainly not to the level that it needs to be |
45 |
in order for us to make sure we're making the best decision. |
46 |
|
47 |
And remember, after step #1 comes #2, defining requirements.... *then* |
48 |
step 3: proposed implementations. |
49 |
|
50 |
Long live nerdboy! |
51 |
|
52 |
Regards, |
53 |
|
54 |
Daniel |
55 |
|
56 |
|
57 |
-- |
58 |
gentoo-dev@g.o mailing list |