From: William Hubbs <williamh@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] package.mask vs ~arch
Date: Sun, 29 Jun 2014 23:01:53 -0500 [thread overview]
Message-ID: <20140630040153.GA668@linux1> (raw)
[-- 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 --]
next reply other threads:[~2014-06-30 4:02 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-30 4:01 William Hubbs [this message]
2014-06-30 6:04 ` [gentoo-dev] package.mask vs ~arch 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
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=20140630040153.GA668@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