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 9650F13888F for ; Thu, 8 Oct 2015 15:01:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 20B5CE0814; Thu, 8 Oct 2015 15:01:57 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5E130E0810 for ; Thu, 8 Oct 2015 15:01:56 +0000 (UTC) Received: from greysprite.dite (cpe-74-77-145-97.buffalo.res.rr.com [74.77.145.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: blueness) by smtp.gentoo.org (Postfix) with ESMTPSA id 3EB06340C8D for ; Thu, 8 Oct 2015 15:01:55 +0000 (UTC) Subject: Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11 To: gentoo-project@lists.gentoo.org References: <1904237.nU16iSOlTl@kailua> <20150930204510.7e0bd29f.mgorny@gentoo.org> <20151008154237.c5b94b546444d7204ab91a98@gentoo.org> <56166864.2050204@gentoo.org> <9C591B75-DE0D-4AB6-8A6E-89FA178513BF@gentoo.org> From: "Anthony G. Basile" Message-ID: <5616855D.8000106@gentoo.org> Date: Thu, 8 Oct 2015 11:01:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 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 In-Reply-To: <9C591B75-DE0D-4AB6-8A6E-89FA178513BF@gentoo.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Archives-Salt: 0f63643f-329b-46d5-9f9d-b2946bf0249f X-Archives-Hash: 6ec9696be883b7a603337c37fdc38d55 On 10/8/15 10:09 AM, Michał Górny wrote: > > Dnia 8 października 2015 14:58:14 CEST, "Anthony G. Basile" napisał(a): >> On 10/8/15 8:42 AM, Andrew Savchenko wrote: >>> Hello all, >>> >>> On Wed, 30 Sep 2015 20:45:10 +0200 Michał Górny wrote: >>>> The second issue that may need Council's attention is developers' >>>> attitude towards pull request source via GitHub. >>>> >>>> One and a half month since enabling it, we already had almost 150 >> pull >>>> requests from Gentoo users (and a few Gentoo developers who use this >> as >>>> a collaboration tool). Sadly, some developers not only refuse to use >>>> GitHub (which is an acceptable choice) but also have very negative >>>> attitude towards users submitting pull requests and the developers >>>> helping with them. >>>> >>>> The point is, if we want users to submit pull requests, we should be >>>> handling them. Then we can't really agree on some developer refusing >> to >>>> look at the request, and requesting the user to re-send it some >> other, >>>> less convenient way. Or another developer just silently ignoring >> every >>>> request and rudely responding to pings. >>>> >>>> Since the amount of work necessary to proxy between users >>>> and developers who refuse to use GitHub is huge, I have prepared >>>> a script that opens Bugzilla bugs for GitHub pull requests >>>> and bidirectionally copies comments between them, therefore allowing >>>> Gentoo developers to handle pull requests via Bugzilla at their >>>> convenience. However, it is currently waiting for review and >> approval >>>> by Robin before it will get deployed. >>>> >>>> But even then, I need to make sure the developers will actually use >> it >>>> politely. Developers can't really close those bugs 'because it's >>>> GitHub', or 'attach a patch', or 'duplicate of #nnnnnn' (because >>>> it's a synced bug, it can't be magically coerced into existing bug). >>>> In fact, I mailed bug-wranglers about this already but I got no >> reply. >>> I'd like to ask the Council to consider pros and cons of this issue >>> with extreme care. Benefits and dangers of the integration with the >>> proprietary GitHub service were discussed many times already, >>> starting from [1]. >>> >>> While the GitHub integration allows to receive a bit more >>> contributions, it contains long-term dangers of the Gentoo Social >>> Contract violation and loosing independence of the infrastructure >>> and the development workflow itself. >>> >>> I propose that we should draw a line which should not be crossed to >>> satisfy both the Social Contract and freedom of people to use >>> whatever tools they want, including GitHub. As a first approximation >>> I suggest the following: >>> >>> All connections with external infrastructure should be done in a >>> such way, that in case this external infrastructure will instantly >>> and permanently disappear, we should not loss any valuable data >>> and metadata, including commits, commit history, discussions, >>> patches, issues, bug reports and so on. >> Thanks for this language Andrew. It reflects my concerns and I can >> support it in the council. >> >>> As far as I understand Mgorny's proposal, it implies that pull >>> request issues and patches will be mirrored on bugzilla, but not >>> patches themselves. In my opinion this is not acceptable, since >>> violates both the Social Contract (by dependence on propietary >>> metadata, such as GitHub issues (and pull request is a special type >>> of issue on GitHub)) and Bugzilla's policy of having all patches >>> attached to the Bugzilla. >> I'm hopeful that Michal will be able to figure out a technical >> solution. >> >> I have one situation where I wanted a user to post his patches to our >> bugzilla for discussions but he did not. As a result I was unable to >> discuss them on our bugzilla, nor commit them in their current state. >> I >> could have discussed them on github but I did not want to create a long >> >> discussion history there, since that's supposed to be on bugzilla. So >> > > I see a few problems with that: > > 1. Should we create separate patches for each commit? If we don't, we discard history. > > 2. Should we attach the patches separately or tar them? The latter is inconvenient, the former can create a lot of patches. > > 3. Each update implies mass obsoleting of all patches. > > 4. Bugzilla has attachment size limit that we'd have to account for. > > Now imagine a pull request doing mass fixing. Git can handle that with ease. For bugzie it will be a serious mess. > > Potential alternative is to back-mirror pull requests in git.gentoo.org and work on that. But that's likely to cause even more uproar. So perhaps it was unwise for us to get into a situation where either 1) we violate the Social Contract or 2) we have to surmount a technically difficult situation. Perhaps those responsible for doing so should fix this. > >>> I honestly do not understand why developers should be forced to >>> violate the Social contract under the excuse of "being polite" to >>> GitHub contributors nor why such actions should be allowed at all. >> There may be a technical solution where we can mirror pull requests, >> bugs and patches on bugzilla. >> >> As a side note, this approach to pushing through agendas by creating >> situations where its easier to accept a "solution" rather than reject >> it >> is not going to work in Gentoo. We have lots of smart people that see >> through this. If we wind up being "impolite" to our users, the blame >> belongs to those who created that situation in the first place, not to >> the council. The Social Contract is correct and I'm not going to >> support anything that violates it. >> >>> [1] >>> >> https://archives.gentoo.org/gentoo-project/message/27e8b99db6fcd2654fc2548a605f0b70 >>> Best regards, >>> Andrew Savchenko -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA