Re: [gentoo-dev] package.mask vs ~arch

[Rich Freeman <rich0@gentoo.org>]

On Mon, Jun 30, 2014 at 10:15 AM, Jeroen Roovers <jer@gentoo.org> wrote:
> On Mon, 30 Jun 2014 09:25:27 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>
>> Agree 100%.  I'm taking about masking things that HAVEN'T BEEN TESTED
>> AT ALL.  The maintainer knows that they compile, and that is it.
>
> Developers who "HAVEN'T [...] TESTED AT ALL" and still commit their
> changes to the tree should immediately hand in their toys and leave
> the project.

What harm does it cause to commit an untested package in a masked
state to the tree?

Doing so violates no policy, and IMHO it shouldn't be considered a
policy violation either, especially if it makes life easier on anybody
who has actually volunteered to test it.

Real life example:

Mythtv has a fixes branch which I try to update monthly, but sometimes
it is every few months.  Sometimes users ping me because a fix is
likely to be useful to them, or perhaps to others as well (especially
if it has been a while since my last update).  Generally I don't put
new updates in the tree until I've run them for a day or two at home.
That to me is the threshold of minimal testing appropriate for ~arch,
but not stable.

Some users are clamoring for a new set of fixes, but I don't have time
to deploy it at home and test for a day or two.  Mythtv is not
compatible across versions and involves client/server tiers, a php web
interface, and plugins.  So, I bump it, test-compile it, and mask it
and announce it in the bug so those who really want it can have it.
It is probably fine, but I haven't so much as run it so I'm not going
to foist it on ~arch.  A few days or a week later I get around to
testing it myself, and unmask it.

Just what value does the distro obtain by banning that workflow?
Sure, I could stick it in my overlay, but that is an extra step for
users.  I just don't see a quality issue here unless we're talking
about neglect, and in general neglect will cause quality issues no
matter how many rules we create.

Rich