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 B47241381F3 for ; Mon, 1 Jul 2013 10:01:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2C348E0969; Mon, 1 Jul 2013 10:01:22 +0000 (UTC) Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 85FC3E0968 for ; Mon, 1 Jul 2013 10:01:21 +0000 (UTC) Received: by mail-vb0-f50.google.com with SMTP id w16so3397139vbb.37 for ; Mon, 01 Jul 2013 03:01:20 -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 :content-transfer-encoding; bh=UHRG3WuDDiBp/NTPUL2vowZ2E6rsOPMn2JBgC+Q5D/A=; b=qHeZ6sCzf7e91uc4DOr4KSh7AYiuyFfK5GbRra/s+CMpIzeEMAZnGiCWdkz3ePGvvR 1mfePIpqPgasWeApchdE9FlrR1Js0vtSFibxLIx/7uTE6YdLW9RikPGEQHhGi3+Am+YL 188YFIRRFQprRYRmqPDfq83Aiy3aqj9WPfNY/W86PXssrIcReOD5hXA6A/rbR2vYR3g3 x+wFKFOcpw/iRoxaFYdjeDZ6XDdlSndT3ntmEH0d146q8otimPJQxi7Isoj2J2mDdJVX TN9tK2s4WTZOgUWMnc0Shw5Xj4UYhRAho0zgVsTUz/pjFJb35edJaT4qR447n4/EVREV gfFQ== 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.221.21.74 with SMTP id qr10mr9312630vcb.25.1372672880691; Mon, 01 Jul 2013 03:01:20 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.163.71 with HTTP; Mon, 1 Jul 2013 03:01:20 -0700 (PDT) In-Reply-To: <51D14CC1.9080500@gentoo.org> 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> <51D14CC1.9080500@gentoo.org> Date: Mon, 1 Jul 2013 06:01:20 -0400 X-Google-Sender-Auth: fNiX4eTByqZdrll_tvCPBFAUb_I 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=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 5f7513cf-3fea-425b-a9e7-5fe8401073d7 X-Archives-Hash: 7be4c52834cdd506ebae88004010969d On Mon, Jul 1, 2013 at 5:32 AM, Ch=C3=AD-Thanh Christopher Nguy=E1=BB=85n wrote: > Rich Freeman schrieb: >> 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. > > I did not say that maintainers can ignore policy. The removal of ebuilds > must follow certain rules which are set in policy. IMO this really doesn't say anything at all. Of course maintainers have to follow policy. The question is what should the policy be? The original question was whether we should be forking or splitting packages over adding single files when the maintainer doesn't want them in the original package. Right now we have no explicit policy governing this. I don't think it necessarily needs to be written down, but if people are going to refuse to cooperate using the lack of something written down as an excuse and devrel feels that they can't do anything about it in the absence of a written policy, then we'll need a new policy. I think the policy should basically amount to requiring devs to coordinate with maintainers, but that maintainers can not outright block well-supported project-related work without Council approval. Also, policy would be that anybody can become a maintainer of any package, but they're responsible for their actions and maintainers must coordinate. I don't think we need rules for everything. However, if the lack of a policy is causing paralysis then a policy should be created. That said, this might be a moot issue - the only Dev to really be vocal about blocking such changes asked to retire a week or two ago over this very debate. I'd probably wait until a real issue comes up, but I would not take my time about dealing with it (announce an immediate case-by-case decision and then write up a GLEP/etc over the next few weeks). > > With x32 specifically, a number of people including some upstreams think > that the whole concept is a bad idea. A case could be made for patches > that #ifdef x32 and which compile to a no-op on other arches, but even > those must be maintained. What if the patch no longer applies after a > version bump? Well, since I'm only talking about WELL-SUPPORTED project-related work, just ask the project team to fix the patch. If they don't in a reasonable timeframe, then it isn't well-supported and the maintainer can do whatever they want with it. Project teams should only take on patches if they think they can sustain them. Most likely for something like x32 they'd only do it for strategic packages anyway (toolchain, etc). This is no different than requiring arch teams to operate in a timely manner/etc. If a project is getting out of hand Maintainers can talk to the lead, and bring it to Council if necessary. Honestly, I think an issue here is that some would like Gentoo to slowly transform into a retirement community where nobody wants cars driving on the road after 7PM. I see Gentoo as a place where people can do things that are new and exciting, and yet still run a traditional system. For end users I want to contain disruption, and for maintainers I want to coordinate disruption, but if we want to be a place where innovation happens, disruption is going to be there. Advocates for disruptive changes should be required to properly coordinate and support these changes, but they should not be at the mercy of individuals who want to block these changes. > >> 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. > > That's great, and I encourage all developers to allow this too. But I am > against forcing anybody. I'm not going to force anybody to do anything they don't already have to do. I'm just not going to let them stand in the way. I think there is a balance, but right now we're moving too far in the direction of treating packages as the personal property of maintainers, and that needs adjustment. It is certainly possible to move too far in the other direction, and perhaps our current situation is the result of over-reaction to these kinds of problems in the past (devs running scripts against the tree and such). Rich