Am 02.09.2014 um 18:41 schrieb Mark Thomas:
I've been looking at this again (anything to get a break from writing
parsers for cookies) and chatting with some of the infra folks that look
after the ASF's git repos.
There are a couple of things we need to do:
a) decide how we want to organise development in git
b) decide if we want to move to git
Now the decision we make for a) might influence some folks to make a
different decision for b). On the other hand, there is no point debating
a) if we are never going to move.
So, how do folks want to approach this?
A: Vote to move to git and then figure out how best to use it? or
B: Agree our git workflows and then have a vote on moving to git with
those workflows?
I'm leaning towards A myself.
It looks like the discussion in january and the answers on this thread
show a majority for a move to git (not necessarily a consensus). I'd
prefer if we knew more about the details before finally voting on it, so
"B", and I expect the time and work needed for that will not be wasted.
I agree with others about items for a). Things that come into my mind:
- one repos or multiple: Actually I dont't care about that question per
se, but more about the implications that will have (which I'm not sure
about). For instance, does it matter in git, that we would only have one
master (trunk), and the heads of the versions only as branches?
- backport workflow
I find "trunk first, then version branches" slightly better, but it
might depend on details unknown to me. Concerning "cherry-pick" this
seems to break the link between the original (e.g. master) commit and
the commit on the branch. Not a good thing IMHO.
- use of temporary feature or backport branches: delete after merge?
- handling pull requests (tracking patch authors)
- move tomcat-connectors as well, same repos? No preference here.
- move old branches to simplify code archeology? I'd prefer so.
- sources for the web site remain in svn?
- is there (in principle) a way back from git to svn, or is this a one
way street? No details needed, but if the project finds out the move was
a bad thing, are we confident, that we can get back?
- Konstantin provided some reasons against git during the last three
discussions. Some of the might be mitigated by now (e.g. svn externals
vs. git submodules? Version diffs), some of them might not (Buildbot and
Jenkins integration, missing EU mirror).
I guess experienced git users (like Martin Grigorov) could answer most
questions easily, but I don't have the experience with git allowing me
to understand implications of decisions.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
