[
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