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 DC8031387FD for ; Sat, 29 Mar 2014 19:47:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C5ECBE0AB0; Sat, 29 Mar 2014 19:46:55 +0000 (UTC) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2E981E0AAF for ; Sat, 29 Mar 2014 19:46:54 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id ik5so7419256vcb.28 for ; Sat, 29 Mar 2014 12:46:54 -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=MxvamHeX26Eu3l9a5QFsoBLzQhlbbixwiVuS6zOmPfc=; b=FxAddbK9KkN+Q+U4dfMfqIVwChKk0gj0n4wY2nj3qDIZD3Y6d1YBCgB4wxepkOUtjm +OOnL8oOz/jRDlj+FVn9jN3AsekczXU1SeDThmEXXAS+OGIPP5li4xPaaBShX9h6EkDg H14Kz3KGiF/kE3VvctBrI8S0HE4J1spXH69K9yVkwJgxxhvHOncPhwhLJHLBmpHkboTj p8rQpXRyE86bQFNYoOqf0dspxkchD/nU9hw1czGoiUVuTsIu7K9n5vMpWHFF5rXG1fP3 E2A28eaXhBhfKYJStr49fDD+OrbCxuUb9a6dG9NWWtX1FXJ+nSB2z9V0E8YkRe15aAEa eNQQ== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.58.57.42 with SMTP id f10mr14132804veq.1.1396122414100; Sat, 29 Mar 2014 12:46:54 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.29.142 with HTTP; Sat, 29 Mar 2014 12:46:54 -0700 (PDT) In-Reply-To: <20140329143634.GA31923@laptop.home> References: <53342A5F.70903@gentoo.org> <20140329143051.791839e6@gentoo.org> <5336D386.6080609@opensource.dyc.edu> <20140329143634.GA31923@laptop.home> Date: Sat, 29 Mar 2014 15:46:54 -0400 X-Google-Sender-Auth: xVuUesXQVBm7-iTbhNC235Mh1dc Message-ID: Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08 From: Rich Freeman To: gentoo-project@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 2c4aa4c0-4cbc-4986-9088-928806783756 X-Archives-Hash: 235071a5a1f2ab24b0eff1039c800f38 On Sat, Mar 29, 2014 at 10:36 AM, William Hubbs wrote: > > We are supposed to be a team, and if a few people aren't team players, > I would rather see energy spent on fixing that issue instead of trying > to legislate every possible corner case. So, a few thoughts on the whole issue in general. 1. When somebody wants to do something in a way completely different from how things have been done before or in a way that impacts how many packages will be maintained, it is best to discuss it on the lists first. That doesn't mean that you can't proceed without unanimous consent, but rather that even good ideas can become better ideas with more input. That said, when an issue comes up those who object need to at least speak up ahead of time, because after-the-fact isn't the time for I-told-you-so. That has come up a few times lately - you don't need to have the last reply on the thread to win the argument, but that doesn't mean that you shouldn't speak up at all. 2. When there is a change in the tree that threatens to be disruptive to users/dev/etc QA has the right to step in. The necessity of doing this should really be considered first - if simply saying "hold on, don't do any more of this for a few days" is sufficient to get by, that should be preferred over masks/bans/etc. On the other hand, if users are being adversely affected by something and this will get worse with time, it is better to stop the bleeding. Think of it like asking a court for an emergency stay/injunction/etc - courts generally prefer to hear the whole case before taking action, but if there is some kind of irreversible harm at stake, they'll act first and sort it out later. Obviously QA should manage its own guidelines as to when individuals should act in the name of QA. 3. In general the absence of an explicit policy should never be considered grounds for ignoring #1 or preventing #2. The real principle is cooperation and managing disruptive change. QA can step in even if you can't quote a specific rule that was broken (though they should be careful before doing so), and I really don't want to hear excuses like "well, there was no rule saying I had to play nicely with the other kids." We really don't want to have to maintain the Code of Gentoo Regulations. So, I'd certainly endorse that things like profile changes, eclass changes, and changes that impact many reverse-deps should be announced on the list and coordinated in general if they aren't routine. That said, I don't see the need to codify this in some kind of explicit policy - I'd argue that it already is policy. I don't want to get into back-and-forth on how to word a policy so that a dev masking their own package is fine but a dev removing bash from the system set isn't. If somebody can't tell the difference between these, they shouldn't have commit access. Rich