[gentoo-dev] package.mask vs ~arch

[gentoo-dev] package.mask vs ~arch

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2836 bytes --]

All,

I am starting a new thread so we don't refer to a specific package, but I
am quoting Rich and hasufell from the previous masking thread.

On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote:
> On Sun, Jun 29, 2014 at 8:36 AM, hasufell <hasufell@gentoo.org> 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.

> I agree that masking for testing is like having a 3rd branch, but I'm
> not convinced that this is a bad thing.  ~arch should be for packages
> that have received rudimentary testing and which are ready for testing
> by a larger population.  Masking should be used for packages that
> haven't received rudimentary testing - they might not have been tested
> at all.

The concern with this argument is  the definition of rudimentary testing
is subjective, especially when a package supports many possible
configurations.

I think some packages need wide testing before they go stable, and that
is where ~arch can help out.

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.

*snip*

> I guess the question is, what exactly are we trying to fix?  Even if
> occasionally a maintainer drops the ball and leaves something masked
> for a year, how is that different from a maintainer dropping the ball
> and not adding a new release to the main tree for a year?  Would we be
> better off if Docker 1 wasn't in the tree at all?  If it happened to
> have a known issue would ~arch users be better off if some other dev
> came along and helpfully added it to the tree unmasked no realizing
> that somebody else was already working on it?

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.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Alexandre Rostovtsev]

[-- Attachment #1: Type: text/plain, Size: 3098 bytes --]

On Sun, 2014-06-29 at 23:01 -0500, William Hubbs wrote:
> All,
> 
> I am starting a new thread so we don't refer to a specific package, but I
> am quoting Rich and hasufell from the previous masking thread.
> 
> On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote:
> > On Sun, Jun 29, 2014 at 8:36 AM, hasufell <hasufell@gentoo.org> 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.

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.

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.

> > I agree that masking for testing is like having a 3rd branch, but I'm
> > not convinced that this is a bad thing.  ~arch should be for packages
> > that have received rudimentary testing and which are ready for testing
> > by a larger population.  Masking should be used for packages that
> > haven't received rudimentary testing - they might not have been tested
> > at all.
> 
> The concern with this argument is  the definition of rudimentary testing
> is subjective, especially when a package supports many possible
> configurations.
> 
> I think some packages need wide testing before they go stable, and that
> is where ~arch can help out.
> 
> 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.

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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2444 bytes --]

On Mon, 30 Jun 2014 02:04:20 -0400
Alexandre Rostovtsev <tetromino@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  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1258 bytes --]

Am Montag, 30. Juni 2014, 06:01:53 schrieb William Hubbs:
> 
> 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.
> 

Hey William, 

here's my take:

Masked commit:
* a part of a bigger version bump, i.e. one of many packages that need to 
update together
* or something where I *know* that issues preventing normal function still 
exist. I.e., I want to be able to ask others for testing, but something is 
still missing and I'm actively working on it.

~arch commit: 
* I'm reasonably sure that it should work; it works for me.

Now, one can argue that work in progress should go into an overlay. That in my 
opinion makes sense for e.g. kde packages and kde overlay, or qt packages and 
qt overlay, or similar. Making a fresh overlay for one package or asking to 
add my dev overlay for one required ebuild makes no sense. 

Only my opinion...
Cheers, Andreas


-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

On Mon, 30 Jun 2014 10:12:14 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

> Masked commit:
> * a part of a bigger version bump, i.e. one of many packages that
> need to update together
> * or something where I *know* that issues preventing normal function
> still exist. I.e., I want to be able to ask others for testing, but
> something is still missing and I'm actively working on it.

This is how I like it to be; for ebuilds that are known as broken,
even when that is due to them being incomplete (multiple packages).

When testing packages are added as masked, they miss out on more
testing; now consider that they might just work, you can miss out on
smaller edge case^ bugs if a faster stabilization* must follow later.

 ^ The more users, the more different system environments, ...

 * Reverse dependency that needs it, security and so on.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[hasufell]

Rich Freeman:> On Sun, Jun 29, 2014 at 8:36 AM, hasufell
<hasufell@gentoo.org> 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.

Huh? That's exactly the place. However, if you mean "AT ALL" in the
sense that no one ever tried to compile it, then the guy who comitted
should not have commit rights.

> 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.

In that event, you will get a bug report VERY soon.

> I agree that masking for testing is like having a 3rd branch, but I'm
> not convinced that this is a bad thing.

I have to reiterate:
* increases the workload, because we are effectively running 3 branches
* decreases the amount of testing for that time period, because... it's
masked
* causes confusion (see this thread)
* decreases the quality of our stable branch, because people suddenly
expect the unstable branch to be ...stable and don't bother with filing
stabilization requests anymore
* makes the whole testing/stabilization iteration actually slower,
possibly even causing unnecessary exposures to security issues
* causes inconsistency, because not everyone actually agrees on the
3-branches concept and it was never actually decided to be one

> Sure, it could go into an overlay, but for that matter so could all of ~arch.

Not at all. I made a clear distinction for that. Overlays have some good
use cases, but even those get abused and we end up with projects not
caring to import ebuilds to the tree anymore.

To make the situation even worse, a lot of people don't mask broken
packages if they have ever been in ~arch, as if this is a one-way road
from hardmask->keywordmask->stable. No, it isn't.

> I guess the question is, what exactly are we trying to fix?  Even if
> occasionally a maintainer drops the ball and leaves something masked
> for a year, how is that different from a maintainer dropping the ball
> and not adding a new release to the main tree for a year?  Would we be
> better off if Docker 1 wasn't in the tree at all?  If it happened to
> have a known issue would ~arch users be better off if some other dev
> came along and helpfully added it to the tree unmasked no realizing
> that somebody else was already working on it?

Trying to fix
* workflow
* user experience
* quality of stable branch

Inconsistent usage of hardmasks is only one problem here, but it is one.


So, from my POV hardmasks are reasonable for these use cases:
* package was imported to ~arch, turned out broken, bugs are difficult
to fix, no improvement upstream
* package has security issues, but we don't want it removed (happens a
lot for games)
* package is known to be broken, but we want it in the tree (like
googleearth)
* package is a library and is either known to or expected to break more
than half of it's consumers

