Repository? -- How many lines of development?

[John Coomes]

On Mon, Nov 28, 2016 at 2:07 PM, Joseph D. Darcy <joe.darcy at oracle.com>
wrote:

> Hi David,
>
>
> On 11/28/2016 1:47 PM, David Holmes wrote:
>
>> Sorry Joe this got forgotten ...
>>
>> On 19/11/2016 2:33 AM, joe darcy wrote:
>>
>>> Hello,
>>>
>>> On 11/18/2016 5:50 AM, Aleksey Shipilev wrote:
>>>
>>>> Hi,
>>>>
>>>> It is very exciting to see the JDK 10 mailing list!
>>>>
>>>> When can we expect open forests (or maybe a monorepo that was discussed
>>>> at jdk9-dev some time ago [1]) for JDK 10? :)
>>>>
>>>> Thanks,
>>>> -Aleksey
>>>>
>>>> [1] http://openjdk.java.net/jeps/296
>>>>
>>>
>>> And thus will commence the first thread in jdk10-dev, how many lines of
>>> development where "line is development" means either a forest or a
>>> monorepo.
>>>
>>> For a few reasons including not holding up the start of JDK 10
>>> development for further discussion about and administrative advancement
>>> of JEP 296 and to give more time to work on internal-only details of the
>>> repo consolidation (such as how the various closed repos are handled),
>>> the JDK 10 lines of development won't start out as monorepos. They will
>>> at least initially use the existing multi-repo structure as in JDK 9.
>>> However, we'll return to JEP 296 later in the release.
>>>
>>> Regardless of many repos used for a line of the development, there is a
>>> larger question of how many lines of development to have. For JDK 10 I
>>> propose three lines of development:
>>>
>>> * A master forest, serving the roles master and dev play today in 9.
>>>
>>> With a few exceptions, in JDK 9 master was just time-delayed copy of dev
>>> so we can implement recording the  information about which set of
>>> sources correspond to a promoted build without using a whole other
>>> forest.
>>>
>>
>> I agree with the description, but how does someone get a stable snapshot
>> of master at a given "level"? How will the tagging work?
>>
>
> For the combined dev/master forest, the most recent integration tag will
> have the same stability guarantees we have today so "pull the most recent
> jdk-10+XYZ tag" to get a stable snapshot.
>
> As an aside, for JDK 10 I'd also like to see promoted builds on a more
> frequent schedule than once a week.
>
>
>> I also think the name "master" (due to historical usage) suggests a level
>> of stability that won't actually be present. Maybe it is better to call it
>> "dev"?
>>
>>
> Much of the stability we see in master today is because the forest only
> changes once a week with the dev -> master integration ;-)
>
> In a nutshell, the proposal is to replace tracking the known-good state in
> 9 via integrate dev -> master, tag in master, pull down to dev process
> today with just "tag known good in combined dev/master" in 10.
>
>
Hi Joe,

This would make cloning or pulling the "last known good" state more
difficult.  In jdk9, I can always clone/pull from a fixed location
(http://.../jdk9/jdk9).
With the proposal, I would have to first clone/pull everything, then
examine the tags and sort them (which programatically means decoding
release and build numbers, ugh), find the right tag, then pull/update to
get the working dir in the right state.

Since my clone would have all the changesets, including those beyond the
"last known good" state, it also makes the use of 'tip' and 'default' error
prone.  If I do some archaeology and run "hg update <some_older_rev>", then
when I'm done, I can't go back to "last known good" with a simple "hg
update default".  I have to look at the tags again, sort them, and so on.

I think it's more important that cloning or pulling the "last known good"
state be simple, rather than promoting a build.

Mercurial bookmarks might be a compromise solution - you can have a
bookmark with a fixed name (e.g., "stable", "jdk10-stable",
"last-promoted", whatever) that is updated each time a build is promoted.
With validation from jcheck, it could be made reasonably safe.

-John