Just found [1], that's the contributor side only but it pleased me, just
replacing master by develop could be a good base for the wiki ?
-Fred
[1]
https://www.openshift.com/wiki/github-workflow-for-submitting-pull-requests
-----Message d'origine-----
From: Erik de Bruin
Sent: Friday, March 22, 2013 1:27 PM
To: dev@flex.apache.org
Subject: Re: [Git/Wiki] please review the proposed workflow and comment
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