The last 3 points can, depending on the actual situation, be a good use
case for an overlay. Some already do it, including for non-trivial
libraries.


To make a blunt statement here: many commits in profiles/ cause trouble
for the user in one way or another. Some people on the forums already
told us they want to switch, because they are sick of dealing with world
updates since they seem get more and more complicated. For multilib we
have been abusing profiles/ a lot, since there is only one alternative
way which is almost impossible to carry out given the large scale of
these changes: a parallel branch which gets imported in one blow.

Profile hackery has to get less. It's not improving user experience.
Users are switching to ~arch, because people tell them on IRC and
elsewhere that it's "almost stable" and that arch is too slow. That
makes the situation even worse.


In addition, we should make the most important arch testing
points/techniques part of the quizzes and allow maintainers to carry out
stabilization on major arches if they have access to them (that doesn't
mean they have to, they can still request help from the dedicated arch
teams).

Having no clear release scheme can be neck-breaking for a project.
Rolling release or not.

But I doubt we will come to any conclusion here. This thread will get
some bikeshed and if someone really cares, he will bring it up to the
council which will basically say "we encourage foo, but allow bar as
well and leave anything else up to the maintainer", neither deciding on
a real 3rd branch, nor declining it (because if they would decide on a
3rd branch, they would actually have to come up with a PMS addition that
is sane and not ambigous like hardmasks which are used for all random
sorts of things... and don't tell me hardmask messages can be used as an
API).

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

[Alexandre Rostovtsev]

[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]

On Mon, 2014-06-30 at 11:29 +0000, hasufell wrote:
> > I agree that masking for testing is like having a 3rd branch, but I'm
> > not convinced that this is a bad thing.
> 
> I have to reiterate:
> * increases the workload, because we are effectively running 3 branches
> * decreases the amount of testing for that time period, because... it's
> masked
> * causes confusion (see this thread)

A branch is is supposed to be internally consistent: for any X and Y,
the latest version of X from a given branch is in theory compatible with
the latest version of Y from the same branch. If they are not
compatible, there should be a bug that somebody is actively working on
resolving, or a blocker dependency, and such blockers ought to be
relatively rare to make things easy for human minds and package
managers.

Masked packages are not a third branch. Some packages are hardmasked for
being untested, some for impossible-to-fix bugs, some are known to break
a reverse dependency and are waiting for that reverse dependency to be
updated, some are lastrited for removal in 30 days. There is absolutely
no expectation that all masked packages are compatible with each other.

> * decreases the quality of our stable branch, because people suddenly
> expect the unstable branch to be ...stable and don't bother with filing
> stabilization requests anymore

Stablereq for wine-1.6.2 was filed in February. It got stabilized on
amd64 exactly 4 months later.

Security stablereq for freetype-2.5.3-r1 was filed in March for all
arches. Thus far, only hppa and ia64 stabilized it.

People don't bother with filing stabilization requests because they
realize that arch teams usually have a long backlog of existing
requests, and might take weeks/months to get to your new request.
Especially if your new request depends on other stablereqs.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Rich Freeman]

On Mon, Jun 30, 2014 at 7:29 AM, hasufell <hasufell@gentoo.org> wrote:
> Huh? That's exactly the place. However, if you mean "AT ALL" in the
> sense that no one ever tried to compile it, then the guy who comitted
> should not have commit rights.

I mean in the sense that it has been compiled, but that it hasn't been
executed, or the maintainer believes that it significant portions of
it haven't been executed.

Simply being able to compile something shouldn't really be grounds for
sticking it in ~arch, at least not for x86/amd64.  I could see that
workflow making more sense for obscure archs where users are happy to
have any packages at all and the fact that something compiles is a
useful data point.

>
>> Sure, it could go into an overlay, but for that matter so could all of ~arch.
>
> Not at all. I made a clear distinction for that. Overlays have some good
> use cases, but even those get abused and we end up with projects not
> caring to import ebuilds to the tree anymore.

I have mixed feelings on this.

On the one hand I think having "first-class" overlays could be a
better solution to getting more outside contribution, and allowing for
more variety in QA standards (with users being able to choose).  Many
distros have a large percentage of their packages in unofficial
repositories of some kind.

On the other hand, Gentoo is not release-based, which means that
overlays will basically always be broken.  There has been talk about
better announcing changes to common deps and not just quietly patching
the tree so that overlay maintainers aren't behind the times.
However, overlays will never get systematically tested before changes
are made in the main tree, and since we don't have releases that is
going to make them problematic.

So, I guess I tend to agree with you more than not.

> To make a blunt statement here: many commits in profiles/ cause trouble
> for the user in one way or another. Some people on the forums already
> told us they want to switch, because they are sick of dealing with world
> updates since they seem get more and more complicated. For multilib we
> have been abusing profiles/ a lot, since there is only one alternative
> way which is almost impossible to carry out given the large scale of
> these changes: a parallel branch which gets imported in one blow.
>
> Profile hackery has to get less. It's not improving user experience.
> Users are switching to ~arch, because people tell them on IRC and
> elsewhere that it's "almost stable" and that arch is too slow. That
> makes the situation even worse.

I couldn't agree more here.  If we're going to define ~arch as
basically stable, and arch as out-of-date, then we might as well drop
keywords entirely.  That makes no sense, unless you're actually
backporting things like Debian does, which we don't.

>
> But I doubt we will come to any conclusion here. This thread will get
> some bikeshed and if someone really cares, he will bring it up to the
> council which will basically say "we encourage foo, but allow bar as
> well and leave anything else up to the maintainer", neither deciding on
> a real 3rd branch, nor declining it (because if they would decide on a
> 3rd branch, they would actually have to come up with a PMS addition that
> is sane and not ambigous like hardmasks which are used for all random
> sorts of things... and don't tell me hardmask messages can be used as an
> API).
>

