The official repositories are on ASF Gitbox, only those are committers writable.
We have also Github mirrors. Committers can push to them they are synced to Gitbox, even using Subversion!
There are actually two mirrors, before and after release16.11.
Since release branch 16.11, we disentangled the plugin components (previously under the specialpurpose folder) into a separate repository called ofbiz-plugins
https://gitbox.apache.org/repos/asf/ofbiz-framework.git https://gitbox.apache.org/repos/asf/ofbiz-plugins.git https://gitbox.apache.org/repos/asf/ofbiz-site.git https://gitbox.apache.org/repos/asf/ofbiz-tools.git
Synced with Gitbox, can be forked, and PRs can be made
https://github.com/apache/ofbiz/
https://github.com/apache/ofbiz-framework
https://github.com/apache/ofbiz-plugins
https://github.com/apache/ofbiz-site
https://github.com/apache/ofbiz-tools
Note that you can use Subversion through those repository to finally commit to Gitbox. You can also checkout. A Github feature[1] allows that. You can do it by checking out from Github. For instance, simply try svn co https://github.com/apache/ofbiz-plugins/trunk/ecommerce If you then Svn commit, the Github repo will be the ending container and will sync to ASF Gitbox I have used the same in build.Gradle: I don't say it's a definitive solution. At least it allows to think more about the best solution... [1] https://help.github.com/en/github/importing-your-projects-to-github/working-with-subversion-on-github |
As nicely explained by Taher Alkhateeb in the mail thread, here details on workflow.
The contribution workflow for small features/bug fixes and large features.
Small features follow the exact same workflow that currently exists in SVN.
You do your work, diff it, and attach the patch to a JIRA and request a commit from one of the committers. As explained in Contributing via Git and Github - WIP
For large features usually multiple people need to collaborate on a separate branch. Here is where git shines and the distributed model kicks in:
1. A JIRA is created for a large feature.
2. The team (not necessarily having a committer) creates a remote repository which itself may have many branches with the master branch having all the work agreed upon and merged (actually, rebased)
3. The collaboration for this branch happens in the JIRA including discussions, comments, and even links to the commits, etc ...
4. A request is made to the project, to make a pull request from the repository after reaching a certain milestone with consensus from the community of course.
5. Here, for extra safety, the branch model may have a trunk and a develop branches. Everything is pulled to the develop branch and trickles down to the master branch after thorough and proper testing.
The above workflow can also adhere to the now famous Vincent Driessen git branching model found here -> http://nvie.com/posts/a-successful-git-branching-model/
The git revert command can use be revert a commit, more details can be found here.
git revert <commit-revision> |
In SVN we have script to merge and commit the fixes from trunk to release branches.
We will have a branch for the release management, currently we have three branches in https://github.com/apache/ofbiz-framework/
trunk, release17.12 and release18.12
In OFBiz, we cut a release and thoroughly test it and then finally make it available to the public.
To create a new release, a branch will be cut from the trunk.
Ideally, the branch will be cut from the trunk branch. So make sure you are on the trunk branch.
Here is the example, we have cut the release19.06.
git checkout -b release19.06 git push origin release19.06 |
Once the branch is ready to publish, we will cut a tag to the release branch. As per our example above we can cut a tag release19.06.01
Here is the example, we have cut a tag for release19.06 branch.
Make sure you are on release19.06 branch
git tag release19.06.01 git push origin release19.06.01 |
After the successful migration to Git, we should update this information to various resources like website, wiki documents, and references.
As mentioned by Deepak Dixit, we have hooks on commits, like the word limit in a line for Java file.