Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "BPEL/Contributors Area"

(New page: == Using Git == Now that the BPEL Designer code is hosted in a GIT repository, there has been some [http://dev.eclipse.org/mhonarc/lists/bpel-dev/msg01359.html discussion lately on the bp...)
 
(Using Git)
Line 3: Line 3:
 
Now that the BPEL Designer code is hosted in a GIT repository, there has been some [http://dev.eclipse.org/mhonarc/lists/bpel-dev/msg01359.html discussion lately on the bpel-dev mailing list] about contributing bug fixes and enhancements to the project and the whole GIT process in general. I must admit I'm a GIT newbie myself and while there is a bit of a learning curve and "attitude readjustment", the effort is well worth the benefits of using GIT (so I am told ;^) )  
 
Now that the BPEL Designer code is hosted in a GIT repository, there has been some [http://dev.eclipse.org/mhonarc/lists/bpel-dev/msg01359.html discussion lately on the bpel-dev mailing list] about contributing bug fixes and enhancements to the project and the whole GIT process in general. I must admit I'm a GIT newbie myself and while there is a bit of a learning curve and "attitude readjustment", the effort is well worth the benefits of using GIT (so I am told ;^) )  
  
To clear up any confusion about how to contribute to the project, here is what you should do:<br>
+
To clear up any confusion about how to contribute to the project, here is what you should do:
  
  
'''For committers '''
+
=== For committers ===
  
 
*Create a clone of the repo, locally fork the master branch.  
 
*Create a clone of the repo, locally fork the master branch.  
Line 18: Line 18:
 
*Create a local clone of the git repo, locally fork the master branch  
 
*Create a local clone of the git repo, locally fork the master branch  
 
*For bug fixes &amp; features, either:  
 
*For bug fixes &amp; features, either:  
**make changes on your local branch and send a pull request to the bpel-dev mailing list.
+
**make changes on your local branch and send a pull request to the bpel-dev mailing list, or
**publish a branch with the bugfix on a remote repo (such as GitHub) and notify the bpel-dev mailing list of the change.<br>
+
**publish a branch with the bugfix on a remote repo (such as GitHub) and notify the bpel-dev mailing list of the change.
  
A committer will then be assigned to merge your changes back into the master branch at git.eclipse.org<br>
+
A committer will then be assigned to merge your changes back into the master branch at git.eclipse.org
  
 
As always, please make sure that every change (bug fix or feature) is associated with a [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=BPEL bugzilla report], and that your commit comments include a reference to that bugzilla ID.
 
As always, please make sure that every change (bug fix or feature) is associated with a [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=BPEL bugzilla report], and that your commit comments include a reference to that bugzilla ID.

Revision as of 04:01, 19 September 2011

Using Git

Now that the BPEL Designer code is hosted in a GIT repository, there has been some discussion lately on the bpel-dev mailing list about contributing bug fixes and enhancements to the project and the whole GIT process in general. I must admit I'm a GIT newbie myself and while there is a bit of a learning curve and "attitude readjustment", the effort is well worth the benefits of using GIT (so I am told ;^) )

To clear up any confusion about how to contribute to the project, here is what you should do:


For committers

  • Create a clone of the repo, locally fork the master branch.
  • For bug fixes, push your changes directly to the master branch.
  • For new features, create branches on git.eclipse.org, push changes to that branch, and merge the branch back into master when you feel the new feature is ready.

Note that before a new feature is added to the product, the author(s) should inform the community through the bpel-dev mailing list and/or through the BPEL Forum.

For other contributors (non committers)

  • Create a local clone of the git repo, locally fork the master branch
  • For bug fixes & features, either:
    • make changes on your local branch and send a pull request to the bpel-dev mailing list, or
    • publish a branch with the bugfix on a remote repo (such as GitHub) and notify the bpel-dev mailing list of the change.

A committer will then be assigned to merge your changes back into the master branch at git.eclipse.org

As always, please make sure that every change (bug fix or feature) is associated with a bugzilla report, and that your commit comments include a reference to that bugzilla ID.

Back to the top