You're basically asking for the practice of hard-masks for testing to
be banned.  If the council disagrees, it doesn't mean that somebody
has to come up with some mechanism to have some full-featured 3rd
branch in Gentoo.  Maybe they just agree that on occasion it is useful
to use hard-masks for testing.

Nobody is saying that these masks should sit around for months.  That
falls into the same category as packages that haven't been revbumped
in months despite upstream having new releases.

Rich

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

[Jeroen Roovers]

On Mon, 30 Jun 2014 10:37:11 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> You're basically asking for the practice of hard-masks for testing to
> be banned.

My original point in the other thread was that "masked for testing" is
not a valid reason. A reference to an outstanding issue, bug report,
discussion or other resources would help users determine whether it's
safe for them to unmask an ebuild locally. "Masked for testing" offers
no guidance at all and is nothing more than a lazy substitute for real
content.


     jer

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

[Joshua Kinard]

On 06/30/2014 11:27, Jeroen Roovers wrote:
> On Mon, 30 Jun 2014 10:37:11 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
> 
>> You're basically asking for the practice of hard-masks for testing to
>> be banned.
> 
> My original point in the other thread was that "masked for testing" is
> not a valid reason. A reference to an outstanding issue, bug report,
> discussion or other resources would help users determine whether it's
> safe for them to unmask an ebuild locally. "Masked for testing" offers
> no guidance at all and is nothing more than a lazy substitute for real
> content.

I would agree to a point.  In the case of some toolchain related packages,
like gcc and binutils, "masked for testing" keeps potentially dangerous
system updates from propagating out to a majority of users.  However, those
users and developers who are quite avid about being on the forefront of the
latest and greatest already know how to unmask such packages and test them
out.  So a mask on "=sys-devel/gcc-4.9.0" with the reason of "Masked for
testing" makes perfect sense, especially since this version of gcc enables
strong stack-protection.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
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

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

[Jeroen Roovers]

On Mon, 30 Jun 2014 15:49:54 -0400
Joshua Kinard <kumba@gentoo.org> wrote:

> So a mask on
> "=sys-devel/gcc-4.9.0" with the reason of "Masked for testing" makes
> perfect sense, especially since this version of gcc enables strong
> stack-protection.

In that case "this version of gcc enables strong stack-protection
[which might kill your cow]" is a good masking reason. Go for it.

"Masked for testing" never makes sense, let alone perfect sense, because
the intent (testing) is prevented by the action (masking). On the
other hand, "unmasked for testing" would make perfect sense.


     jer

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

[Peter Stuge]

Rich Freeman wrote:
> If we're going to define ~arch as basically stable, and arch as
> out-of-date, then we might as well drop keywords entirely.

I actually don't think that would be such a bad thing.

I only consider ~arch relevant, because it is the closest to upstream.

I want the distribution I use to be as thin as possible; the value it
adds is administrative - and the Gentoo packages and tools are fantastic.
\o/

The thicker a distribution is, the larger a gap between users and
upstream it creates, which inconveniences *both* users and upstream,
because users have to wait for new code, and upstreams have to deal
with lots of known and possibly fixed bugs.

The ideal would be only live ebuilds, but for now we have no precise
technology for synchronization.

Version numbers are both blunt and arbitrary.


//Peter

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

[Rich Freeman]

On Mon, Jun 30, 2014 at 12:01 AM, William Hubbs <williamh@gentoo.org> 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@gentoo.org> 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.

> 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.

> 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?

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.

Rich

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

[Jeroen Roovers]

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.


     jer

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

[Rich Freeman]

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

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

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]

On Mon, 30 Jun 2014 10:48:22 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> 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.

"should" != "must"; that joke aside, while it's not punishable by
policy (and shouldn't even be punished if it's not repeated behavior)
we rather need to keep the package.mask file of a reasonable size.

The goal of this file is to have an overview of what _is_ BROKEN; when
you add a lot of UNSURE, its contents will diverge away from this goal.

A test of a package to determine whether it appears to be working OK or
whether it destructs your system isn't too much asked for; if it works
it can then be ~arch tested, if it breaks you have a bug # for p.mask.

If someone can't test it at all, why was it added in the first place?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Rich Freeman]

On Mon, Jun 30, 2014 at 3:11 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
>
> A test of a package to determine whether it appears to be working OK or
> whether it destructs your system isn't too much asked for; if it works
> it can then be ~arch tested, if it breaks you have a bug # for p.mask.
>
> If someone can't test it at all, why was it added in the first place?

So that it can be tested?  Maybe the maintainer doesn't have the
ability to test the package (might require special hardware).  Maybe
the maintainer doesn't have the time to test it right away, but wants
to allow others to do so (especially if others show an interest).

In my example of mythtv, testing might require first updating all the
front-ends to be current and ensure that nothing breaks (it might only
be emerge --sync'ed monthly).  Then a window has to exist where
nothing will be recorded.  Then everything gets brought down and
backed up (not a big deal, but nobody is watching TV for a while).
Then you update everything and see if it works, perhaps having to
tweak things a bit.  Then you do the quick tests (record shows, play
things back, check the web front end).  Then you leave it alone for a
day and see if anybody screams - best not to do this if you'll be
really busy the next day.

If people are clamoring for an update, it may be more productive to
just let them have it with a disclaimer about quality, rather than
just putting them off for a week or two.

Sure, I can set up yet another overlay, which will be empty 99% of the
time.  But, what is the harm in just using a mask?  I've yet to leave
one sitting around for years (well, not for testing at least).

Rich

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

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]

On Mon, 30 Jun 2014 15:19:59 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Jun 30, 2014 at 3:11 PM, Tom Wijsman <TomWij@gentoo.org>
> wrote:
> >
> > A test of a package to determine whether it appears to be working
> > OK or whether it destructs your system isn't too much asked for; if
> > it works it can then be ~arch tested, if it breaks you have a bug #
> > for p.mask.
> >
> > If someone can't test it at all, why was it added in the first
> > place?
> 
> So that it can be tested?  Maybe the maintainer doesn't have the
> ability to test the package (might require special hardware).  Maybe
> the maintainer doesn't have the time to test it right away, but wants
> to allow others to do so (especially if others show an interest).

