public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Alexandre Rostovtsev <tetromino@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] package.mask vs ~arch
Date: Mon, 30 Jun 2014 02:04:20 -0400	[thread overview]
Message-ID: <1404108260.29783.1.camel@rook> (raw)
In-Reply-To: <20140630040153.GA668@linux1>

[-- 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 --]

  reply	other threads:[~2014-06-30  6:05 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-30  4:01 [gentoo-dev] package.mask vs ~arch William Hubbs
2014-06-30  6:04 ` Alexandre Rostovtsev [this message]
2014-06-30 18:51   ` [OT] " Tom Wijsman
2014-06-30  8:12 ` Andreas K. Huettel
2014-06-30 18:57   ` Tom Wijsman
2014-06-30 11:29 ` hasufell
2014-06-30 14:11   ` Alexandre Rostovtsev
2014-06-30 14:37   ` Rich Freeman
2014-06-30 15:27     ` Jeroen Roovers
2014-06-30 19:49       ` Joshua Kinard
2014-06-30 20:36         ` Jeroen Roovers
2014-07-02 10:10     ` Peter Stuge
2014-06-30 13:25 ` Rich Freeman
2014-06-30 14:15   ` Jeroen Roovers
2014-06-30 14:48     ` Rich Freeman
2014-06-30 19:11       ` Tom Wijsman
2014-06-30 19:19         ` Rich Freeman
2014-07-02 17:56           ` Tom Wijsman
2014-07-02 18:04             ` Rich Freeman
2014-07-01 12:41     ` Patrick Lauer
2014-07-01 13:48       ` Rich Freeman
2014-07-05 21:08     ` Greg KH
2014-07-06 13:07       ` hasufell
2014-07-06 19:30         ` William Hubbs
2014-06-30 15:22   ` Ian Stakenvicius
2014-06-30 15:36     ` Michał Górny
2014-06-30 15:40       ` Ian Stakenvicius
2014-06-30 16:13         ` Jeroen Roovers
2014-06-30 16:32           ` William Hubbs
2014-06-30 17:07             ` Rich Freeman
2014-06-30 17:49               ` William Hubbs
2014-06-30 19:18             ` Tom Wijsman
2014-06-30 16:40           ` Rich Freeman
2014-06-30 16:55             ` Jeroen Roovers
2014-06-30 19:14         ` Tom Wijsman
2014-06-30 19:44           ` Ian Stakenvicius
2014-07-02 17:58             ` Tom Wijsman
2014-06-30 21:11         ` Roy Bamford
2014-06-30 20:01   ` Joshua Kinard
2014-06-30 20:50 ` Roy Bamford
2014-08-01  9:13 ` [gentoo-dev] " Steven J. Long
2014-08-01 15:19   ` William Hubbs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1404108260.29783.1.camel@rook \
    --to=tetromino@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox