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 10:11:58 -0400	[thread overview]
Message-ID: <1404137518.29783.3.camel@rook> (raw)
In-Reply-To: <53B14A33.7040108@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2014-06-30 14:13 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 [this message]
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=1404137518.29783.3.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