Fwd: OpenJdk Mirror for Github

[Kervin Pierre]

Martin,

On Tue, 2015-07-28 at 21:09 +0100, Martijn Verburg wrote:
> +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.
> 

Not sure the idea is to *replace* your "POST discussion" system, but
rather COMPATIBILITY with existing external workflows that treat
discussions as "out-of-band".  The discussion of the work could have
been pre/post/never-happened.

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

Corporate teams are used to hierarchies that protect/manage developer
resources.  After all, everyone is part of the same overall team and
gets paid by the same employer.

This is not the case with many Open-source projects, developers
volunteer and hence managing them as resources is optional.  

The existence of a Pull-Request does not necessitate the inclusion, or
even acknowledgement of this work.  Developers are free to fork and
update code as their see fit, and you are free to not accept a single
line of code that does not meet your requirements to an absolute 'T'.

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

Looking forward to Betterev and hope it's a success!  

Eventually when it's completed I'm sure it will do well with highly
motivated developers.  The kind of people who read a Java
'adoption-discuss' list :)  But I think the original goal was to engage
unmotivated/curious/dabbling developers.  And maybe get an additional
foot-in-the-door with that much larger group.  

Best regards,
Kervin


> Hope that all make sense!
> M
> 
> 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
> >
> 
>