[External] : Re: Switch jdk8u development to Git/Skara

[erik.joelsson at oracle.com]

On 2021-10-12 16:13, Andrew Hughes wrote:
> On 06:22 Fri 01 Oct     , erik.joelsson at oracle.com wrote:
>> I think this plan looks reasonable, but I will need to check internally
>> before I can give a final go ahead. Could you narrow down the potential
>> cut over windows to date ranges?
> Certainly.
>
> 1. The monorepo transition and creation of live read-only git mirrors
> would be after the rampdown of 8u322, which is scheduled for Friday,
> November the 26th, 2021.  So I would expect the transition to begin on
> the week beginning Monday, November the 29th, 2021.  One of the
> reasons we chose this particular period for what is expected to be the
> most involved work is that the December period is usually quiet, as
> many people ramp down themselves for the holiday period. So a delay
> should be less problematic than at other times.
>
> 2. The 8u-dev git repo should go live the week beginning Monday,
> February 28th, 2022, following rampdown on Friday the 25th.
> Technically, this should hopefully just mean making the repository
> writable. The main issue is in adjusting our processes to using
> git and Skara.
>
> 3. The 8u git repo should go live after the 8u332 release is pushed,
> on Tuesday, April the 19th 2022.  As 8u is only used at this point
> for the build promotions I'm making, a delay here doesn't
> directly affect developers; it would just mean a later build promotion.
>
> I've updated the 8u wiki with the 8u322 & 8u332 schedules as well:
>
> https://wiki.openjdk.java.net/display/jdk8u/Main
Thanks, updating my calendar.
>> Yes, the consolidation is the trickiest part with the most amount of
>> unknowns that could potentially delay things. I do believe I have it
>> under control however. You can look at the current prototype here:
>>
>> https://hg.openjdk.java.net/jdk8u/consol-proto/
>>
> Thanks. Are the commits from duke usual? The one for 8u312-b05
> particularly catches my attention, as I'd expect several tags
> from myself, as with b04, instead.
Yes, this is (unfortunately) normal. The original tag commits are 
transplanted over to the mono repo, but they are no longer actual tag 
commits as they refer to .hgtags files that are no longer actual .hgtags 
files. The actual new tags are created at consolidation time and I use 
the user "duke" to create them (just as "duke" is also performing all 
the merges that need to be done). For every tag except the very last 
one, the original tag commits are included in the mono repo, as they are 
part of the changes for the next tag. For the very last tag however, the 
current logic does not include them. At least for the prototype, doing 
so would invalidate (or at least complicate) the ability to 
incrementally continue the consolidation with new changes. In theory, I 
could convert them at the very end as a special case, but I don't think 
it's really worth it. The same thing happened in the JDK 10 consolidation.
> That makes sense. In the worst case, I assume the original forest will
> still be available for reference.
>
> One of the reasons I suggest the rampdown for the consolidation is we
> should be able to just do the process once for 8u, and then 8u-dev can
> just be a duplicate that diverges afterwards.
>
> I presume once the hg monorepos are there, we can have read-only git
> mirrors which will eventually become the live repos?

Yes, all correct. The old forests will be around as read-only references 
for a very long time. There are a lot of deep links in JBS for example 
pointing into repositories.

Doing the consolidation at a point where 8u and 8u-dev are equivalent 
definitely helps.

Git mirrors will be up very soon after the consolidation.

>> Yes, the file layout is identical. We have no plans to rearrange things
>> for 8u. You may want to do some cleanup afterwards, like removing the
>> hgforest.sh/get_source.sh scripts that are no longer useful and remove
>> the no longer used .hgtags files from old nested repo directories.
> That's good to hear. Yes, having just been looking through the 11.0.13
> changes, I see quite a few alterations to adapt to using git in
> build instructions, testing, etc. I expect we'll want to do similar
> over the 8u322 & 8u332 lifecycles.
There is also a bit of build logic in there to record the state of the 
HG forest into the release file that needed to be adapted to git.
>>> 4. Could Skara be adapted to enforce the jdk8u-fix-yes /
>>> jdk8u-critical-yes JIRA labels so the change can't be pushed until it
>>> has been approved?
>> This sounds like a rather simple feature in comparison. Please file an
>> enhancement request for SKARA.
>>
> Oh, excellent, will do.
>
I believe Christoph beat you to it. See SKARA-1199.

/Erik