From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 476AE138334 for ; Tue, 22 Oct 2019 00:55:23 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3DBF9E0B35; Tue, 22 Oct 2019 00:55:19 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id DE2FAE0B1D for ; Tue, 22 Oct 2019 00:55:18 +0000 (UTC) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mattst88) by smtp.gentoo.org (Postfix) with ESMTPSA id A3E8434C1B5 for ; Tue, 22 Oct 2019 00:55:17 +0000 (UTC) Received: by mail-io1-f54.google.com with SMTP id 1so6960813iou.4 for ; Mon, 21 Oct 2019 17:55:17 -0700 (PDT) X-Gm-Message-State: APjAAAVVqiFMGG0ZAuxRPJqJvDyrCOJgwDJfJDkwxMbyUzk6NEXfEJzM 26R6JDy5JZ/FzKODPqIKl2RRp+GBhbTAHOfKHMA= X-Google-Smtp-Source: APXvYqy1qxULG/gqUnDDMFsP3H+JSU1tcP5nuQLyAXsneoAZ+t01Y+Us3KNTypebzsmkJ47sQ6xotl9Nwnut2fuAIbE= X-Received: by 2002:a5d:9f17:: with SMTP id q23mr99208iot.100.1571705715606; Mon, 21 Oct 2019 17:55:15 -0700 (PDT) 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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: In-Reply-To: From: Matt Turner Date: Mon, 21 Oct 2019 17:55:04 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [gentoo-dev] Proposal: change to default policy of doing changes to packages that are maintained by other developers To: gentoo development Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 89927e2b-39e1-4825-a11b-dd1a0ff21966 X-Archives-Hash: c426b0ab45942cdd83719cc67a20edc3 On Mon, Oct 21, 2019 at 10:37 AM Piotr Karbowski wrote: > > Hi, > > I'd like to bring the topic of defining default policy to do changes to > packages within ::gentoo that one does not maintain. > > This topic goes back from time to time on #gentoo-dev, and as I was > told, it was originally sent to gentoo-dev mailing list by robbat2 (I > failed to find this in archive, so if anyone have copy of it, please share). > > Current policy is to never touch ebuild that one did not claim as > maintainer unless maintainer of said package allowed you to do so. > > This is a bit unhealthy, especially when some developers that maintain > packages are out of reach, or the patches to update ebuild just rot on > the bugzilla and are not taken in by maintainers. > > What I'd like to end with would be to set a policy that allows any > developer with write access to ebuilds tree do changes that are small in > scope, like a minor bug fixes, adding missing flags, version bumps, > anything, that does not require complete overhaul of ebuild, with the > option to set in metadata.xml that policy for specified package is to > deny anyone but maintainers from doing changes. > > The packages that would require a flag to prohibit non-maintainers from > doing changes would of course be those of toolchain, or other big in > user base packages that are in very good shape, as in gnome packages, GNOME is not in good shape. > kde packages, X11 packages and so on. These are in good shape. > Of course, the policy would also define, that if there are any bug > introduced by changes that non-maintainer made, it's responsibility of > those who did the change in first place to fix it and clean any mess > that it has created. > > I personally am fine with others doing changes to packages I own, as > long as they won't break anything and I do know from the discussion on > #gentoo-dev, that there are others who have similar opinion about it. > > Those who feel territorial and those who believe only maintainers should > maintain specified packages can just set the flag in metadata.xml and > continue with the current state of things for their packages. > > The reason why I would like to get default policy to allow-all is that I > do not believe most of developers would want to go around all the > packages they own and set it manually to allow others doing changes even > if they're fine with others touching those packages. > > What do you think folks? I typically operate this way: If the package maintainer is active (on IRC, mailing lists, bugzilla) I file a bug. If no response after a week or two, depending on the importance of the change I commit it myself. If the package is not actively maintained (maintainer-needed@ or the maintainer has not touched the package in a long time while there are open bugs without response, etc) and the change is trivial (missing dependency, simple version bump for non-critical package, etc), then I'll just commit it directly. If the package is not actively maintained and the change is not trivial, I file a bug and try to get the maintainer to review. If they don't respond, I try to get others that may be interested to review and then commit after 2 weeks. For tree-wide stuff (package rename, removing amd64-fbsd keywords, $Header: ...$, etc) I think a mailing list post announcing what you're doing is a good idea. Wait a couple days for feedback and then do it. No need to get an ack from individual maintainers. I feel like these are pretty reasonable guidelines and have rarely gotten me yelled at. I know that a lot of the details of my personal behavior are subjective, but maybe that's good enough? Not sure. We seem to always have some disagreeable person force us to codify common sense. Am I missing any cases? The only thing I can think of is maintainers that are so territorial that try to prevent others from committing to their packages and also are not responsive to bug reports. Fortunately that is uncommon, but unfortunately it does still happen today. I don't really know how to solve that, but /that/ seems like the only real problem case to me.