public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Roy Bamford <neddyseagoon@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] package.mask vs ~arch
Date: Mon, 30 Jun 2014 21:50:35 +0100	[thread overview]
Message-ID: <1404161463.1680.0@NeddySeagoon_Static> (raw)
In-Reply-To: <20140630040153.GA668@linux1> (from williamh@gentoo.org on Mon Jun 30 05:01:53 2014)

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

  parent reply	other threads:[~2014-06-30 20:51 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 [this message]
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=1404161463.1680.0@NeddySeagoon_Static \
    --to=neddyseagoon@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