From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 93BA913877A for ; Mon, 30 Jun 2014 14:48:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 940F7E0A6C; Mon, 30 Jun 2014 14:48:29 +0000 (UTC) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A5FB3E09D2 for ; Mon, 30 Jun 2014 14:48:28 +0000 (UTC) Received: by mail-ve0-f181.google.com with SMTP id db11so8261874veb.12 for ; Mon, 30 Jun 2014 07:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=zYbtqjbwxZKyDlrehIgF1H2jcrw6iShEAdkOl77regA=; b=WPc/NzTlypFKyTOTuznk7CLem5MVStgFP5NBrGt0JedD4ltD0lQTMMWLoQmdDxZr/7 WB5WbIuIvROA/xub9bFHSJEe1jnTEGuFl8I54Ehw+EzIvVhX7TV+h6JY6PRYBD+oFSe4 O5DzFOHaPZajU3EVbM8KC8xQxz47phG2C0fgotR9xC6soNiHaCzZZCQe+IoP3BwX04nv KFdKkBGm7kFOkgG6Lh/FgzkBqXlTlrBpYrw+fIn6hfzz5kfrU3U3aiOP2SKLVVE9ShOU zxlBJIQiNL1ynjNJPkrDsFbG8Wmzdhp3qKV6fK82HiAYYf4aVv02bRgkodZolAAJSDHL e68w== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.58.132.70 with SMTP id os6mr2561724veb.36.1404139702667; Mon, 30 Jun 2014 07:48:22 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.72.19 with HTTP; Mon, 30 Jun 2014 07:48:22 -0700 (PDT) In-Reply-To: <20140630161555.15ab3403@marga.jer-c2.orkz.net> References: <20140630040153.GA668@linux1> <20140630161555.15ab3403@marga.jer-c2.orkz.net> Date: Mon, 30 Jun 2014 10:48:22 -0400 X-Google-Sender-Auth: 4IG74UM2mkJhuNJjZnKxLUGOYyg Message-ID: Subject: Re: [gentoo-dev] package.mask vs ~arch From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: faabd504-e381-4b93-8692-c12fdafd7d45 X-Archives-Hash: e3748e581ba2557c55aaaa436f0d5201 On Mon, Jun 30, 2014 at 10:15 AM, Jeroen Roovers wrote: > On Mon, 30 Jun 2014 09:25:27 -0400 > Rich Freeman wrote: > >> Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED >> AT ALL. The maintainer knows that they compile, and that is it. > > Developers who "HAVEN'T [...] TESTED AT ALL" and still commit their > changes to the tree should immediately hand in their toys and leave > the project. What harm does it cause to commit an untested package in a masked state to the tree? Doing so violates no policy, and IMHO it shouldn't be considered a policy violation either, especially if it makes life easier on anybody who has actually volunteered to test it. Real life example: Mythtv has a fixes branch which I try to update monthly, but sometimes it is every few months. Sometimes users ping me because a fix is likely to be useful to them, or perhaps to others as well (especially if it has been a while since my last update). Generally I don't put new updates in the tree until I've run them for a day or two at home. That to me is the threshold of minimal testing appropriate for ~arch, but not stable. Some users are clamoring for a new set of fixes, but I don't have time to deploy it at home and test for a day or two. Mythtv is not compatible across versions and involves client/server tiers, a php web interface, and plugins. So, I bump it, test-compile it, and mask it and announce it in the bug so those who really want it can have it. It is probably fine, but I haven't so much as run it so I'm not going to foist it on ~arch. A few days or a week later I get around to testing it myself, and unmask it. Just what value does the distro obtain by banning that workflow? Sure, I could stick it in my overlay, but that is an extra step for users. I just don't see a quality issue here unless we're talking about neglect, and in general neglect will cause quality issues no matter how many rules we create. Rich