On 17/09/2019 13:24, Richard Biener wrote:
On Tue, Sep 17, 2019 at 2:02 PM Richard Earnshaw (lists)
<richard.earns...@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?
I was expecting that we would allow some trial commits to the initial
conversion in order to test that the hooks were working correctly. At
the end of the trial that conversion would be discarded entirely and
replaced by the final conversion.
Of course, depending on which conversion we chose we could simply clone
it and then back out any test commits if that was easier than redoing
the final conversion.
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.
I've created a page on the wiki to track this and any other work that
needs doing to achieve the transition.
https://gcc.gnu.org/wiki/GitConversion
R.
