| 1 |
On Mon, 30 Jun 2014 02:04:20 -0400 |
| 2 |
Alexandre Rostovtsev <tetromino@g.o> wrote: |
| 3 |
|
| 4 |
> I realize that not everybody agrees with me, but I see ~arch as a |
| 5 |
> "semi-stable" branch - an internally consistent branch for people who |
| 6 |
> don't feel like maintaining a horrific mess of keywords and masks in |
| 7 |
> their /etc/portage and don't want to wait weeks/months for bugfixes to |
| 8 |
> their favorite ebuilds to be marked stable by overworked arch teams, |
| 9 |
> and who don't mind seeing an occasional build failure or crash as a |
| 10 |
> consequence of standing closer to the bleeding edge. |
| 11 |
|
| 12 |
[[ TL;DR: This mail is a confirmation with some more side details. ]] |
| 13 |
|
| 14 |
+1. I do agree; it works well, and the occasional regression that |
| 15 |
manages to get through often isn't too bad. Maybe once in multiple |
| 16 |
years you end up with a broken boot; however, that's not a huge problem |
| 17 |
if you plan upgrades to not be in front of a deadline / presentation. |
| 18 |
|
| 19 |
> In my view, experimental work not ready for general exposure should be |
| 20 |
> kept in overlays and/or the main tree's package.mask, depending on how |
| 21 |
> the particular project's workflow is organized. |
| 22 |
|
| 23 |
Indeed; take for example MATE, I bump the packages over a span of a few |
| 24 |
days and keep it masked until mate-base/mate. With GNOME it is similar. |
| 25 |
|
| 26 |
This is a case where I need more packages do the standard developer |
| 27 |
testing; so, I can't just have an individual package unmasked without |
| 28 |
being able to confirm that it actually works at run-time. |
| 29 |
|
| 30 |
For version bumps / new packages I just don't add them to the tree till |
| 31 |
I have confidently tested for it to not be a bug magnet, but rather a |
| 32 |
stabilization candidate; I thus don't understand such p.mask entries. |
| 33 |
|
| 34 |
> At any given stability level, a system-critical library ideally ought |
| 35 |
> to be better-tested than, say, a game or a media player. In practice, |
| 36 |
> this sometimes doesn't happen, because some system-critical library |
| 37 |
> maintainers don't care about ~arch users and dump experimental code in |
| 38 |
> their laps, and in my view that's a bad thing because it encourages |
| 39 |
> users to come up with ad-hoc mixed arch/~arch setups which have |
| 40 |
> *never* been tested by any developer. |
| 41 |
|
| 42 |
The granted ability to make a choice brings its own limits. :) |
| 43 |
|
| 44 |
-- |
| 45 |
With kind regards, |
| 46 |
|
| 47 |
Tom Wijsman (TomWij) |
| 48 |
Gentoo Developer |
| 49 |
|
| 50 |
E-mail address : TomWij@g.o |
| 51 |
GPG Public Key : 6D34E57D |
| 52 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |
Archives