That is an edge case; it's somewhat hard to maintain a package if you
can't test it, and there are occasions (eg. Amazon EC2 related
packages) where this is indeed needed. I don't see a need to introduce
that masked though; but again, it depends on how edgy it is...

> Sure, I can set up yet another overlay, which will be empty 99% of the
> time.  But, what is the harm in just using a mask?  I've yet to leave
> one sitting around for years (well, not for testing at least).

No problem with that if it is for a safe introduction, although I'm
not quite sure how much that really invites actual testing; however
it's not about that, everything that stays longer forms the problem.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Rich Freeman]

On Wed, Jul 2, 2014 at 1:56 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> That is an edge case; it's somewhat hard to maintain a package if you
> can't test it, and there are occasions (eg. Amazon EC2 related
> packages) where this is indeed needed. I don't see a need to introduce
> that masked though; but again, it depends on how edgy it is...
>

No argument there.  I think that use of package masks for
testing-related purposes should be rare and short-lived.  I just don't
think that banning them entirely is the right solution.  If they're
done right they probably shouldn't be noticed by the majority.

Rich

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

[Patrick Lauer]

On 06/30/14 22:15, Jeroen Roovers 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.
> 

I usually avoid overlays (best way to make things hard to find), so when
there's stuff that upstream says is experimental (e.g. perl6/rakudo with
the MoarVM backend) I have no issue with adding it as un-keyworded
ebuilds to the tree. That way it's easy to test, and once there's a bit
more confidence that it works well enough it's trivial to keyword.

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

[Rich Freeman]

On Tue, Jul 1, 2014 at 8:41 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> On 06/30/14 22:15, Jeroen Roovers 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.
>>
>
> I usually avoid overlays (best way to make things hard to find), so when
> there's stuff that upstream says is experimental (e.g. perl6/rakudo with
> the MoarVM backend) I have no issue with adding it as un-keyworded
> ebuilds to the tree. That way it's easy to test, and once there's a bit
> more confidence that it works well enough it's trivial to keyword.
>

If the goal is to reduce clutter in the profiles then this could be a
good alternative.  Nothing would prevent a maintainer from sticking a
comment in the ebuild as well.

Hate to derail this, but another option would be to migrate
package.mask to a directory (eventually) and manage masks by project
or by date.  Projects could create standing files when needed, and
misc masks would go into a file named by year/quarter.  Then anybody
looking in the directory can spot projects that are dead, or files
which are old.  Either would be easier to clean up.

Obviously restructuring the profiles entirely as has been suggested
will help, though not for masks like these.

Rich

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

[Greg KH]

On Mon, Jun 30, 2014 at 04:15:55PM +0200, Jeroen Roovers 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 toys?  Were we given some when we became developers?  If I had some
I'd send mine back in, but as I don't, I'll keep committing stable
kernel ebuilds that I never test as no one seems to be complaining...

greg "never make absolute statements" k-h

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

[hasufell]

Greg KH:
> On Mon, Jun 30, 2014 at 04:15:55PM +0200, Jeroen Roovers 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 toys?  Were we given some when we became developers?  If I had some
> I'd send mine back in, but as I don't, I'll keep committing stable
> kernel ebuilds that I never test as no one seems to be complaining...
> 
> greg "never make absolute statements" k-h
> 

Depends on what you mean with testing. Just renaming ebuilds like
foo-1.2.ebuild -> foo-1.3.ebuild and letting the community figure out if
that even makes sense (e.g. the ebuild dies in src_prepare, because a
patch fails or is missing) is a bit rough, although it may work if you
know the underlying package very well.

If you are talking about actually testing and running the software then
that's a different story and definitely not within our scope when
committing to ~arch.

That said, I think it's a reasonable minimum to at least check if an
ebuild emerges on my current machine with my current setup before
committing to ~arch. If even that fails, what's the point of committing
the ebuild?

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

On Sun, Jul 06, 2014 at 01:07:18PM +0000, hasufell wrote:
> If you are talking about actually testing and running the software then
> that's a different story and definitely not within our scope when
> committing to ~arch.
> 
> That said, I think it's a reasonable minimum to at least check if an
> ebuild emerges on my current machine with my current setup before
> committing to ~arch. If even that fails, what's the point of committing
> the ebuild?

Yes, this is basically what I do. I make sure the ebuild emerges and
the software runs in the configuration I was running the old version in.
Once I know that's true, I don't see anything wrong with committing to
~arch.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 30/06/14 09:25 AM, Rich Freeman wrote:
> On Mon, Jun 30, 2014 at 12:01 AM, William Hubbs
> <williamh@gentoo.org> 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@gentoo.org>
>>> 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.
> 


Here's a great example of this -- dev-libs/nss-3.16-r1 is p.masked by
me for testing, because when I converted it to multilib i needed to
change the way it does some internal ABI determination tests, and
although I know it does work fine on multilib-amd64 and (non-multilib)
x86, I am not confident without more testing that it will work for
cross-compiles or other non-multilib arches.  As such, it -is- in the
tree, but I've masked it until I can test it myself in these
circumstances or find someone else that can do it for me.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlOxgJ8ACgkQ2ugaI38ACPC8zAD/XwulPJp4f3xNFe4ZP7gE+kmp
qhmdvJjUFyWW8j1dTHMA/jFc/mrH/dnyq/MJWBlUbEFY3ccebpLw/8C6/IaSeXw4
=iKL1
-----END PGP SIGNATURE-----

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2289 bytes --]

Dnia 2014-06-30, o godz. 11:22:07
Ian Stakenvicius <axs@gentoo.org> napisał(a):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 30/06/14 09:25 AM, Rich Freeman wrote:
> > On Mon, Jun 30, 2014 at 12:01 AM, William Hubbs
> > <williamh@gentoo.org> 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@gentoo.org>
> >>> 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.
> > 
> 
> 
> Here's a great example of this -- dev-libs/nss-3.16-r1 is p.masked by
> me for testing, because when I converted it to multilib i needed to
> change the way it does some internal ABI determination tests, and
> although I know it does work fine on multilib-amd64 and (non-multilib)
> x86, I am not confident without more testing that it will work for
> cross-compiles or other non-multilib arches.  As such, it -is- in the
> tree, but I've masked it until I can test it myself in these
> circumstances or find someone else that can do it for me.

