| 1 |
Hi All again! |
| 2 |
|
| 3 |
Further refinement. |
| 4 |
|
| 5 |
Proposed package state levels: |
| 6 |
1. "new" - new package submitted, no peer review yet. |
| 7 |
2. "unstable" - package got over the threshold of negative votes |
| 8 |
3. "confirmed" - positive votes threshold reached |
| 9 |
4. "approved" - package was checked and approved by core group (after being |
| 10 |
confirmed) |
| 11 |
5. "core" - package is maintained via core group (all patches must go through |
| 12 |
them). Portage and supporting packages come to mind for example. |
| 13 |
"core-new" may be usefull, see below. |
| 14 |
|
| 15 |
It might be desirable to have "new-version" level, specifically for new |
| 16 |
ebuild versions, they might need special processing. However right now I |
| 17 |
cannot come up with the reasons why just marking them as "new" won't work. |
| 18 |
|
| 19 |
As specified above these pkg-state levels may be treated as new |
| 20 |
"minor-minor" number after ebuild revision number. It makes sense to |
| 21 |
incorporate this into ebuild name right before .ebuild part. |
| 22 |
|
| 23 |
In this way the package flow is as follows: new ebuild gets a "new" status |
| 24 |
until it gets enough peer-review and is considered "confirmed" and may be |
| 25 |
later even "stable". In this way many distribution stability levels are |
| 26 |
possible from more_strict_then_debian_stable to |
| 27 |
more_extreme_then_Mandrake_beta_or_RH_x.0. |
| 28 |
You are also not forced to believe just anybody. It may be usefull to assign |
| 29 |
"new" status even to the new "core" ebuilds (well, probably "core-new" will |
| 30 |
be better), which upon confirmation would get "core" status directly (they |
| 31 |
have been reviewed already). Thus you are getting not only level |
| 32 |
assumed_to_be_stable_because_I_personally_tested_it_on_whatever_was_available |
| 33 |
but you can also have level |
| 34 |
extensively_tested_by_many_people_on_many_architectures_to_be_stable. |
| 35 |
|
| 36 |
In addition I want to note, that gentoo is a true meta-distribution, so it |
| 37 |
might be desirable to create more categories along these lines to represent |
| 38 |
this. For example there might be "secure-core" level treated analogously to |
| 39 |
"core" with different core group responsible for it. |
| 40 |
|
| 41 |
It will also allow to solve such situation as there is with new kernel for |
| 42 |
example. Now it has to be masked out, so that 2.4.17-r5 is used by default. |
| 43 |
This does not look elegant and is just plain wrong on a large scale. There is |
| 44 |
nothing right-out wrong with new kernel. It is not as efficient as an old |
| 45 |
one, but it contains some new features which some people might want to use |
| 46 |
(not that much for this one, but there were such situations quite a few times |
| 47 |
with kernel versions). It would be better for it get out in the open and end |
| 48 |
up in "unstable" with the comment attached or even some special category for |
| 49 |
example "ambiguous" :-). |
| 50 |
|
| 51 |
Some reflection. |
| 52 |
Having thought about this issue for some time I start considering this to be |
| 53 |
the next necessary step for gentoo as it gains momentum. |
| 54 |
Few important things for distribution are: |
| 55 |
1. good scalable core - fine here. |
| 56 |
2. appropriate (and competent in some circumstances) user base - excellent |
| 57 |
here. |
| 58 |
3. ease of participation in development via bug reports/submissions - good |
| 59 |
here. |
| 60 |
4. easy access for EVERYBODY to new submissions for peer review - not good |
| 61 |
here. And this is the issue I try to bring up with this proposal. |
| 62 |
|
| 63 |
Key point here is pushing as much responsibility down the chain as possible. |
| 64 |
Many people will be willing to live with "confirmed" level thus reviewing new |
| 65 |
submissions and speeding up ebuild handling process. |
| 66 |
Present situation with gentoo ebuilds somewhat mirrors kernel |
| 67 |
patch-submission situation. Linus is crying out to make people to assume as |
| 68 |
much responsibility down the chain as possible and not try to push ALL |
| 69 |
patches through him directly. (I am not referencing his switch to BitKeeper, |
| 70 |
this is just a technical thing which will increase his personal throughput |
| 71 |
approx 2x, while 10x larger throughput is necessary for the whole arbitration |
| 72 |
and 100x is desirable if kernel is to continue to grow as it does now). |
| 73 |
|
| 74 |
Ok, It's been a few long submissions today, so I will just shut up now and |
| 75 |
try to limit myself to listening and answering questions only :-). |
Archives