On Apr 23, 2015, at 11:42 AM, Martin Becker <martin.bec...@ecomify.de> wrote:
> Maybe it’s necessary to think about which processes and workflows maybe the > ones that are expected by the current and especially future > audience/clients/contributors from a state of the art, living and ongoing > open source project. Exactly. I think that we are having a thorough discussion on the pros and cons of git vs svn, which is good, but we are not focusing enough, in my opinion, on the existing workflows and if/how they should change with the adoption of a new tool. For example, I guess that some of us are implying that with the new tool (git) will also come a new workflow and specifically the "Fork workflow" that is the one made easy by GitHub and similar: there is one official repo, developer fork it and then submit pull request that the committers of the official (upstream) repo can merge. However this is not the only one and it is important that we clarify this aspect: do all proponent of git also agree on one workflow? Another important aspect of the story is that, for policy/license reasons, while it is completely fine for an ASF project to use git as the primary SCM, there are things that they still cannot do (e.g. I think that merging code from pull requests is not allowed); the current git workflow that is recommended at the ASF is the following: non committers: https://git-wip-us.apache.org/docs/workflow.html committers: https://git-wip-us.apache.org/docs/committer-practices.html Jacopo