But... if you unmask it, someone will test it and report whether it
works :P.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 30/06/14 11:36 AM, Michał Górny wrote:
> Dnia 2014-06-30, o godz. 11:22:07 Ian Stakenvicius <axs@gentoo.org>
> napisał(a):
> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 
>> On 30/06/14 09:25 AM, Rich Freeman wrote:
>>> On Mon, Jun 30, 2014 at 12:01 AM, William Hubbs 
>>> <williamh@gentoo.org> 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@gentoo.org> 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.
>>> 
>> 
>> 
>> Here's a great example of this -- dev-libs/nss-3.16-r1 is
>> p.masked by me for testing, because when I converted it to
>> multilib i needed to change the way it does some internal ABI
>> determination tests, and although I know it does work fine on
>> multilib-amd64 and (non-multilib) x86, I am not confident without
>> more testing that it will work for cross-compiles or other
>> non-multilib arches.  As such, it -is- in the tree, but I've
>> masked it until I can test it myself in these circumstances or
>> find someone else that can do it for me.
> 
> But... if you unmask it, someone will test it and report whether
> it works :P.
> 

But... if I unmask it, -everyone- using ~arch will install it and
it'll break all the systems that it doesn't work on, which -could- be
quite a lot at this point.  :D


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlOxhOIACgkQ2ugaI38ACPD4NwD/Spcjj7VPGNIz+FCVTkSUDmKZ
ghVqFhuiemJO7+G62wgA/jc7bpyPsu8S7wbbNs3UYGqE//MyVYNWHDmOoXDZ3Qsk
=FEfS
-----END PGP SIGNATURE-----

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

[Jeroen Roovers]

On Mon, 30 Jun 2014 11:40:19 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> But... if I unmask it, -everyone- using ~arch will install it and
> it'll break all the systems that it doesn't work on, which -could- be
> quite a lot at this point.  :D

Which is great, because then you have an actual test result, whereas
before you had nothing but a stupid mask.

And lots of people are suddenly very much interested in getting any and
all bugs fixed in the new ebuild, whereas before you only had the stupid
mask.


     jer

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

On Mon, Jun 30, 2014 at 06:13:45PM +0200, Jeroen Roovers wrote:
> On Mon, 30 Jun 2014 11:40:19 -0400
> Ian Stakenvicius <axs@gentoo.org> wrote:
> 
> > But... if I unmask it, -everyone- using ~arch will install it and
> > it'll break all the systems that it doesn't work on, which -could- be
> > quite a lot at this point.  :D
> 
> Which is great, because then you have an actual test result, whereas
> before you had nothing but a stupid mask.
> 
> And lots of people are suddenly very much interested in getting any and
> all bugs fixed in the new ebuild, whereas before you only had the stupid
> mask.
> 
> 
>      jer

I am going to agree with Jer on this.

As said before, ~arch users know that their systems will break
sometimes, so if the package works for you, unleash it on ~arch. If
someone using a configuration you don't have finds that it breaks, I'm
sure it would be reported. Then you could determine whether the bug is
severe enough to warrant a mask.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Rich Freeman]

On Mon, Jun 30, 2014 at 12:32 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Mon, Jun 30, 2014 at 06:13:45PM +0200, Jeroen Roovers wrote:
>> On Mon, 30 Jun 2014 11:40:19 -0400
>> Ian Stakenvicius <axs@gentoo.org> wrote:
>>
>> > But... if I unmask it, -everyone- using ~arch will install it and
>> > it'll break all the systems that it doesn't work on, which -could- be
>> > quite a lot at this point.  :D
>>
>> Which is great, because then you have an actual test result, whereas
>> before you had nothing but a stupid mask.
>>
>> And lots of people are suddenly very much interested in getting any and
>> all bugs fixed in the new ebuild, whereas before you only had the stupid
>> mask.
>>
>>
>>      jer
>
> I am going to agree with Jer on this.
>
> As said before, ~arch users know that their systems will break
> sometimes, so if the package works for you, unleash it on ~arch. If
> someone using a configuration you don't have finds that it breaks, I'm
> sure it would be reported. Then you could determine whether the bug is
> severe enough to warrant a mask.
>

We're not talking about packages that work for the maintainer.  We're
talking about packages where the maintainer doesn't know if they work.
Or at least, those are the packages I'm talking about.

Everybody seems to think that this is a debate between having newer
ebuilds in the tree masked vs unmasked.  This is a debate between
having newer ebuilds in the tree masked vs not having them in the tree
at all.  Nobody is going to put an ebuild in the tree unmasked if they
don't know that it is going to work, and per earlier comments anybody
who does that probably shouldn't have commit privs.

Rules won't make maintainers do more work.  They can only prevent
maintainers from doing certain kinds of work.  That is why I tend to
oppose more rules unless they actually are preventing some kind of
harm, or having a likely benefit.  I just don't see the benefit here.

I'm fine with a policy that says that packages should only be masked
for testing if they're actually being tested and there is some kind of
roadmap for getting rid of the mask.

I don't like seeing 3 year old masks in the profile either.  Let's try
to curtail that kind of thing.  However, I think we're in danger of
throwing the baby out with the bath water here.  I cringe anytime I
hear somebody say that ~arch has fewer issues than stable, but the
solution to that isn't to go looking for opportunities to break ~arch.

Rich

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 4099 bytes --]

