It's easy to create a .patch file using git and attach that to a JIRA ticket, isn't it? Why not "declare" that the as the default way to contribute code for non-committers, and revisit this if/when Github is in sync again?
EdB On Fri, Mar 22, 2013 at 1:19 PM, Cyrill Zadra <cyrill.za...@gmail.com> wrote: > Apache cordova has already a nice step by step manual for pull request > on github -> http://wiki.apache.org/cordova/CommitterWorkflow. > > It's not just a click on the accept pull request on github. :( > > Cyrill > > On Fri, Mar 22, 2013 at 10:11 PM, Frédéric THOMAS > <webdoubl...@hotmail.com> wrote: >> I don't know very well the GitHub workflow as even though I worked on public >> and privates ones but: >> >> >>> A non-committer forks the GitHub repo >> >> >> Can't he clone directly the GitHub Repo ? >> >> >>> which branch(es) will non-committers have to target? >> >> >> I would say, its own branch, I mean a branch with the name of the relative >> issues in the JIRA >> >> Thanks, >> -Fred >> >> -----Message d'origine----- From: RIAstar >> Sent: Friday, March 22, 2013 1:02 PM >> >> To: dev@flex.apache.org >> Subject: Re: [Git/Wiki] please review the proposed workflow and comment >> >>> How would that work, if you don't mind explaining? >> >> On the non-comitter's side: >> - A non-committer forks the GitHub repo >> - He now has a complete copy of this repo in his own account >> - He clones his own fork to work on it locally >> - He works locally, makes some commits, pushes to his fork, makes some >> more commits, pushes again, ... until he thinks his feature/bug fix/... >> is ready >> - On GitHub, he hits the "pull request" button >> - He selects the commits that he wants to be packaged in this pull >> request (if not all) >> - He chooses a source branch in his fork and a target branch in the >> original repo and sends the request >> >> On the committer's side: >> - A pull request appears in the list of pull requests (mails are also >> sent to notify interested people) >> - A committer reviews the commits (GitHub will list all the diffs) and >> - a/ sends a message back to the developer with instructions to >> tweak his changes in one way or the other >> - the non-committer fixes what was requested and submits his >> pull request again >> - b/ accepts the pull request and merges it into the target branch; >> this can happen in two ways >> 1/ it's a fast-forward merge: the committer just hits the >> button and the new code will be automatically merged >> 2/ it's not: the committer resolves conflicts and merges manually >> >> Regarding the workflow with big projects like Apache Flex: >> I don't think the pull request concept is mentioned in the nvie article. >> So I guess there's going to be questions like: >> - which branch(es) will non-committers have to target? >> - will their code be merged into 'develop' directly or is a different >> workflow required? >> - maybe bugfixes go directly into 'develop', but new components go into >> a feature branch? >> -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
