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.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
>