On Mon, Jun 30, 2014 at 01:07:17PM -0400, Rich Freeman wrote:
> On Mon, Jun 30, 2014 at 12:32 PM, William Hubbs <williamh@gentoo.org> wrote:
> > On Mon, Jun 30, 2014 at 06:13:45PM +0200, Jeroen Roovers wrote:
> >> On Mon, 30 Jun 2014 11:40:19 -0400
> >> Ian Stakenvicius <axs@gentoo.org> wrote:
> >>
> >> > But... if I unmask it, -everyone- using ~arch will install it and
> >> > it'll break all the systems that it doesn't work on, which -could- be
> >> > quite a lot at this point.  :D
> >>
> >> Which is great, because then you have an actual test result, whereas
> >> before you had nothing but a stupid mask.
> >>
> >> And lots of people are suddenly very much interested in getting any and
> >> all bugs fixed in the new ebuild, whereas before you only had the stupid
> >> mask.
> >>
> >>
> >>      jer
> >
> > I am going to agree with Jer on this.
> >
> > As said before, ~arch users know that their systems will break
> > sometimes, so if the package works for you, unleash it on ~arch. If
> > someone using a configuration you don't have finds that it breaks, I'm
> > sure it would be reported. Then you could determine whether the bug is
> > severe enough to warrant a mask.
> >
> 
> We're not talking about packages that work for the maintainer.  We're
> talking about packages where the maintainer doesn't know if they work.
> Or at least, those are the packages I'm talking about.

The debate is sort of two-pronged, and I split out the package.mask
question to another thread. There are 6 year old p.mask entries that
just say "masked for testing", and those are listed in the new thread I
started.

> Everybody seems to think that this is a debate between having newer
> ebuilds in the tree masked vs unmasked.  This is a debate between
> having newer ebuilds in the tree masked vs not having them in the tree
> at all.  Nobody is going to put an ebuild in the tree unmasked if they
> don't know that it is going to work, and per earlier comments anybody
> who does that probably shouldn't have commit privs.
 
 What was said earlier is if a maintainer just runs compile tests then
 commits the new version that person probably shouldn't have commit
 privs.

> Rules won't make maintainers do more work.  They can only prevent
> maintainers from doing certain kinds of work.  That is why I tend to
> oppose more rules unless they actually are preventing some kind of
> harm, or having a likely benefit.  I just don't see the benefit here.
 
 The benefit of getting packages into ~arch vs "masked for testing" is
 that maintainers can get users to test their packages in configurations
 that the maintainers are not able to test with.

 Also, it opens up the package to more testing because it will be
 exposed to more users with different configurations.

> I'm fine with a policy that says that packages should only be masked
> for testing if they're actually being tested and there is some kind of
> roadmap for getting rid of the mask.
 
 The problem I see with "masked for testing" is probably similar to what
 you are talking about. If something is "masked for testing", there
 should be a push from somewhere to not keep it "masked for testing".

> I don't like seeing 3 year old masks in the profile either.  Let's try
> to curtail that kind of thing.  However, I think we're in danger of
> throwing the baby out with the bath water here.  I cringe anytime I
> hear somebody say that ~arch has fewer issues than stable, but the
> solution to that isn't to go looking for opportunities to break ~arch.
 
 I don't like seeing old masks in the profiles either. p.mask
 should never be permanent, but there are other issues associated with
 making that happen that should be in other threads probably.

All I'm saying about ~arch is that it is known to break and will
continue to break, so lets not try to pretend otherwise. Someone in this
thread said ~arch is semi-stable; it is not. If you use ~arch you are on
your own and expected to be able to handle any breakage that comes up.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

On Mon, 30 Jun 2014 11:32:35 -0500
William Hubbs <williamh@gentoo.org> wrote:

> As said before, ~arch users know that their systems will break
> sometimes, so if the package works for you, unleash it on ~arch. If
> someone using a configuration you don't have finds that it breaks, I'm
> sure it would be reported. Then you could determine whether the bug is
> severe enough to warrant a mask.

As long as important/core/system packages don't result in a wide scale
breakage on ~arch this approach should be fine; we've been doing fine
before, so I don't think that this warrants a change in what we do.

Just want to note that you can get an idea from previous outages (or
similar events like python-exec / UPower) on how much testing is needed.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Rich Freeman]

On Mon, Jun 30, 2014 at 12:13 PM, Jeroen Roovers <jer@gentoo.org> wrote:
> On Mon, 30 Jun 2014 11:40:19 -0400
> Ian Stakenvicius <axs@gentoo.org> wrote:
>
>> But... if I unmask it, -everyone- using ~arch will install it and
>> it'll break all the systems that it doesn't work on, which -could- be
>> quite a lot at this point.  :D
>
> Which is great, because then you have an actual test result, whereas
> before you had nothing but a stupid mask.
>
> And lots of people are suddenly very much interested in getting any and
> all bugs fixed in the new ebuild, whereas before you only had the stupid
> mask.

This subjects a lot of users to unnecessary inconvenience.

Testing is a necessary inconvenience.  Anybody who uses ~arch should
be prepared for things to sometimes break.  However, foisting
completely alpha stuff on users that the maintainer simply hasn't
gotten a chance to test yet seems excessive.

I'm perfectly fine with the suggestion of requiring a bug reference
when masking for testing.  I think that adds value.  I just don't
think that giving the maintainers only the options of introducing
untested packages directly to ~arch or not putting them in the tree at
all is an unnecessary dichotomy.  Why tie our own hands?

Again, by all means lets require bug references and consider a masks
in the absence of activity a QA issue.  I'm less concerned with the
actual duration and more with the level of activity.  If it takes six
months of hard work to get something into the tree, that isn't a
problem, but six months of just rusting is a separate matter.

Rich

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

[Jeroen Roovers]

On Mon, 30 Jun 2014 12:40:59 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> I'm perfectly fine with the suggestion of requiring a bug reference
> when masking for testing.  I think that adds value.

You don't mean a reference to a bug report that merely says "masked for
testing" or purports to be a "tracker" (but isn't), right?


     jer

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

