public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: William Hubbs <williamh@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: package.mask vs ~arch
Date: Fri, 1 Aug 2014 10:19:33 -0500	[thread overview]
Message-ID: <20140801151933.GA1421@linux1> (raw)
In-Reply-To: <20140801091333.GB17213@rathaus.eclipse.co.uk>

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

      reply	other threads:[~2014-08-01 15:19 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
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 [this message]

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=20140801151933.GA1421@linux1 \
    --to=williamh@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