Alexey, You are right and big thanks for the diagram on the wiki!
In bounds of IGNITE-1217 <https://issues.apache.org/jira/browse/IGNITE-1217> I've created a script for commiters (see patch). You need to point to the script a contributor_github_user_name and a branch_name_with_contribution. The script just fetchs a remote repository (by contributor_github_user_name) and cherry-picks last commit from this branch to local master - it stores commit author information. So, the commiter can push master at apache git. In this case we have one requirement: a pull-request should have only one commit (as with patches). I've mention next model of development at fork (see steps below). But now, I see it has too many steps. I will think about more simple way. 1. Preparation (need to configure once): git remote add apache https://git-wip-us.apache.org/repos/asf/incubator-ignite git remote my_fork https://github.com/<github_uname>/incubator-ignite.git 2. Forking on jira ignite-xxxx # Update local master from apache repo git checkout master git pull apache master # Create new development branch for the ticket. git checkout -b ignite-xxxx-dev # Some development here with many commits at ignite-xxxx-dev. git commit -a -m 'ignite-xxxx: Intermediate commit 1' ... git commit -a -m 'ignite-xxxx: Intermediate commit 100' # Push at fork git push my_fork ignite-xxxx-dev Now a pull-request can be created. TC will be triggered. To fix some something and rerun TC, you need just fix it at ignite-xxxx-dev and push to fork again, TC will be triggered again for new commit. When TC is green, it needs to create 'final' pull-request branch with one commit. For it: # Update local master from apache repo git checkout master git pull apache master # Create a final pull-request branch for the ticket. git checkout -b ignite-xxxx # Squash all changes at one commit. git merge --squash ignite-xxxx-dev git commit -a -m 'ignite-xxxx: Implemented' Then need to push it to fork and open new pull-request. -- Artem -- On Fri, Aug 14, 2015 at 5:30 AM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > I forgot that the mailing list takes out all formatting, the diagram meant > to be in a monospaced font :) > > I added it to Ignite wiki: > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute > > 2015-08-13 19:22 GMT-07:00 Alexey Goncharuk <alexey.goncha...@gmail.com>: > > > While the process of a pull-request creation and CI run is clear for, the > > whole cycle from start to end is still fuzzy. Let me summarize my > > understanding and correct me if I got something wrong. > > > > For any committer/contributor John Doe we will have the following > > structure: > > > > +------------+ +---------------+ > > +-----------------+ > > | | replica | | fork | > > | > > | Apache Git | ==========> | GitHub Mirror | ---------> | John Doe's > Fork > > | > > | | | | | > > | > > +------------+ +---------------+ > > +-----------------+ > > ^ ^ > > | | > > | | > > | > > +-----------------+ > > | *Apache Git remote handle for committers* | > > | > > +------------------------------------------------| Local clone > > | > > | > > | > > > > +-----------------+ > > Development is going in the JD's fork and at some point he thinks that > the > > feature is ready to be tested by CI. > > > > He creates a pull request. Usually it takes more than one iteration to > > have a successful CI run, but each pull request sends an e-mail to the > dev > > list. I think we should have some mechanism allowing to differentiate > > "work" pull requests and final pull requests that passed CI and should be > > reviewed by a committer. We also need to create (maybe) a maven profile > > with a set of quick tests that cover as much functionality as possible, > so > > that a developer could run it locally before submitting a request to the > CI. > > > > Let's say now the pull request is approved. If the pull request was > > submitted by a contributor, a committer should pull it to it's local > clone. > > Then commit is pushed to the apache git repository. I glanced through the > > Apache Spark development process document [1] and it seems that we should > > have a similar script that will properly process commits (squash or > > whatever we need) before the push. > > > > Assuming my understanding is correct and the minor things I mentioned > > above are addressed, I like the new process :) > > > > [1] > > https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark > > > > > > 2015-08-13 18:13 GMT-07:00 Konstantin Boudnik <c...@apache.org>: > > > >> On Thu, Aug 13, 2015 at 05:54PM, Dmitriy Setrakyan wrote: > >> > On Thu, Aug 13, 2015 at 5:51 PM, Konstantin Boudnik <c...@apache.org> > >> wrote: > >> > > >> > > On Thu, Aug 13, 2015 at 05:40PM, Alexey Goncharuk wrote: > >> > > > Maybe I miss a good piece of information about how Git works, but > I > >> > > always > >> > > > thought that if a pull request is accepted, it will be merged to > the > >> > > GitHub > >> > > > mirror of Apache Ignite. How will this change get to the original > >> Apache > >> > > > git repository? > >> > > > >> > > It won't. github repo is a mirror of Apache git mirror. In order to > >> have > >> > > the > >> > > changes from github PR to be in visible in the github a committer > >> needs to > >> > > commit it into our Apache repo. > >> > > > >> > > >> > Cos, will the original contributor's name be preserved or should the > >> Ignite > >> > committer add "-author" parameter when committing? > >> > >> It depends on how the patch file was made. If 'git format-patch' was > used > >> then > >> the name will be preserved. Otherwise, it won't. Sorry, I don't know > much > >> about github and I really am not using it. > >> > >> Cos > >> > >> > > > Can somebody explain to me the merge procedure? > >> > > > > >> > > > 2015-08-12 3:15 GMT-07:00 Artem Shutak <ashu...@gridgain.com>: > >> > > > > >> > > > > Inline. > >> > > > > > >> > > > > On Wed, Aug 12, 2015 at 10:19 AM, Dmitriy Setrakyan < > >> > > dsetrak...@apache.org > >> > > > > > > >> > > > > wrote: > >> > > > > > >> > > > > > On Tue, Aug 11, 2015 at 6:28 AM, Artem Shutak < > >> ashu...@gridgain.com> > >> > > > > > wrote: > >> > > > > > > >> > > > > > > And one more question. Is it mandatory to have possibility > >> works > >> > > via > >> > > > > > > patches if we will have pull-request way for contributions? > >> > > > > > > > >> > > > > > > I'd like to have only one approach. > >> > > > > > > > >> > > > > > > >> > > > > > Artem, if possible I would allow 2 approaches and document > the 2 > >> > > > > approaches > >> > > > > > on Wiki. > >> > > > > > > >> > > > > > >> > > > > At least it increases support efforts. And if all will use only > >> one, > >> > > then > >> > > > > there is a big chance that second will not work properly. > >> > > > > > >> > > > > And, to complete patch-way: > >> > > > > - need to split simple "master" builds and "patch" builds on TC > - > >> I > >> > > can do > >> > > > > it by yourself. > >> > > > > - need to implement git-format-patch.bat for Windows users. It's > >> not > >> > > > > mandatory, all can be done manually by contributors, but it > would > >> be > >> > > nice. > >> > > > > This script can make any Windows user (I'm not :) ). > >> > > > > > >> > > > > > >> > > > > > > >> > > > > > One question, does a pull request automatically generate a > Jira > >> > > comment > >> > > > > > (see Spark, Camel)? > >> > > > > > > >> > > > > > >> > > > > I will look at mentioned projects. From my view, by default, > >> GitHub > >> > > know > >> > > > > nothing about our Jira. So, there's no way to GitHub can add any > >> > > comments > >> > > > > to unknown Jira. > >> > > > > DVCS plugin - it's a standard way to acquaint Jira and GitHub > and > >> it > >> > > will > >> > > > > work pretty nice. > >> > > > > > >> > > > > --Artem-- > >> > > > > > >> > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > -- Artem -- > >> > > > > > > > >> > > > > > > On Tue, Aug 11, 2015 at 4:15 PM, Artem Shutak < > >> > > ashu...@gridgain.com> > >> > > > > > > wrote: > >> > > > > > > > >> > > > > > > > Igniters, > >> > > > > > > > > >> > > > > > > > I'm working on > >> https://issues.apache.org/jira/browse/IGNITE-1217 > >> > > . > >> > > > > > > > > >> > > > > > > > Currently, everyone can fork Mirror of Apache Ignite on > >> GitHub ( > >> > > > > > > > https://github.com/apache/incubator-ignite), works with > >> own fork > >> > > > > > (create > >> > > > > > > > branches, commit, pull changes at fork) and then creates a > >> > > > > pull-request > >> > > > > > > to > >> > > > > > > > Mirror of Apache Ignite on GitHub (all changes should be > >> done in > >> > > one > >> > > > > > > commit > >> > > > > > > > as in patch-way approach). Then test TC builds will > >> triggered > >> > > > > > > > automatically. Results can be found by branch filtering by > >> > > pattern > >> > > > > > > > <pull-request-number>/merge. "Merge" suffix here means > >> > > pull-request > >> > > > > > > merged > >> > > > > > > > with master branch (if pull-request at master branch). > >> > > > > > > > > >> > > > > > > > Notes: > >> > > > > > > > > >> > > > > > > > 1. I tried to use TC plugin for github to see TC result at > >> > > > > > pull-request. > >> > > > > > > > But the plugin works in unexpected way and add comments > not > >> only > >> > > to > >> > > > > > > > pull-requests. Example: > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > >> > https://github.com/apache/incubator-ignite/commit/ae11e9b5aa9af4d0d58e2a16dd3a3331969961df#commitcomment-12635375 > >> > > > > > > > . > >> > > > > > > > Maybe someone had this problem before? > >> > > > > > > > > >> > > > > > > > 2. I'm looking for a simple way to add information about > new > >> > > > > > pull-request > >> > > > > > > > to associated jira. > >> > > > > > > > The better way to use existing Jira plugin for it - DVCS > >> plugin ( > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > >> > https://confluence.atlassian.com/display/BITBUCKET/Linking+Bitbucket+and+GitHub+accounts+to+JIRA > >> > > > > > > ). > >> > > > > > > > But I need both: Jira administration rights to configure > the > >> > > plugin > >> > > > > and > >> > > > > > > > GitHub password for "apache" user. Or I missed something > >> and we > >> > > can't > >> > > > > > use > >> > > > > > > > this plugin at Apache infrastructure? > >> > > > > > > > Maybe someone can suggest another solution? > >> > > > > > > > > >> > > > > > > > Thanks, > >> > > > > > > > Artem. > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > >> > > > > >
