| 1 |
John Lawles wrote: |
| 2 |
> |
| 3 |
> A possible solution is Daniel Robbins' proposal to have |
| 4 |
> separate "developer-facing" and "user-facing" portage trees. |
| 5 |
> Developers working on the developer-facing side would be freed to |
| 6 |
> experiment, hopefully improving their productivity. Only the |
| 7 |
> tested and successful ideas would be ported to the user-facing |
| 8 |
> tree, improving end-user satisfaction. |
| 9 |
> |
| 10 |
|
| 11 |
In theory we already have things like that. We have overlays, masking, |
| 12 |
etc - all designed to keep messes out of the sight of users. The main |
| 13 |
problem is that not everybody installs everything so it is hard to get a |
| 14 |
full test. |
| 15 |
|
| 16 |
Arch teams are supposed to test all packages on a stable-keyworded |
| 17 |
system before stabilizing them. Repoman also has automated checks to |
| 18 |
prevent in theory the worst offenses from happening. Sure, things do |
| 19 |
get through, but it usually isn't all that bad. When I get blocks |
| 20 |
typically I just need to unmerge one package and then do my emerge world |
| 21 |
to fix things - rarely do I get major circular dependency issues. |
| 22 |
|
| 23 |
Out of curiosity, are you running stable? If you have ~x86/~amd64 |
| 24 |
accepted in your keywords then you are running what would otherwise be |
| 25 |
the developer-facing portage tree, and you'd tend to get breakage. |
| 26 |
|
| 27 |
What I recommend is running the stable tree in general, and then |
| 28 |
accepting only individual packages in ~arch (usually tied to a version |
| 29 |
number) for the cases where you want cutting-edge. You'll get a lot |
| 30 |
farther that way - you can still have the latest and greatest amarok or |
| 31 |
whatever, but not have to take an experimental glibc or kdelibs or |
| 32 |
anything like that. Most users don't need EVERYTHING to be |
| 33 |
bleeding-edge, and you can benefit from just targeting this behavior for |
| 34 |
the packages you need this from the most. |
| 35 |
|
| 36 |
Getting back on-topic - how will a separate portage tree for devs be any |
| 37 |
different from what we already have (masking and keywording), and how |
| 38 |
will we prevent users getting hit with even worse bugs because nobody is |
| 39 |
bothering to test anything in the environment that end-users actually use? |
| 40 |
-- |
| 41 |
gentoo-project@l.g.o mailing list |
Archives