| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
george (et al.), |
| 5 |
|
| 6 |
On Tuesday 27 August 2002 00:24, George Shapovalov wrote: |
| 7 |
> original authors of the packages. It would be a life in heaven |
| 8 |
> if everything installed via "./configure && make && make |
| 9 |
> install". All packages would compile on any arch and glibc/gcc |
| 10 |
> version and no weir dependencies were lost in docs and nothing |
| 11 |
> would conflict... |
| 12 |
|
| 13 |
ack. |
| 14 |
|
| 15 |
> Well, you get the idea. Unfortunately this |
| 16 |
> is our imperfect word where everything tends to break and |
| 17 |
|
| 18 |
ack. nevertheless i'd like to add that gentoo is particularly and |
| 19 |
implicitly vulnerable to such issues as some troubles are |
| 20 |
"home-made by concept". |
| 21 |
|
| 22 |
1) gentoo uses performance optimizations by default (which |
| 23 |
sometimes lead to non-deterministic, non-reproducible results |
| 24 |
which are particularly hard to track down and solve, e.g. |
| 25 |
parallel make) |
| 26 |
|
| 27 |
2) gentoo users usually further tweak their systems (aggressive |
| 28 |
gcc flags, ...) |
| 29 |
|
| 30 |
3) while better performance is desirable one must be aware (i |
| 31 |
think most gentooers are) that things tend to be less stable, |
| 32 |
less predictable the more aggressive and uncommon the |
| 33 |
performance optimizations are. |
| 34 |
|
| 35 |
gentoo also uses the latest app releases which are less |
| 36 |
thouroughly tested by nature and consequences not entirely clear |
| 37 |
from the beginning (introduction of non-backwards-compatible |
| 38 |
changes, e.g. libvorbis). |
| 39 |
|
| 40 |
now i do not say that this is bad practice or a conceptually |
| 41 |
wrong, i just say that this implicitly means that gentoo is a |
| 42 |
"bleeding edge" distro and that this is gentoo's (and its |
| 43 |
community's) own decision (thus no self-pity, please ;) |
| 44 |
|
| 45 |
the same goes for greater flexibility which is fine but makes |
| 46 |
*any* testing approach pretty tough to unmanageable (see |
| 47 |
combinatorics ;). in real world, there will always be a |
| 48 |
trade-off between performance optimizations, flexibility and |
| 49 |
stability. |
| 50 |
|
| 51 |
> changes were implemented in this new revision? Things will get |
| 52 |
> better when we release 1.4, however I am afraid not by much. |
| 53 |
|
| 54 |
well, it's some bad luck currently with these horrible gcc 2.95.3 |
| 55 |
- -> gcc 3.1 -> gcc 3.2 changes. as the gcc devs have declared to |
| 56 |
take better care of backwards compatibility in the future, i |
| 57 |
hope things will stabilize. |
| 58 |
|
| 59 |
> The point I am getting at here is that we should and can allow |
| 60 |
> our users to take care of a large portion of non-crytical |
| 61 |
> packages. What we need is: 1. Multiple stability levels or |
| 62 |
> KEYWORDS |
| 63 |
|
| 64 |
ack. |
| 65 |
|
| 66 |
> 2. Streamlined ebuild processing - that automates submission |
| 67 |
> of new ebuilds/versions and assigns them some kind of "new" or |
| 68 |
> "user-test" keyword/level |
| 69 |
|
| 70 |
ack. |
| 71 |
|
| 72 |
> 3.Feedback system that collects user voices and moves ebuilds |
| 73 |
> to corresponding categories increasing or decreasing their |
| 74 |
> stability rating. |
| 75 |
|
| 76 |
ack. the barrier for giving feedback should be as low as possible |
| 77 |
and feedback should be given instantly. i.e. emerge should give |
| 78 |
the user an option to send a standardized bug-report by more or |
| 79 |
less just hitting enter when an ebuild fails (i think this has |
| 80 |
been discussed several times on this list already). |
| 81 |
|
| 82 |
rule: you can always trash submitted, bad (useless) bug-reports |
| 83 |
but you can't get bug-reports that were not submitted. |
| 84 |
standardizing bug-reports should also help in improving their |
| 85 |
quality. |
| 86 |
|
| 87 |
> 4. Core group oversees and takes care of the |
| 88 |
> core/crytical stuff and has *much* more time to work |
| 89 |
> onportage/sysinit/other_more_distro_specifc_stuff Well, that |
| 90 |
> would be one possible point of view on this :). |
| 91 |
|
| 92 |
addendum regarding qa: perhaps a more process-oriented |
| 93 |
organization would help improving qa and take some pressure from |
| 94 |
core-devs? has this ever been evaluated? how is qa organized |
| 95 |
atm? |
| 96 |
|
| 97 |
disclaimer: i do not know how gentoo-core is really organized (i |
| 98 |
do not think anybody outside of gentoo-core does). i think some |
| 99 |
more information about gentoo's internal organization, tasks, |
| 100 |
release schedules and targets for non-gentoo-core people would |
| 101 |
be very much appreciated and would enhance confidence, |
| 102 |
predictability and thus the coordination of own activities. |
| 103 |
gentoo-core still looks like some kind of a blackbox to me as |
| 104 |
what regards these points. is this really intended? |
| 105 |
|
| 106 |
> Please take a look at bug#1523 for much more details (though |
| 107 |
> bear in mind that some of that stuff is outdated by now). |
| 108 |
|
| 109 |
i've only skimed your proposal but it looks fine to me. is there |
| 110 |
any reason why gentoo-core has not approved it yet? |
| 111 |
|
| 112 |
summa summarum: |
| 113 |
|
| 114 |
1.) gentoo as a distro has its own strengths and weaknesses |
| 115 |
2.) organization is a very important thing when managing software |
| 116 |
projects |
| 117 |
3.) information flow from gentoo-core to gentoo-dev/-user and |
| 118 |
vice-versa is important |
| 119 |
|
| 120 |
regards |
| 121 |
|
| 122 |
dan |
| 123 |
|
| 124 |
- -- |
| 125 |
...::: Daniel Mettler | http://www.numlock.ch :::.... |
| 126 |
|
| 127 |
-----BEGIN PGP SIGNATURE----- |
| 128 |
Version: GnuPG v1.0.7 (GNU/Linux) |
| 129 |
|
| 130 |
iD8DBQE9as5ASLYjgrGjnWQRAsroAJ40C3TJCCZmVKy0zaYFD37jrA1kHACeJu1l |
| 131 |
A9+Z8QG4R/T2Ywg1nPguzis= |
| 132 |
=eC5U |
| 133 |
-----END PGP SIGNATURE----- |
Archives