valhalla openjdk repository

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "Karen Kinnear" <karen.kinnear at oracle.com>
> Cc: valhalla-dev at openjdk.java.net
> Envoyé: Mardi 16 Mai 2017 22:58:13
> Objet: Re: valhalla openjdk repository

> On 16/05/17 21:14, Remi Forax wrote:
>> Hi Karen, hi all,
>> the main issue i see with branches is that, they easily becomes incompatibles,
>> which means that less people will test before things are integrated in main
>> workspace.
>> by example for amber, lvti and lambda-leftover both change the frontend compiler
>> in an incompatible way,
>> even if it can be easily fixed, it's an unnecessary barrier for testing in my
>> opinion.
>>
>> I believe that the default repo should contains the code of all branches
>> automatically integrated so people will be able to test without messing with
>> branches.
> Hi Remi,

Hi Maurizio,

> the branch-based solution is an attempt to work with openjdk projects in
> a more flexible way. Big projects such as valhalla or amber, often ends
> up (either accidentally, as Valhalla), or by design (as Amber) to be
> containers for several isolated sub-projects. From a perspective of
> trying to keep the code fresh, it is much better to try not to put
> everything in the same place - as that will lead to the usual issues:
> 
> * proliferation of both compile-time and runtime-flags
> * accumulation of dead code
> * increasing pain when doing merges (which are mostly a manual process)
> 
> I agree that, when it comes to try the bits out, the branch-based
> approach feels inferior to what we had before, but we have ideas on how
> to improve on that. In the current infrastructure we can easily setup
> 'dependent' branches, which can contain multiple branches at once, and
> also receive the automatic merge treatment. So it's just a matter of
> mere infra programming to create branches for the subset of features
> that feel more ready for widespread testing.

cool

> 
> Another obstacle to all this is availability of binary snapshot - as
> we'd like to reduce entry barrier and not to have people mess with
> source code in order to test. This is another thing in our radar which
> will be addressed.

with the problem that, at least for jigsaw, there are two binary builds named jdk9 and jdk9 + jigsaw so a lot of people have believed that the jdk9 binaries was not containing jigsaw, but perhaps it's just a naming thing. 

> 
> So, while I agree that some edges of the new infra are sharp, I think
> this approach has a lot more room to improve than the old one - and it
> makes for a much saner process when it comes to integrate the various
> features into separate JDK changesets (and reviews) - not so long ago
> I've spent a significant portion of my time - and sanity! - trying to
> extract a set of curated patches out of the monolithic lambda repositories.
> 
> Maurizio

Rémi

>>
>> Rémi
>>
>> ----- Mail original -----
>>> De: "Karen Kinnear" <karen.kinnear at oracle.com>
>>> À: valhalla-dev at openjdk.java.net
>>> Envoyé: Mardi 16 Mai 2017 00:05:04
>>> Objet: valhalla openjdk repository
>>> Please hold off making changes to the valhalla openjdk repository until further
>>> notice.
>>> We are in the process of updating the parent to be based off of jdk10/hs to have
>>> the
>>> latest changes.
>>>
>>> When the repository is ready, I will let you know.
>>>
>>> We are moving to a branch model, so that we will NOT be pushing changes to the
>>> valhalla/valhalla repository.
>>>
>>> Instead we will create branches underneath that for specific projects, including
>>> to start with
>>> mvt (minimal value types) and
>>> nest mates (JEP 181: nested class access controls)
>>>
>>> Once those are created, give us time to push the merged code to mvt and then I
>>> will
>>> notify you that the repository is open for business.
>>>
>>> thanks,
>>> Karen
>>>
>>> p.s. Note that we have saved the existing valhalla repository to
> >> valhalla/valhalla9 and made it read-only