This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Proposal for the transition timetable for the move to GIT

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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]