1 |
For first implementation, my vote is for #2. |
2 |
|
3 |
Of course I would have to agree with the common consensus that this |
4 |
alone would inevitably increase (at least slightly) the level of QA. |
5 |
|
6 |
It would also provide a nice vantage point for further moving in the |
7 |
direction of option #1. |
8 |
|
9 |
- Michael |
10 |
|
11 |
On Tuesday, February 3, 2004, at 03:36 PM, Kurt Lieber wrote: |
12 |
|
13 |
> All -- |
14 |
> |
15 |
> I'd like to poll the group to get your input on a question that has |
16 |
> come up |
17 |
> recently. |
18 |
> |
19 |
> There are a number of areas where Gentoo Linux could stand improvement |
20 |
> -- |
21 |
> we all know this. Two examples being discussed now are a) improved QA |
22 |
> for |
23 |
> the portage tree and b) the fact that the portage tree is very fluid |
24 |
> and |
25 |
> dynamic, which makes it more difficult to use in enterprise |
26 |
> environments. |
27 |
> |
28 |
> If you were given the choice between: |
29 |
> |
30 |
> 1) A more robust QA process for the main portage tree or |
31 |
> 2) A seperate 'server' portage tree that offered: |
32 |
> * only updated quarterly |
33 |
> * security and major bug-fixes off-cycle, but no other changes to |
34 |
> the |
35 |
> tree |
36 |
> * guaranteed minimum life of all ebuilds in the tree |
37 |
> |
38 |
> Which would you find more valuable and why? |
39 |
> |
40 |
> --kurt |
41 |
> <mime-attachment> |