[Tom Wijsman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 30 Jun 2014 11:40:19 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> On 30/06/14 11:36 AM, Michał Górny wrote:
> > Dnia 2014-06-30, o godz. 11:22:07 Ian Stakenvicius <axs@gentoo.org>
> > napisał(a):
> > 
> >> Here's a great example of this -- dev-libs/nss-3.16-r1 is
> >> p.masked by me for testing, because when I converted it to
> >> multilib i needed to change the way it does some internal ABI
> >> determination tests, and although I know it does work fine on
> >> multilib-amd64 and (non-multilib) x86, I am not confident without
> >> more testing that it will work for cross-compiles or other
> >> non-multilib arches.  As such, it -is- in the tree, but I've
> >> masked it until I can test it myself in these circumstances or
> >> find someone else that can do it for me.
> > 
> > But... if you unmask it, someone will test it and report whether
> > it works :P.
> > 
> 
> But... if I unmask it, -everyone- using ~arch will install it and
> it'll break all the systems that it doesn't work on, which -could- be
> quite a lot at this point.  :D

Setting up an overlay for this and poking a stick at a few developers to
try it out could help as an intermediary test, to ensure that you don't
break every ~arch user in the progress. Better than "all or nothing"...

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJTsbcmAAoJEPWZc8roOL/QOVMH/3PXYSKNIOnEbsuo6JbHoksZ
UO7D88KNsN0Z8sbygsjM3H6Qkh6+iQSIqIhu8g6Y5OvT2bndz/qoJI3jIyO/Kjg/
no9tfiuCT61erHpQDg81LuPA2IaQnL1DbnNmsYl+j7SIMxu3R7nWLu0VmZbp1DA+
aEWn4eZX9z6IMqQWRDGmiJ7LAyJk36qFZwsvIlUJvfEJQEr0nIhJ+9UQsiNq0sPJ
ytZ5VI14MXW2bY84THWxn12Svey42AEsd9ggzgHnWp04v08NWseypvI69kAyvM0z
pu2G9k7QAx/ULNz9BuzZUm2vBO7D5qROy1G3EEY+GqySkqYNefOgobtY3CT/T8M=
=1qIF
-----END PGP SIGNATURE-----

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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 30/06/14 03:14 PM, Tom Wijsman wrote:
> On Mon, 30 Jun 2014 11:40:19 -0400 Ian Stakenvicius
> <axs@gentoo.org> wrote:
> 
>> On 30/06/14 11:36 AM, Michał Górny wrote:
>>> Dnia 2014-06-30, o godz. 11:22:07 Ian Stakenvicius
>>> <axs@gentoo.org> napisał(a):
>>> 
>>>> Here's a great example of this -- dev-libs/nss-3.16-r1 is 
>>>> p.masked by me for testing, because when I converted it to 
>>>> multilib i needed to change the way it does some internal
>>>> ABI determination tests, and although I know it does work
>>>> fine on multilib-amd64 and (non-multilib) x86, I am not
>>>> confident without more testing that it will work for
>>>> cross-compiles or other non-multilib arches.  As such, it
>>>> -is- in the tree, but I've masked it until I can test it
>>>> myself in these circumstances or find someone else that can
>>>> do it for me.
>>> 
>>> But... if you unmask it, someone will test it and report
>>> whether it works :P.
>>> 
> 
>> But... if I unmask it, -everyone- using ~arch will install it
>> and it'll break all the systems that it doesn't work on, which
>> -could- be quite a lot at this point.  :D
> 
> Setting up an overlay for this and poking a stick at a few
> developers to try it out could help as an intermediary test, to
> ensure that you don't break every ~arch user in the progress.
> Better than "all or nothing"...
> 
> 

Or i can just use the same stick to poke them about the p.masked
version in the tree. :)

All of this just means, to me, that as long as the packages indeed are
actively being pursued for testing, I think it's still fine to use
package.mask.  However, if things aren't being actively tested (ie
they've been forgotten about) then probably whomever added the mask
should be pinged relentlessly about it until it's resolved one way or
another.  At least, I would find it perfectly acceptable to being
pinged on any mask I've left rotting in the tree.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlOxvhUACgkQ2ugaI38ACPBqfQD/b4Rj0qoczFNwQO6jfnQjkL74
wFvxDV4SvER3BOyZRKkBAK5C63zG0YEAZvpfYTd6CwNLeX4cNdZXuVyMTqbPhx5k
=DbOV
-----END PGP SIGNATURE-----

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

[Tom Wijsman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 30 Jun 2014 15:44:21 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 30/06/14 03:14 PM, Tom Wijsman wrote:
>
> > Setting up an overlay for this and poking a stick at a few
> > developers to try it out could help as an intermediary test, to
> > ensure that you don't break every ~arch user in the progress.
> > Better than "all or nothing"...
> 
> Or i can just use the same stick to poke them about the p.masked
> version in the tree. :)
> 
> All of this just means, to me, that as long as the packages indeed are
> actively being pursued for testing, I think it's still fine to use
> package.mask.  However, if things aren't being actively tested (ie
> they've been forgotten about) then probably whomever added the mask
> should be pinged relentlessly about it until it's resolved one way or
> another.  At least, I would find it perfectly acceptable to being
> pinged on any mask I've left rotting in the tree.

+1 One could say that ensuring it is tested is part of the workflow;
and then I don't mean your own testing, but inviting others to do so.

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJTtEguAAoJEPWZc8roOL/QKKoIAI0KlFu28ri4KB7gAWJAQXe/
cgvNYy7Gy5kwbl9pagCSP9NhBO0VZ4LNRZIMY0OqOhv/fs9pM2+tdKOV3c/f+8mo
3PvE2zW6+U0NUDBeYDmSdRoCVuFecuZiLk9y8gciGLIipLVZ9jaIwW2N5l/jvT69
KZFLLRgoFvLeXFvg05LUbZgKlMsvpi3DJh0HWG2l0CCuGAw+vNSnFqviPyFWnVCP
mhZZuYh3Xwf9/yyrWwKHFY+JjlHD2aqCd1rO9q7Ght/Wbi1knzBt4PE+kgj7xTSo
7BVTEuskcAq4yU9wvmxUYKIyGGwnjmVD5L+fK+LcVnWp4A8zwQG6bk6opiSIFN0=
=R2Cc
-----END PGP SIGNATURE-----

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

[Roy Bamford]

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

On 2014.06.30 16:40, Ian Stakenvicius wrote:
> On 30/06/14 11:36 AM, Michał Górny wrote:

[snip]

> >
> > But... if you unmask it, someone will test it and report whether
> > it works :P.
> >
> 
> But... if I unmask it, -everyone- using ~arch will install it and
> it'll break all the systems that it doesn't work on, which -could- be
> quite a lot at this point.  :D
> 
> 
> 

