diff options
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 32 |
1 files changed, 3 insertions, 29 deletions
diff --git a/README.md b/README.md index 842b139ecd3..046a374ba64 100644 --- a/README.md +++ b/README.md @@ -76,28 +76,10 @@ The project assumes one of 3 _roles_ an individual may assume when interacting w ### Occasional Contributor -This role defines a user who browses through the source code of the project and occasionally submits patches. Patches may be submitted in one of two ways: - -* Attach a patch file to the Bugzila issue (ATCD Bug tracking system may be found [here](http://bugzilla.dre.vanderbilt.edu/)). -* Creating a pull request on GitHub - -The approach a contributor chooses to use depends entirely his/her personal preference, but usually is tied to how the -contributor accesses ACE/TAO source code. If the contributor directly clones the upstream repository, -they should submit patch files. If the contributor instead uses their personal GitHub account to fork the upstream repository, then they are should issue a pull request. - -![Tip][tip] A GitHub pull request is the preferred method to submit a patch! - - -#### Attach a patch file to the Bugzilla issue - - - -In this workflow, the contributor directly clones the upstream repository, makes changes to his local clone, adequately tests and commits his work with proper comments (more on commit comments later), and generates a patch. The patch should then be attached to the Bugzilla issue. - -More information on generating patches suitable for attaching to a Bugzilla can be found in [Chapter 5, Section 2](http://progit.org/book/ch5-2.html) of Pro Git, under the section titled *Public Large Project*. - -![Warning][warn] Rather than emailing the patches to a developer mail list, please attach your patch to the Bugzilla issue. +This role defines a user who browses through the source code of the project and occasionally submits patches. +An occasional contributor will only submit patches via a pull requests. The pull request will be submitted via GitHub. +Occasional contributors should *always* fork the upstream project on GitHub and work off a clone of this fork #### Creating a pull request on GitHub @@ -227,14 +209,6 @@ Project Admins have a very limited role. Only Project Admins are allowed to push This approach ensures ACE/TAO maintains quality on the main code source tree, and allows for important code reviews to take place again ensuring quality. Further, it ensures clean and easily traceable code history and makes sure that more than one person knows about the changes being performed. -#### Merging in patches - - - -Patches submitted via Bugzilla are audited and promoted to the upstream repository as detailed above. A Project Admin would typically create a working branch to which the patch is applied and tested. The patch can be further modified, cleaned up, and commit messages made clearer if necessary. The branch should then be merged to the master or one of the maintenance branches before being pushed. - -More information on applying patches can be found in [Chapter 5, Section 3](http://progit.org/book/ch5-3.html) of Pro Git, under *Applying Patches From Email.* - #### Handling pull requests  |