Fwd: OpenJdk Mirror for Github
dalibor.topic at oracle.com
Tue Jul 28 14:17:50 UTC 2015
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
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
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
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
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.
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +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
More information about the adoption-discuss