valhalla openjdk repository
maurizio.cimadamore at oracle.com
Tue May 16 20:58:13 UTC 2017
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.
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.
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.
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.
> ----- 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
>> We are in the process of updating the parent to be based off of jdk10/hs to have
>> 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
>> notify you that the repository is open for business.
>> p.s. Note that we have saved the existing valhalla repository to
>> valhalla/valhalla9 and made it read-only
More information about the valhalla-dev