JEPs proposed to target JDK 10 (2017/11/2) (original) (raw)
Volker Simonis volker.simonis at gmail.com
Wed Nov 8 17:07:18 UTC 2017
- Previous message: JEPs proposed to target JDK 10 (2017/11/2)
- Next message: JEPs proposed to target JDK 10 (2017/11/2)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Roman, Brian,
@Roman: I just want to re-iterate that my post was in no way intended as a criticism of your work. I think you did everything right (at least as good as if can be done in the current project setup :)
@Brian: You wrote: "For nontrivial projects, you are expected to work iteratively, progressively refining the design, interface, implementation, and test suite together, outside of the main code line, until it is ready, and then — and only then — do you start the process of proposing to target." That's actually exactly how I understand the process as well. However, looking at the reality, how many of the JEPs (except Jigsaw and some ports) have been developed in their own repositories before they have been integrated into the main line?
We have a serious process/infrastructure problem because creating a new clone is a much to heavyweight operation and branches are not yet a generally accepted "working model" in the OpenJDK. Let alone the fact of testing such a clone/branch (i.e. JPRT/Mach5 for the insiders :) I'm also not sure if other tools like JBS work well with branches for example. Finally, it is currently much easier to attract the attention of a potential Oracle reviewer/sponsor when you subdivide your JEP into small sub features. I wouldn't call that cheating - it's just the only viable way to get your work done if you're an external contributor.
So, to sum it up, I think we have a well defined and sound process but we really need the infrastructure and tools to execute it!
Regards, Volker
On Tue, Nov 7, 2017 at 5:58 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
If that’s your conclusion, I think you have a serious misunderstanding of how the JEP process works. Yes ,there are a sequence of milestones, but you’ll notice none of them are “design complete”, “spec complete”, “implementation complete”, “testing complete” as a waterfall process would mandate. In fact, all of the JEP milestones are either related to inception as a project (is this something we want to consider having in the JDK), or tracking steps that all happen after all the work is done. For nontrivial projects, you are expected to work iteratively, progressively refining the design, interface, implementation, and test suite together, outside of the main code line, until it is ready, and then — and only then — do you start the process of proposing to target. That’s not waterfall; that’s “get it right before you think about committing any of it.”
While it would surely be possible to cheat and pretend that a project is merely N sub features each small enough to be called a bug/rfe, that would definitely be working outside the spirit of how we work. Surely that’s not what you were suggesting?
On Nov 6, 2017, at 11:35 AM, Roman Kennke <roman at kennke.org> wrote: The biggest issue is that the JEP is a sort of waterfall process
- Previous message: JEPs proposed to target JDK 10 (2017/11/2)
- Next message: JEPs proposed to target JDK 10 (2017/11/2)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]