Re: Proposal for the transition timetable for the move to GIT

[Richard Biener <richard.guenther@gmail.com>]

On Tue, Sep 17, 2019 at 2:02 PM Richard Earnshaw (lists)
<Richard.Earnshaw@arm.com> wrote:
>
> At the Cauldron this weekend the overwhelming view for the move to GIT
> soon was finally expressed.
>
> But we never discussed when and we didn't really decide which conversion
> we would use from the three that we currently have on the table.
>
> So during the cauldron dinner I discussed with several people a possible
> timetable and route to making the final decision.  This seemed to be
> broadly acceptable to everyone I discussed this with (though obviously)
> that was by no means everyone there.
>
> So here's my proposal, and a few implications that follow from this.
>
> We should switch to GIT at the end of GCC-10 development Stage 3.  Ie
> on, or shortly after the 1st of January 2020.  This gives us time to get
> all the major work that might have been prepared based on SVN committed,
> but also gives us time to get used to using the new repo before we reach
> the GCC 10 branch date.
>
> If we're to meet that date I think that means we need to make a final
> decision as to which conversion about a fortnight before that date (lets
> say Monday 16th December).  The decision should be based on the best
> conversion that we have at that time.  My proposed ranking criteria would be
>
> - Most branches converted (eg, can it handle the SVN
> branches/<vendor>/<branch> layout that we have in addition to the
> engineering branches).
> - tweaked committer history (email ids etc - nice to have)
> - fixes for accidental trunk/branch deletions/restores (preferred)
> - correctness around branch points (nice to have)
>
> The conversion that meets all/most of these at the cut off date will be
> the one chosen.  Additionally, a candidate can only be chosen if it is
> correct at all (converted) branch heads.
>
> The need to make the cut off a couple of weeks before the final
> conversion is to allow time for some trial conversions and to allow us
> time to validate that the commit hooks we want are all in place.
>
> There should be NO CHANGE to the other processes and policies that we
> have, eg patch reviews, ChangeLog policies etc at this time.  Adding
> requirements for this will just slow down the transition by
> over-complicating things.
>
> So after the 16th, I would expect a trial conversion to be done and the
> hooks to be installed on a version that we make available on the web
> site, but which is not the final conversion.  We can still allow commits
> to it for testing purposes, etc and to allow users to check that they
> are integrating properly with the new repo, but any such changes will be
> lost when the final conversion is done at the switch time.
>
> So in summary my proposed timetable would be:
>
> Monday 16th December 2019 - cut off date for picking which git
> conversion to use
>
> Tuesday 31st December 2019 - SVN repo becomes read-only at end of stage 3.
>
> Thursday 2nd January 2020 - (ie read-only + 2 days) new git repo comes
> on line for live commits.

I think that's fine if the repository state from Dec 16th is kept up-to-date
so that effectively two weeks can be used to verify its integrity.  Doing
the update to the Dec 31th state should relatively easy?

If stage3 ends on Dec 31st then stage1 ends Oct 31st to have a two-month
stage3.  That's about two weeks earlier than in the past.

> Doing this over the new year holiday period has both advantages and
> disadvantages.  On the one hand the traffic is light, so the impact to
> most developers will be quite low; on the other, it is a holiday period,
> so getting the right key folk to help might be difficult.  I won't
> object strongly if others feel that slipping a few days (but not weeks)
> would make things significantly easier.
>
> It would be good if we could get agreement on this soon, as there are
> probably some additional logistical things to sort out.  I can think of
> a number of these, but this mail is already long enough for now.

+1

Richard.

> R.