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 BBA081381F3 for ; Mon, 1 Jul 2013 01:20:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 31195E0996; Mon, 1 Jul 2013 01:20:12 +0000 (UTC) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 835D9E0961 for ; Mon, 1 Jul 2013 01:20:11 +0000 (UTC) Received: by mail-ve0-f178.google.com with SMTP id pb11so3280425veb.37 for ; Sun, 30 Jun 2013 18:20:10 -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 :x-google-sender-auth:message-id:subject:from:to:content-type; bh=hLIYuAjkL3kx1nvM3y9M9Hr49Xg/GRQ+FvmOsgI12lQ=; b=QeqVXHAAyqOQJt4Ne362MbG24uDH7R+yb/q2YR+AAyB9inlUC6M+W6tsv39vluq+kL QP984gLs0zeNcY3ra2g9lvtb0AWAn30imnKSFNKk9jkYKYToTjdIRX+UUYzJSsdz4JDf j7X4ilNs7m4XSfJPO+0PgLxc493xtvGdCxOpd5WQNelX8MsruKFOiDaKPHuqInpRW7Ln QyqjG+GyC5+5w6RnhVgXa4qK0WRwbiyDZGERs5VxI2s581lGbSB0CFVwE3YRy3yjqNiX pjMp3xGG68dXISrkHN6zxOAeK13k/VJE0zqfunPsA5PpMUXGLa89KMi6dD8CGp98yapN EAfA== 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.182.103 with SMTP id ed7mr8992408vec.70.1372641610605; Sun, 30 Jun 2013 18:20:10 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.163.71 with HTTP; Sun, 30 Jun 2013 18:20:10 -0700 (PDT) In-Reply-To: <20130701005911.GA1936@linux1> References: <51BF597B.6060600@gentoo.org> <51CF1759.10903@gentoo.org> <51CF4529.7010307@gentoo.org> <51D011C1.2040606@gentoo.org> <20130630185215.GA968@linux1> <1372625765.17485.18.camel@big_daddy.dol-sen.ca> <20130701005911.GA1936@linux1> Date: Sun, 30 Jun 2013 21:20:10 -0400 X-Google-Sender-Auth: feDYLccrcsJTIa2F83-VtQ1z4Fk Message-ID: Subject: Re: [gentoo-project] Re: Questions for Candidates (was: Questioning/Interviewing council nominees) From: Rich Freeman To: gentoo-project@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: f5233960-458e-4fe3-a6d5-a2043262ae73 X-Archives-Hash: 75d4d33b62c241786d8f4be97a163901 On Sun, Jun 30, 2013 at 8:59 PM, William Hubbs wrote: > Nothing is an absolute. I'm not saying that anyone who doesn't like > something a maintainer does should be able to force the maintainer to do > what they want. Ditto. I only want maintainers to not be able to get in the way of reasonable and well-supported projects and other teams. If a maintainer just hates having foo-1.2 in the tree because they put foo-1.3 in the tree yesterday, and foo-1.2 is stable on x86, we already require them to wait until 1.3 can be stabilized (perhaps rapidly if a security issue). Maintainers already must coordinate with other projects. In general I'm not in favor of forcing maintainers to do anything beyond fixing glaring QA issues. If a maintainer wants to have a non-upstreamed patch that doesn't cause issues that isn't a big problem IMHO. However, if another dev wants to co-maintain and make that non-upstream patch USE-dependent and support the work, the original maintainer must allow them to do so. If the x32 project wants to add a conditional patch to support their arch and they are willing to follow-through on support, the original maintainer must allow this. Non-maintainers must always collaborate with maintainers, but the intent of that isn't so that maintainers can block other projects. I've been in the place of having somebody come along and bump an EAPI on me or make other changes that I'd honestly have been more comfortable taking my time with. I understand that the job of a maintainer is easier if they can block outside changes entirely. However, we need to strike a balance. And on the other side of things I'm completely against scripted tree-wide changes without a great deal of care (honestly, I'd prefer that all scripted changes against the tree aside maybe from package renames be reviewed on -dev first unless they're confined to within a project's domain - such as the KDE team making a change to only KDE packages). I'm also against fly-by commits where a dev makes changes but isn't willing to stand behind them. I think that is what we need to protect against, not well-organized projects adding config files to daemons. Rich