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