KSL: moving forward

[Jonathan Gibbons]

Patrick,

Thank you for your feedback. You have noted some of the confusion
and that is part of what we are trying to clear up here.  I think the name
and description of KSL was meant to indicate "anything goes" but some
of the guidelines seemed to indicate more of a preparation ground for
inclusion in OpenJDK.  Both are useful in their own way, and we would
like to support both.

I agree with your comment that "bringing together the various experiments
people are working on for the compiler would be a good thing." However,
I don't think that a centralized Subversion repository is the right medium.
OpenJDK is using Mercurial, and it makes more sense to encourage folk
to work in a Mercurial repository, since that greatly simplifies their 
getting updates
for the latest bits. In Subversion, random wacky experiments might live in
separate branches of the repository; in Mercurial, you achieve the same
effect with separate repositories -- it's a distributed SCM, after all.

An advantage of publishing wacky experiments in separate repositories
is that no-one has to sign any SCA to contribute bits. Nor is there any
requirement for a code review. Folk can publish their bits and other folk
can use them.  The requirements for "serious" work (your word) would
kick in if the work starts being done in the context of an official 
OpenJDK project.

But, as I said, I agree with your comments about trying to bring the
experiments together, and that is why we are proposing compiler-dev
and perhaps the Compiler Group pages on openjdk.java.net as a central
location where people can announce their work, and where others can go
to find out what experiments are available.

-- Jon







Patrick Wright wrote:
> Hi Jon
>
> I don't have any say in all of this, but I think that bringing
> together the various experiments people are working on for the
> compiler would be a good thing.
>
> I'm wondering if you can clarify the text on the KSL homepage,
> specifically this section, under "code reviews":
> "Request a code review by sending your patch to the compiler-dev
> mailing list. The code must be reviewed by an experienced compiler
> engineer/hacker before being committed to the **trunk**. Currently,
> this mostly means a current or former Sun employee that has worked on
> javac.
>
> When the reviewer approves your changes, you can commit them to the
> **branch**. The reviewer will reply something similar to I approve
> these changes so you know when the reviewer is satisfied with the
> quality of the code. Do not commit anything until you are sure the
> reviewer approves your changes. If in doubt, do not hesitate to ask."
>
> (stars added for emphasis). Is it a mistake that the first paragraph
> refers to trunk and the second to a branch?
>
> What's not clear to me is whether KSL is really a "kitchen sink" for
> ideas on changes to the compiler (or usually, to the language), or
> more specifically a place for compiler experts to propose almost-ready
> changes or bug fixes for the KSL trunk (which I would consider a more
> serious effort).
>
> I'm wondering if there is a way that KSL could include (and encourage)
> wild and wooly (but working) experiments with the language/compiler
> while also preserving an area with a higher standard for inclusion.
> Perhaps that's the difference between branch (experimental) and trunk
> (serious) here.
>
> SwingLabs has the idea of an incubator, which is a space which any
> SCA-signer can commit to, but which doesn't guarantee inclusion into
> SwingLabs. It is a way to encourage people to contribute ideas as they
> develop them.
>
>
> Thanks
> Patrick
>