Yep.  The good old days ... X11 going modular ... expat-2 and a few 
others that I've forgotten.
There was no news then so if you missed an email to the list you got to 
pick up the pieces.  Those examples may well be me missing emails.

I've run ~arch since mid 2002 and until the last few years always had a 
few builds fail or things build then operate so badly they needed to be 
p.masked locally.  That's what buildpkg is for ... so that after you 
spend 10 hours building *office and find out its a dud, you can back it 
out in a few minutes.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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@gentoo.org> 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@gentoo.org> 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@gentoo.org
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

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

[Roy Bamford]

[-- Attachment #1: Type: text/plain, Size: 4110 bytes --]

On 2014.06.30 05:01, William Hubbs wrote:
> All,
> 
> I am starting a new thread so we don't refer to a specific package,
> but I
> am quoting Rich and hasufell from the previous masking thread.
> 
> On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote:
> > On Sun, Jun 29, 2014 at 8:36 AM, hasufell <hasufell@gentoo.org>
> 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.
> 
> > I agree that masking for testing is like having a 3rd branch, but
> I'm
> > not convinced that this is a bad thing.  ~arch should be for
> packages
> > that have received rudimentary testing and which are ready for
> testing
> > by a larger population.  Masking should be used for packages that
> > haven't received rudimentary testing - they might not have been
> tested
> > at all.
> 
> The concern with this argument is  the definition of rudimentary
> testing
> is subjective, especially when a package supports many possible
> configurations.
> 
> I think some packages need wide testing before they go stable, and
> that
> is where ~arch can help out.
> 
> 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.
> 
> *snip*
> 
> > I guess the question is, what exactly are we trying to fix?  Even 
> if
> > occasionally a maintainer drops the ball and leaves something 
> masked
> > for a year, how is that different from a maintainer dropping the
> ball
> > and not adding a new release to the main tree for a year?  Would we
> be
> > better off if Docker 1 wasn't in the tree at all?  If it happened 
> to
> > have a known issue would ~arch users be better off if some other 
> dev
> > came along and helpfully added it to the tree unmasked no realizing
> > that somebody else was already working on it?
> 
> 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.
> 
> William
> 
> 

Once upon a time, not so long ago I don't remember it, there were very 
few overlays.  At that time, there was always a lot of packages in the 
tree "masked for testing".  At that time, well before layman, overlays 
were inconvenient. 

As overlays have become more widespread and used as a way to lower the 
barrier to contributing directly to Gentoo, there are fewer packages 
"masked for testing".

I like the old way, it avoids installing yet another overlay but 
clearly others feel differently or there would not be so many overlays 
to choose from. The reality is, both ways work for me.
Pragmatically, its not practical to merge all of the overlays into the 
tree, then ban overlays.  That would be a return to the old way.

This just represents a change of workflow with time.
The question then is do we need to formalise the changed workflow, or 
can both be allowed to continue side by side?

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Steven J. Long]

On Sun, Jun 29, 2014 at 11:01:53PM -0500, William Hubbs wrote:
> On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote:
> > 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.

Nor is it a dumping ground for something you can't be bothered to overlay.

> > I agree that masking for testing is like having a 3rd branch, but I'm
> > not convinced that this is a bad thing.  ~arch should be for packages
> > that have received rudimentary testing and which are ready for testing
> > by a larger population.  Masking should be used for packages that
> > haven't received rudimentary testing - they might not have been tested
> > at all.
> 
> The concern with this argument is  the definition of rudimentary testing
> is subjective, especially when a package supports many possible
> configurations.

Well it can never be fresh from upstream, even if that upstream is a
Gentoo developer. eudev is more of a sanity filter, and doesn't claim
to be upstream. If anything we want more constraints when a Gentoo dev
is "lead" on a project, as there are even less dykes in the way.

> I think some packages need wide testing before they go stable, and that
> is where ~arch can help out.

IOW some packages don't need "wide" testing, which by your yardstick, is
what anyone with experience/common-sense would call "a beta release."

> 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.

Yes, and so should Gentoo, when faced with "developers" who think
themselves exceptions to the rules everyone else should live by.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2845 bytes --]

On Fri, Aug 01, 2014 at 10:13:33AM +0100, Steven J. Long wrote:
> On Sun, Jun 29, 2014 at 11:01:53PM -0500, William Hubbs wrote:
> > On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote:
> > > 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.
> 
> Nor is it a dumping ground for something you can't be bothered to overlay.
 
I can see why teams like gnome, kde, etc choose to use overlays. They
have many packages which need to be kept in sync for every release.
For single packages though, an overlay is overkill. Also, overlays are
purely optional; there is no Gentoo policy requiring their use. In fact,
overlays are considered unsupported.

If you don't know that something is going to break, it can go straight
to ~arch. If you know that something will cause breakage, sure, it can
go to package.mask. Or, if a bug that causes many systems to break is
found in a package, the package should go to package.mask until the bug is fixed.

> > > I agree that masking for testing is like having a 3rd branch, but I'm
> > > not convinced that this is a bad thing.  ~arch should be for packages
> > > that have received rudimentary testing and which are ready for testing
> > > by a larger population.  Masking should be used for packages that
> > > haven't received rudimentary testing - they might not have been tested
> > > at all.
> > 
> > The concern with this argument is  the definition of rudimentary testing
> > is subjective, especially when a package supports many possible
> > configurations.
> 
> Well it can never be fresh from upstream, even if that upstream is a
> Gentoo developer.

What does this mean? We drop packages that are "fresh from upstream"
into ~arch all the time.

> eudev is more of a sanity filter, and doesn't claim
> to be upstream.

Eudev is a fork, so it is its own upstream. Also, it is used by some
distros outside of Gentoo.

> If anything we want more constraints when a Gentoo dev
> is "lead" on a project, as there are even less dykes in the way.

Adding more constraints to software that has Gentoo devs as the upstream
authors would be a policy I couldn't support. That is a form of
discrimination against our own devs.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]