package.mask vs ~arch

classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

package.mask vs ~arch

William Hubbs
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 <[hidden email]> 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


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: package.mask vs ~arch

Alexandre Rostovtsev-2
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 <[hidden email]> 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.

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: package.mask vs ~arch

Andreas K. Huettel
In reply to this post by William Hubbs
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
[hidden email]
http://www.akhuettel.de/


signature.asc (985 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: package.mask vs ~arch

hasufell
In reply to this post by William Hubbs
Rich Freeman:> On Sun, Jun 29, 2014 at 8:36 AM, hasufell
<[hidden email]> 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).

Reply | Threaded
Open this post in threaded view
|

Re: package.mask vs ~arch

Rich Freeman
In reply to this post by William Hubbs
On Mon, Jun 30, 2014 at 12:01 AM, William Hubbs <[hidden email]> wrote:

>
> On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote:
>> On Sun, Jun 29, 2014 at 8:36 AM, hasufell <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: package.mask vs ~arch

Alexandre Rostovtsev-2
In reply to this post by hasufell
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.

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: package.mask vs ~arch

Jeroen Roovers-3
In reply to this post by Rich Freeman
On Mon, 30 Jun 2014 09:25:27 -0400
Rich Freeman <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: package.mask vs ~arch

Rich Freeman
In reply to this post by hasufell
On Mon, Jun 30, 2014 at 7:29 AM, hasufell <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: package.mask vs ~arch

Rich Freeman
In reply to this post by Jeroen Roovers-3
On Mon, Jun 30, 2014 at 10:15 AM, Jeroen Roovers <[hidden email]> wrote:
> On Mon, 30 Jun 2014 09:25:27 -0400
> Rich Freeman <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: package.mask vs ~arch

Ian Stakenvicius-2
In reply to this post by Rich Freeman
-----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
> <[hidden email]> wrote:
>>
>> On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote:
>>> On Sun, Jun 29, 2014 at 8:36 AM, hasufell <[hidden email]>
>>> 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-----

Reply | Threaded
Open this post in threaded view
|

Re: package.mask vs ~arch

Jeroen Roovers-3
In reply to this post by Rich Freeman
On Mon, 30 Jun 2014 10:37:11 -0400
Rich Freeman <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: package.mask vs ~arch

Michał Górny-5
In reply to this post by Ian Stakenvicius-2
Dnia 2014-06-30, o godz. 11:22:07
Ian Stakenvicius <[hidden email]> 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
> > <[hidden email]> wrote:
> >>
> >> On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote:
> >>> On Sun, Jun 29, 2014 at 8:36 AM, hasufell <[hidden email]>
> >>> 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

signature.asc (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: package.mask vs ~arch

Ian Stakenvicius-2
-----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 <[hidden email]>
> 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
>>> <[hidden email]> wrote:
>>>>
>>>> On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman
>>>> wrote:
>>>>> On Sun, Jun 29, 2014 at 8:36 AM, hasufell
>>>>> <[hidden email]> 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-----

Reply | Threaded
Open this post in threaded view
|

Re: package.mask vs ~arch

Jeroen Roovers-3
On Mon, 30 Jun 2014 11:40:19 -0400
Ian Stakenvicius <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: package.mask vs ~arch

William Hubbs
On Mon, Jun 30, 2014 at 06:13:45PM +0200, Jeroen Roovers wrote:

> On Mon, 30 Jun 2014 11:40:19 -0400
> Ian Stakenvicius <[hidden email]> 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


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: package.mask vs ~arch

Rich Freeman
In reply to this post by Jeroen Roovers-3
On Mon, Jun 30, 2014 at 12:13 PM, Jeroen Roovers <[hidden email]> wrote:

> On Mon, 30 Jun 2014 11:40:19 -0400
> Ian Stakenvicius <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: package.mask vs ~arch

Jeroen Roovers-3
On Mon, 30 Jun 2014 12:40:59 -0400
Rich Freeman <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: package.mask vs ~arch

Rich Freeman
In reply to this post by William Hubbs
On Mon, Jun 30, 2014 at 12:32 PM, William Hubbs <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: package.mask vs ~arch

William Hubbs
On Mon, Jun 30, 2014 at 01:07:17PM -0400, Rich Freeman wrote:

> On Mon, Jun 30, 2014 at 12:32 PM, William Hubbs <[hidden email]> 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 <[hidden email]> 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


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Tom Wijsman-2
In reply to this post by Alexandre Rostovtsev-2
On Mon, 30 Jun 2014 02:04:20 -0400
Alexandre Rostovtsev <[hidden email]> 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  : [hidden email]
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

signature.asc (484 bytes) Download Attachment
123