Fwd: OpenJdk Mirror for Github

[dalibor topic]

On 28.07.2015 14:19, Stanislav Baiduzhyi wrote:
> On 27/07/15 20:11, dalibor topic wrote:
>> OpenJDK does not work with pull requests, so mirroring does not really
>> seem to provide long term, practical benefits.
>
> Other than the process was established long long before github/bitbucket
> got usable, are there any strong reasons not to work with pull requests?

There are two different issues here - one is the lack of long term, 
practical, benefits (i.e. no positives), the other is the presence of 
negative aspects.

Considering that Torvalds already provides a laundry list of items that 
he considers to be problematic with pull requests, I'm not sure that 
adding items to that list is very productive - even if there were no 
strong reasons against pull requests, the lack of strong reasons for 
them is a heavy argument against the belief that spending time and 
effort on mirroring leads to long term practical benefits.

>> For a spirited discussion of some of the problems one may have with
>> using GitHub pull requests without also subscribing to a GitHub-specific
>> workflow, please refer to the comments from Linus Torvalds, the creator
>> of Git in this thread: https://github.com/torvalds/linux/pull/17 .
>
> But that was about linux kernel development, from quite a stubborn
> person (who even wrote his own vcs for his own needs!). Are there some
> specific things required by openjdk development that are missing on
> github or bitbucket?

The added complexity of supporting pull requests along with the current 
mode of operation (which lets us actually ship releases, which is rather 
important to the broader ecosystem) is even less likely then mirroring 
to be worth the effort ...

For a completely different aspect, consider that pull requests work 
backwards, from the end result - a proposed changeset that's in theory 
(almost) ready to merge.

That's suboptimal, to put it mildly.

In OpenJDK, you'd want to first discuss a proposed change (rather than 
changeset), in order to be better informed about its design, impact, 
risks and so on. Once you understand that the problem you want to solve 
is actually worth solving in a specific way, at a specific time ... then 
the proposed changeset for review is the result of that design and 
discussion process.

By instead centering the attention on pull requests, there is a 
permanent source of conflict around sunk costs - the potential 
contributor has already sunk their time and effort into producing 
something, often in splendid isolation, which they hold to be good 
enough to be included in the main project.

That's typically not going to be the case, on the first attempt at 
least. Sturgeon's law is as true for YouTube comments as it is for pull 
requests.

A nice blog post on that is at 
http://josephg.com/blog/github-pull-requests/ - and for the other side 
of that coin, see http://gist.io/3444052 .

Poor pull requests on the other hand are a drag on reviewers and 
maintainers, as explained in 
http://blog.spreedly.com/2014/06/24/merge-pull-request-considered-harmful/ 
due to the sunk cost conflict described above.

In addition, on complex projects, there are many external factors in 
play, like milestone schedules, which dictate what kind of changes are 
acceptable at what time, or contributor agreements, which dictate whose 
changes are acceptable, to name a few.

Such external factors don't mesh well with pull requests - you can't 
just disable them for a few weeks/months while you're in rampdown and 
focusing on high impact issues, for example.

cheers,
dalibor topic
-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment