RFC: JDK 9 Sandbox Forest Proposal

[Mike Duigou]

On Sep 22 2014, at 12:03 , Mario Torre <neugens.limasoftware at gmail.com> wrote:

> I also think that if we start using branches, it will end up being
> more overhead than using multiple mercurial repositories...

Yes, it's possible this will be the case for some users. If you don't need collaboration with other users for specific projects or bugs then it might be best to continue to MQ or patches upon the mainline repos. 

Cheers,

Mike

> 
> Cheers,
> Mario
> 
> 2014-09-22 10:38 GMT+02:00 Volker Simonis <volker.simonis at gmail.com>:
>> On Sun, Sep 21, 2014 at 4:41 PM, David Chase <david.r.chase at oracle.com> wrote:
>>> I vote yes, I have some feedback/questions on the proposal:
>>> 
>>> On 2014-09-19, at 1:15 PM, Mike Duigou <mike.duigou at oracle.com> wrote:
>>>> Goals:
>>>> 
>>>> - Open          : Use OpenJDK public infrastructure
>>>> - Low-friction  : Minimal start-cost and no delays
>>> 
>>> I ran into one specific problem attempting to add stuff to
>>> jdk libraries as part of Panama, which is that the creation
>>> of a new module is error-prone.  In my case, it is only
>>> error-prone, I never succeeded, I assume I missed some
>>> crucial step.  I think we want people to be able to work in
>>> this style because at least one of the IDE tools (NetBeans)
>>> can sometimes get confused when working with a subset of the
>>> source files in java.base.  (and even when it works, it’s another
>>> little speedbump on the way to configure NetBeans to work
>>> properly in this case)
>>> 
>>> So I think we need to address this and write up a recipe,
>>> including the need to regenerate configure files etc before
>>> commit.  Ideally the recipe will contain copy-and-pasteable
>>> commands where that is possible.
>>> 
>>>> Specifics:
>>> 
>>>> - Neither jcheck nor hgupdater is enabled for this forest.
>>> 
>>> Do we want something like jcheck to keep the code moderately
>>> clean — for example, there’s the personal “fixit” script
>>> I’ve informally put up for consideration for Codetools (it’s
>>> not a commit hook, it merely checks a bunch of source code
>>> rules and gives you the the option of an automated fix).
>>> This is purely a matter of keeping code clean, on the off
>>> chance that we do include some of it in a future release.
>>> 
>>>> - All development happens on branches.
>>> 
>>> It would be lovely to have a short tutorial on how we do
>>> this written up and put in an easy-to-access place.
>>> Branching still makes me nervous.
>>> 
>> 
>> I'm also not familiar with branches. How do branches work in a
>> Mercurial forest? Is it possible to easily develop on a branch if you
>> need to push to different repositories within the whole sandbox forest
>> (i.e. hotspot and jdk). Is it somehow possible to enforce the smae
>> branch on all the repos in a forest? I agree that the OpenJDK project
>> process is much too heavyweight for many smaller project, but in the
>> end you always get a complete forest. I'm just curious if cross
>> repository changes can be easily developed with branches.
>> 
>> Thanks,
>> Volker
>> 
>>> David
>>> 
> 
> 
> 
> -- 
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
> 
> Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> Read About us at: http://planet.classpath.org
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
> 
> Please, support open standards:
> http://endsoftpatents.org/