[ecf-dev] Git migration and ECF 3.4 timing: PLEASE READ

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

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