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

[Joshua Kinard]

On 06/30/2014 09:25, Rich Freeman wrote:
> On Mon, Jun 30, 2014 at 12:01 AM, William Hubbs <williamh@g.o> wrote:
>>
>> On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote:
>>> On Sun, Jun 29, 2014 at 8:36 AM, hasufell <hasufell@g.o> wrote:
>>>> This is still too vague for me. If it's expected to be short-term, then
>>>> it can as well just land in ~arch.
>>>
>>> A package that hasn't been tested AT ALL doesn't belong in ~arch.
>>> Suppose the maintainer is unable to test some aspect of the package,
>>> or any aspect of the package?  Do we want it to break completely for
>>> ~arch?  In that event, nobody will run ~arch for that package, and
>>> then it still isn't getting tested.
>>
>> I'm not saying that we should just randomly throw something into ~arch
>> without testing it, but ~arch users are running ~arch with the
>> understanding that their systems will break from time to time and they
>> are expected to be able to deal with it when/if it happens. ~arch is
>> not a second stable branch.
>
> 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.  Or
> maybe they tested it in a very limited set of circumstances but know
> that other untested circumstances are important to the users and they
> have definite plans to get them tested.

I think what needs to be defined here is "testing".  What if I know of a
group of packages that are not only open-source and compile w/o major
issues, but are in use in enterprise environments, and not yet in Gentoo?
Would not a "compile and ship it" approach, into "~arch", work best for
something like that?  Do I really need to set up a testing platform for them
and test each one out?

That's just one example, though.  Perhaps we need to work up some very broad
and general guidelines on what "testing" means, and apply that to ~arch.


>> In particular, I would argue that for system-critical packages, users
>> should be very careful about running ~arch unless they know what the
>> fallout can be.
>
> I agree.  I think ~arch should break far more often than it does
> today.  However, I wouldn't extend that to sticking stuff in ~arch
> that hasn't even been executed.  If it is THAT unstable then nobody
> will want to run it, and that defeats the goal of having more testing.

I've been running ~arch for years and very rarely, do I see a breakage.
We're not one of the BSDs, or even Debian, in which we maintain a static
branch of specific package versions.  In a way, I view "arch" to imply
something very close to FreeBSD's -RELEASE branch, just with the flexibility
of getting new major revisions periodically.  "~arch" is more like -STABLE,
but it moves faster and potentially introduces minor breakages once in a
while, but nothing that requires a complete reinstall.

We don't really have anything that's like -CURRENT or a nightly-like build,
in which major, massive breakages are more common.  TBH, I don't know if we
should have something like that.  The hybrid-like approach we have now seems
to work out best for us.


>> Take a look at profiles/package.mask. You will see many packages in
>> there with the description, "masked for testing" on their masks, with no
>> bug references, that have been there for multiple years. My view is we
>> should either get those masks resolved or boot the affected
>> packages/versions out of the tree. If they haven't received rudimentary
>> testing by now, it is pretty obvious that no one cares about them.
>
> Are they even maintained?

We probably just need to step up review and cleaning out of package.mask
more often.  Since Portage tools can parse the file already, it shouldn't be
too hard to determine if there are any masks in there for packages or
package versions that no longer exist in the tree and prune it down some.


> If not maintained, then leave them alone until treecleaned.  If they
> are maintained, then I'd be interested in hearing from maintainers as
> to what they're up to.  I wouldn't just remove the mask unless
> somebody is actually going to co-maintain.  The issue of absentee
> maintainers is a different one than masks, though obsolete masks is a
> symptom of it just like obsolete ebuilds are.

Perhaps some periodic, automated reminders to anyone who adds a package to
package.mask to check up on it?  If the mask persists for a while after such
a notification, it escalates to QA or to -dev?

-- 
Joshua Kinard
Gentoo/MIPS
kumba@g.o
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic