Fwd: OpenJdk Mirror for Github

Martijn Verburg martijnverburg at gmail.com
Tue Jul 28 20:09:41 UTC 2015

+1 to this - a PR in 'GitHub land' is typically a piece of work PRE
discussion. This is true in many OSS projects (which is fine, as that's the
straw X idea to discuss around). In OpenJDK a webrev (a PR ~=) is typically
a POST discussion patch. That is, the debate around whether it is good for
Java has already been discussed.

Why? Well OpenJDK patches can/will impact mllions of developers and a
(unscientific guess) a Trillion dollar ecosystem so the (un)official
barriers are a lot higher than most OSS projects.

Although this can be frustrating, this is a good thing (Tm) for our
ecosystem at large. Java favours a slow and steady wins the race approach.

Betterev is about exploring how far we could move into the GitHub model of
development. Many ideas will be discarded and some will be incorporated. I
appreciate it may be frustrating to some, but it's purpose is to explore
ideas that may be part of OpenJDK workflow going forwards.

Hope that all make sense!

On Tuesday, 28 July 2015, dalibor topic <dalibor.topic at oracle.com> wrote:

> 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

Cheers, Martijn (Sent from Gmail Mobile)

More information about the adoption-discuss mailing list