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

[Michał Górny]

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.

>>
>> 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

-- 
Best regards,
Michał Górny