Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Anthony G. Basile]

On 10/8/15 10:09 AM, Michał Górny wrote:
>
> Dnia 8 października 2015 14:58:14 CEST, "Anthony G. Basile" <blueness@g.o> 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@g.o
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA