Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ecf-dev] Git migration and ECF 3.4 timing: PLEASE READ

Hi Folks,

On today's weekly conference call [1], we discussed the timing of two related things:

1) Migration from dev.eclipse.org CVS repo to git repository
2) The release of ECF 3.4

Before discussing the options here, I would like to make a couple of things clear about '1'. First, once we move to git (from CVS), this will mean that

a) Committer (write) access will *only* be allowed via git...that is, no one will be able to commit via CVS again. b) Because of 'a', and the fact that it's probably going to be impossible to sync the anonymous CVS repo to git, *even read-only access to the latest of ECF will have to be through the git repository*. This is because as soon as we move the write access to git, the read-only access to the anonymous CVS repo will be out of date. c) Because of both 'a' and 'b' there is a fair amount of work to occur prior to moving to git...e.g. i) all committers have to become familiar with the existing git clients (both eGit and others)...and the differences in workflow...commit+push....so that they can continue fixing bugs, adding features, etc.; ii) all the references in the wiki pages to the CVS repo have to be updated to retrieve from git repo; iii) all CVS module renaming/reorganization has to take place before the move; iv) The ECF build system has to be changed over to use git-based repository. We will need contributions from nearly all committers and contributors to help with the releng tasks here, as well as the normal release review process, etc. This means *you* :). d) So the bottom line, I believe, is that once we do the changeover that we should effectively plan on *shutting off CVS access* in favor of the git repo *only*. The reason we think this will be easier is because even if we try to sync the CVS repo with the git repo (i.e. 'b'), it will be a lot of work to do so frequently enough to make it worthwhile...as Eclipse IT won't do it for us, we won't be able to automate it, and we don't currently have the resource for us to do it manually with very high frequency.

So, given these things, and the fact that Markus K has to take some time off in August, we decided this morning to defer the CVS->git changeover of the ECF repository until *after* Markus returns from his holiday...and he returns on Sept 8. Once Markus returns, I think we should leave at least 2 weeks before shutting off/archiving the CVS repository. Now, another thing to consider is that we would like to have an ECF 3.4 release around mid/late September. Although this isn't required, I think it would be a good idea, as we've got a number of new things that could go into such a release (work on remote services, dnssd, possibly wave provider, other work going on right now, etc). If we want to do this (have a release 3.4 in late Sept/early Oct), then I think we should have at least a 2 week interval between the two (i.e. the git changeover and the release). So I think there are two options here in terms of ordering (if we agree that we should do both the git changeover and the ECF 3.4 release during the next few months):

1) Git changeover first, followed by ECF 3.4 release.  Timeline:
Sept 8-> Markus K returns from vacation ->Sept 22 -> git changeover->Oct 6 -> ECF 3.4 release
2) ECF release first, followed by git changeover.  Timeline:
Sept 8 -> Markus K returns from vacation -> Sept 22 -> ECF 3.4 release -> Oct 6 -> git changeover complete

Are there any comments from committers/contributors and/or other community members about either of these two alternatives? Preferences? Please respond to this list. If people don't speak up, the assumption will be that any decision made along these lines (i.e. timing/ordering of git changeover and ECF 3.4 release) will be OK with you.

Thanks,

Scott









Back to the top