You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Jonathan Ellis <jb...@gmail.com> on 2016/08/26 15:33:18 UTC
Github pull requests
Hi all,
Historically we've insisted that people go through the process of creating
a Jira issue and attaching a patch or linking a branch to demonstrate
intent-to-contribute and to make sure we have a unified record of changes
in Jira.
But I understand that other Apache projects are now recognizing a github
pull request as intent-to-contribute [1] and some are even making github
the official repo, with an Apache mirror, rather than the other way
around. (Maybe this is required to accept pull requests, I am not sure.)
Should we revisit our policy here?
[1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced
Re: Github pull requests
Posted by Russell Spitzer <ru...@gmail.com>.
This is one of my favorite aspects of how contributions to Spark work. This
also makes it easier to have automated testing on new branches
automatically occurring.
-Russ
On Fri, Aug 26, 2016 at 8:45 AM Ben Coverston <be...@datastax.com>
wrote:
> I think it would certainly make contributing to Cassandra more
> straightforward.
>
> I'm not a committer, so I don't regularly create patches, and every time I
> do I have to search/verify that I'm doing it right.
>
> But pull requests? I make pull requests every day, and GitHub makes that
> process work the same everywhere.
>
> On Fri, Aug 26, 2016 at 9:33 AM, Jonathan Ellis <jb...@gmail.com> wrote:
>
> > Hi all,
> >
> > Historically we've insisted that people go through the process of
> creating
> > a Jira issue and attaching a patch or linking a branch to demonstrate
> > intent-to-contribute and to make sure we have a unified record of changes
> > in Jira.
> >
> > But I understand that other Apache projects are now recognizing a github
> > pull request as intent-to-contribute [1] and some are even making github
> > the official repo, with an Apache mirror, rather than the other way
> > around. (Maybe this is required to accept pull requests, I am not sure.)
> >
> > Should we revisit our policy here?
> >
> > [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
> >
>
>
>
> --
> Ben Coverston
> DataStax -- The Apache Cassandra Company
>
Re: Github pull requests
Posted by Aleksey Yeschenko <al...@apache.org>.
Also, Github’s ability to modify files ‘in-place’ and create pull requests from those changes is
extremely important for our Docs progress. Now that we have proper in-tree documentation,
this would lower the barrier for Docs writers tremendously.
--
AY
On 26 August 2016 at 17:15:54, Jake Luciani (jakers@gmail.com) wrote:
Jake could you show an example issue and how the pipeline works?
On Fri, Aug 26, 2016 at 12:03 PM, Jake Farrell <jf...@apache.org> wrote:
> We just switched Apache Thrift over to using Github for all our inbound
> contributions, have not made Github canonical yet. We wanted to have one
> unified way to accept patches and also make it easier for automated CI to
> validate the patch prior to review. Much easier now that we have a set
> pipeline
>
> -Jake
>
> On Fri, Aug 26, 2016 at 11:44 AM, Ben Coverston <
> ben.coverston@datastax.com>
> wrote:
>
> > I think it would certainly make contributing to Cassandra more
> > straightforward.
> >
> > I'm not a committer, so I don't regularly create patches, and every time
> I
> > do I have to search/verify that I'm doing it right.
> >
> > But pull requests? I make pull requests every day, and GitHub makes that
> > process work the same everywhere.
> >
> > On Fri, Aug 26, 2016 at 9:33 AM, Jonathan Ellis <jb...@gmail.com>
> wrote:
> >
> > > Hi all,
> > >
> > > Historically we've insisted that people go through the process of
> > creating
> > > a Jira issue and attaching a patch or linking a branch to demonstrate
> > > intent-to-contribute and to make sure we have a unified record of
> changes
> > > in Jira.
> > >
> > > But I understand that other Apache projects are now recognizing a
> github
> > > pull request as intent-to-contribute [1] and some are even making
> github
> > > the official repo, with an Apache mirror, rather than the other way
> > > around. (Maybe this is required to accept pull requests, I am not
> sure.)
> > >
> > > Should we revisit our policy here?
> > >
> > > [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed
> > >
> > > --
> > > Jonathan Ellis
> > > Project Chair, Apache Cassandra
> > > co-founder, http://www.datastax.com
> > > @spyced
> > >
> >
> >
> >
> > --
> > Ben Coverston
> > DataStax -- The Apache Cassandra Company
> >
>
--
http://twitter.com/tjake
Re: Github pull requests
Posted by Edward Capriolo <ed...@gmail.com>.
>> I think it goes the other way around. When you push to ASF git with the
right commit message then the integration from that side closes the pull
request.
Yes. This is how apache-gossip is setup. Someone makes a JIRA and they
include a link to there branch and tell me they are done. We review
git checkout apache master
git pull otherperson jira-123
git push origin master
Ticket on github is "magically" closed.
On Mon, Aug 29, 2016 at 8:45 AM, J. D. Jordan <je...@gmail.com>
wrote:
> I think it goes the other way around. When you push to ASF git with the
> right commit message then the integration from that side closes the pull
> request.
>
> > On Aug 28, 2016, at 11:48 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> >
> > Don't we need something on the infra side to turn a merged pull request
> > into a commit to the ASF repo?
> >
> > On Sun, Aug 28, 2016 at 11:07 PM, Nate McCall <na...@thelastpickle.com>
> > wrote:
> >
> >>>
> >>>
> >>> Infra is exploring options for giving PMCs greater control over GitHub
> >>> config (including allowing GitHub to be the master with a golden copy
> >>> held at the ASF) but that is a work in progress.
> >> ^ Per Mark's comment, there is not anything we can really do past what
> >> Jake F. described with Thrift. We dealt with this with Usergrid back in
> >> incubation two years ago (Jake F. actually helped us get it all sorted
> at
> >> the time) when we were using https://github.com/usergrid/usergrid as
> the
> >> source:
> >> http://mail-archives.apache.org/mod_mbox/usergrid-dev/201405.mbox/%
> >> 3CCANyrgvdTVzZQD7w3C96LUHa=H7-H4Qmu4H7aJsXOAT0gD0fJPw@mail.gmail.com%3E
> >>
> >> Here is the Thrift guide again for reference:
> >> https://github.com/apache/thrift/blob/master/
> CONTRIBUTING.md#contributing-
> >> via-github-pull-requests
> >>
> >> JClouds also has a nice write up/how-to (we based Usergrid on this,
> >> initially):
> >> https://cwiki.apache.org/confluence/display/JCLOUDS/Git+workflow
> >>
> >> Maybe we just amend our 'how-to-commit' with similar details as the two
> >> references above?
> >> http://cassandra.apache.org/doc/latest/development/how_to_commit.html
> >>
> >> -Nate
> >>
> >> On Mon, Aug 29, 2016 at 10:44 AM, Nate McCall <na...@thelastpickle.com>
> >> wrote:
> >>
> >>>
> >>>> Nate, since you have experience with this from Usergrid, can you
> figure
> >>>> out
> >>>> what we need to do to make this happen and follow up with infra?
> >>>
> >>> Yep - i'll look into this.
> >
> >
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
>
Re: Github pull requests
Posted by Jeff Jirsa <je...@crowdstrike.com>.
I guess someone would have to open 3 different PRs (say, 2.2, 3.0, trunk), and the committer would have 3 different commit messages to close each of them?
Anyone have examples of projects with branching strategies similar to ours using github pull requests?
On 8/29/16, 6:26 AM, "Sylvain Lebresne" <sy...@datastax.com> wrote:
>Sorry for being obtuse but what do we win exactly?
>
>The way we're currently working is that a lot of ticket spans 2 or more
>branches so that most people currently submit patches by attaching link to
>the
>relevant branches (one for each version we should commit to) as well as
>links
>to the CI results for those branches. Unless we make serious changes to how
>we
>do things (but I, for one, wouldn't mind clarifications on those changes),
>this doesn't seem to reduce itself well to a single pull request.
>
>On Mon, Aug 29, 2016 at 2:45 PM, J. D. Jordan <https://urldefense.proofpoint.com/v2/url?u=http-3A__jeremiah.jordan-40gmail.com&d=DQIBaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=Y1lrf5Xrsdr1rC9ExKJpIfCHsLS2-I-Tq_G9IKGN4YU&s=RDBg4WBtc535U9iJBWBSIw9OJItd2ZcsL3Kqpzh6Xk8&e= >
>wrote:
>
>> I think it goes the other way around. When you push to ASF git with the
>> right commit message then the integration from that side closes the pull
>> request.
>>
>> > On Aug 28, 2016, at 11:48 PM, Jonathan Ellis <jb...@gmail.com> wrote:
>> >
>> > Don't we need something on the infra side to turn a merged pull request
>> > into a commit to the ASF repo?
>> >
>> > On Sun, Aug 28, 2016 at 11:07 PM, Nate McCall <na...@thelastpickle.com>
>> > wrote:
>> >
>> >>>
>> >>>
>> >>> Infra is exploring options for giving PMCs greater control over GitHub
>> >>> config (including allowing GitHub to be the master with a golden copy
>> >>> held at the ASF) but that is a work in progress.
>> >> ^ Per Mark's comment, there is not anything we can really do past what
>> >> Jake F. described with Thrift. We dealt with this with Usergrid back in
>> >> incubation two years ago (Jake F. actually helped us get it all sorted
>> at
>> >> the time) when we were using https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_usergrid_usergrid&d=DQIBaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=Y1lrf5Xrsdr1rC9ExKJpIfCHsLS2-I-Tq_G9IKGN4YU&s=QJDmpc1jGzcYxAuVgRITwhtE0pvI9cX89qzs4PYGOEw&e= as
>> the
>> >> source:
>> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__mail-2Darchives.apache.org_mod-5Fmbox_usergrid-2Ddev_201405.mbox_-25&d=DQIBaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=Y1lrf5Xrsdr1rC9ExKJpIfCHsLS2-I-Tq_G9IKGN4YU&s=7kzsf7Cftf3JLs6mxfG9K977BOT4UsPhrNrF0AUNMxE&e=
>> >> 3CCANyrgvdTVzZQD7w3C96LUHa=H7-H4Qmu4H7aJsXOAT0gD0fJPw@mail.gmail.com%3E
>> >>
>> >> Here is the Thrift guide again for reference:
>> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_thrift_blob_master_&d=DQIBaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=Y1lrf5Xrsdr1rC9ExKJpIfCHsLS2-I-Tq_G9IKGN4YU&s=jWroE0rW19cTgXQevrVclo_vrOVZPm3ayttaIDlLsmY&e=
>> CONTRIBUTING.md#contributing-
>> >> via-github-pull-requests
>> >>
>> >> JClouds also has a nice write up/how-to (we based Usergrid on this,
>> >> initially):
>> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_JCLOUDS_Git-2Bworkflow&d=DQIBaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=Y1lrf5Xrsdr1rC9ExKJpIfCHsLS2-I-Tq_G9IKGN4YU&s=myPol_9DxHRsfH9Qu4wumwGS85iQMim1H6adNG5q0Nw&e=
>> >>
>> >> Maybe we just amend our 'how-to-commit' with similar details as the two
>> >> references above?
>> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__cassandra.apache.org_doc_latest_development_how-5Fto-5Fcommit.html&d=DQIBaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=Y1lrf5Xrsdr1rC9ExKJpIfCHsLS2-I-Tq_G9IKGN4YU&s=4uaZpa4HwH5Zmy1kcnup2pF7IVDFSNugBV7oKrDNFqA&e=
>> >>
>> >> -Nate
>> >>
>> >> On Mon, Aug 29, 2016 at 10:44 AM, Nate McCall <na...@thelastpickle.com>
>> >> wrote:
>> >>
>> >>>
>> >>>> Nate, since you have experience with this from Usergrid, can you
>> figure
>> >>>> out
>> >>>> what we need to do to make this happen and follow up with infra?
>> >>>
>> >>> Yep - i'll look into this.
>> >
>> >
>> >
>> > --
>> > Jonathan Ellis
>> > Project Chair, Apache Cassandra
>> > co-founder, https://urldefense.proofpoint.com/v2/url?u=http-3A__www.datastax.com&d=DQIBaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=Y1lrf5Xrsdr1rC9ExKJpIfCHsLS2-I-Tq_G9IKGN4YU&s=X4Ry4_CijxQv9T0pV128swtLPYwyImU73IBOUAzfGig&e=
>> > @spyced
>>
Re: Github pull requests
Posted by Sylvain Lebresne <sy...@datastax.com>.
Sorry for being obtuse but what do we win exactly?
The way we're currently working is that a lot of ticket spans 2 or more
branches so that most people currently submit patches by attaching link to
the
relevant branches (one for each version we should commit to) as well as
links
to the CI results for those branches. Unless we make serious changes to how
we
do things (but I, for one, wouldn't mind clarifications on those changes),
this doesn't seem to reduce itself well to a single pull request.
On Mon, Aug 29, 2016 at 2:45 PM, J. D. Jordan <je...@gmail.com>
wrote:
> I think it goes the other way around. When you push to ASF git with the
> right commit message then the integration from that side closes the pull
> request.
>
> > On Aug 28, 2016, at 11:48 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> >
> > Don't we need something on the infra side to turn a merged pull request
> > into a commit to the ASF repo?
> >
> > On Sun, Aug 28, 2016 at 11:07 PM, Nate McCall <na...@thelastpickle.com>
> > wrote:
> >
> >>>
> >>>
> >>> Infra is exploring options for giving PMCs greater control over GitHub
> >>> config (including allowing GitHub to be the master with a golden copy
> >>> held at the ASF) but that is a work in progress.
> >> ^ Per Mark's comment, there is not anything we can really do past what
> >> Jake F. described with Thrift. We dealt with this with Usergrid back in
> >> incubation two years ago (Jake F. actually helped us get it all sorted
> at
> >> the time) when we were using https://github.com/usergrid/usergrid as
> the
> >> source:
> >> http://mail-archives.apache.org/mod_mbox/usergrid-dev/201405.mbox/%
> >> 3CCANyrgvdTVzZQD7w3C96LUHa=H7-H4Qmu4H7aJsXOAT0gD0fJPw@mail.gmail.com%3E
> >>
> >> Here is the Thrift guide again for reference:
> >> https://github.com/apache/thrift/blob/master/
> CONTRIBUTING.md#contributing-
> >> via-github-pull-requests
> >>
> >> JClouds also has a nice write up/how-to (we based Usergrid on this,
> >> initially):
> >> https://cwiki.apache.org/confluence/display/JCLOUDS/Git+workflow
> >>
> >> Maybe we just amend our 'how-to-commit' with similar details as the two
> >> references above?
> >> http://cassandra.apache.org/doc/latest/development/how_to_commit.html
> >>
> >> -Nate
> >>
> >> On Mon, Aug 29, 2016 at 10:44 AM, Nate McCall <na...@thelastpickle.com>
> >> wrote:
> >>
> >>>
> >>>> Nate, since you have experience with this from Usergrid, can you
> figure
> >>>> out
> >>>> what we need to do to make this happen and follow up with infra?
> >>>
> >>> Yep - i'll look into this.
> >
> >
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
>
Re: Github pull requests
Posted by "J. D. Jordan" <je...@gmail.com>.
I think it goes the other way around. When you push to ASF git with the right commit message then the integration from that side closes the pull request.
> On Aug 28, 2016, at 11:48 PM, Jonathan Ellis <jb...@gmail.com> wrote:
>
> Don't we need something on the infra side to turn a merged pull request
> into a commit to the ASF repo?
>
> On Sun, Aug 28, 2016 at 11:07 PM, Nate McCall <na...@thelastpickle.com>
> wrote:
>
>>>
>>>
>>> Infra is exploring options for giving PMCs greater control over GitHub
>>> config (including allowing GitHub to be the master with a golden copy
>>> held at the ASF) but that is a work in progress.
>> ^ Per Mark's comment, there is not anything we can really do past what
>> Jake F. described with Thrift. We dealt with this with Usergrid back in
>> incubation two years ago (Jake F. actually helped us get it all sorted at
>> the time) when we were using https://github.com/usergrid/usergrid as the
>> source:
>> http://mail-archives.apache.org/mod_mbox/usergrid-dev/201405.mbox/%
>> 3CCANyrgvdTVzZQD7w3C96LUHa=H7-H4Qmu4H7aJsXOAT0gD0fJPw@mail.gmail.com%3E
>>
>> Here is the Thrift guide again for reference:
>> https://github.com/apache/thrift/blob/master/CONTRIBUTING.md#contributing-
>> via-github-pull-requests
>>
>> JClouds also has a nice write up/how-to (we based Usergrid on this,
>> initially):
>> https://cwiki.apache.org/confluence/display/JCLOUDS/Git+workflow
>>
>> Maybe we just amend our 'how-to-commit' with similar details as the two
>> references above?
>> http://cassandra.apache.org/doc/latest/development/how_to_commit.html
>>
>> -Nate
>>
>> On Mon, Aug 29, 2016 at 10:44 AM, Nate McCall <na...@thelastpickle.com>
>> wrote:
>>
>>>
>>>> Nate, since you have experience with this from Usergrid, can you figure
>>>> out
>>>> what we need to do to make this happen and follow up with infra?
>>>
>>> Yep - i'll look into this.
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
Re: Github pull requests
Posted by DuyHai Doan <do...@gmail.com>.
Just a question before moving forward, do we want to trigger CI build for
each proposed pull request on Github ? And if yes, on which infra ?
I'm asking because opening PR to the crowd is a good thing but we may have
tons of PRs coming and the infra may be heavily loaded.
Apache Zeppelin project is using Travis as CI infra and there are
constantly errors related to resource shortage (not enough CPU/memory
available)
On Mon, Aug 29, 2016 at 6:48 AM, Jonathan Ellis <jb...@gmail.com> wrote:
> Don't we need something on the infra side to turn a merged pull request
> into a commit to the ASF repo?
>
> On Sun, Aug 28, 2016 at 11:07 PM, Nate McCall <na...@thelastpickle.com>
> wrote:
>
> > >
> > >
> > > Infra is exploring options for giving PMCs greater control over GitHub
> > > config (including allowing GitHub to be the master with a golden copy
> > > held at the ASF) but that is a work in progress.
> > >
> > >
> > ^ Per Mark's comment, there is not anything we can really do past what
> > Jake F. described with Thrift. We dealt with this with Usergrid back in
> > incubation two years ago (Jake F. actually helped us get it all sorted at
> > the time) when we were using https://github.com/usergrid/usergrid as the
> > source:
> > http://mail-archives.apache.org/mod_mbox/usergrid-dev/201405.mbox/%
> > 3CCANyrgvdTVzZQD7w3C96LUHa=H7-H4Qmu4H7aJsXOAT0gD0fJPw@mail.gmail.com%3E
> >
> > Here is the Thrift guide again for reference:
> > https://github.com/apache/thrift/blob/master/
> CONTRIBUTING.md#contributing-
> > via-github-pull-requests
> >
> > JClouds also has a nice write up/how-to (we based Usergrid on this,
> > initially):
> > https://cwiki.apache.org/confluence/display/JCLOUDS/Git+workflow
> >
> > Maybe we just amend our 'how-to-commit' with similar details as the two
> > references above?
> > http://cassandra.apache.org/doc/latest/development/how_to_commit.html
> >
> > -Nate
> >
> > On Mon, Aug 29, 2016 at 10:44 AM, Nate McCall <na...@thelastpickle.com>
> > wrote:
> >
> > >
> > >> Nate, since you have experience with this from Usergrid, can you
> figure
> > >> out
> > >> what we need to do to make this happen and follow up with infra?
> > >>
> > >
> > > Yep - i'll look into this.
> > >
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>
Re: Github pull requests
Posted by Jonathan Ellis <jb...@gmail.com>.
Don't we need something on the infra side to turn a merged pull request
into a commit to the ASF repo?
On Sun, Aug 28, 2016 at 11:07 PM, Nate McCall <na...@thelastpickle.com>
wrote:
> >
> >
> > Infra is exploring options for giving PMCs greater control over GitHub
> > config (including allowing GitHub to be the master with a golden copy
> > held at the ASF) but that is a work in progress.
> >
> >
> ^ Per Mark's comment, there is not anything we can really do past what
> Jake F. described with Thrift. We dealt with this with Usergrid back in
> incubation two years ago (Jake F. actually helped us get it all sorted at
> the time) when we were using https://github.com/usergrid/usergrid as the
> source:
> http://mail-archives.apache.org/mod_mbox/usergrid-dev/201405.mbox/%
> 3CCANyrgvdTVzZQD7w3C96LUHa=H7-H4Qmu4H7aJsXOAT0gD0fJPw@mail.gmail.com%3E
>
> Here is the Thrift guide again for reference:
> https://github.com/apache/thrift/blob/master/CONTRIBUTING.md#contributing-
> via-github-pull-requests
>
> JClouds also has a nice write up/how-to (we based Usergrid on this,
> initially):
> https://cwiki.apache.org/confluence/display/JCLOUDS/Git+workflow
>
> Maybe we just amend our 'how-to-commit' with similar details as the two
> references above?
> http://cassandra.apache.org/doc/latest/development/how_to_commit.html
>
> -Nate
>
> On Mon, Aug 29, 2016 at 10:44 AM, Nate McCall <na...@thelastpickle.com>
> wrote:
>
> >
> >> Nate, since you have experience with this from Usergrid, can you figure
> >> out
> >> what we need to do to make this happen and follow up with infra?
> >>
> >
> > Yep - i'll look into this.
> >
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced
Re: Github pull requests
Posted by Nate McCall <na...@thelastpickle.com>.
>
>
> Infra is exploring options for giving PMCs greater control over GitHub
> config (including allowing GitHub to be the master with a golden copy
> held at the ASF) but that is a work in progress.
>
>
^ Per Mark's comment, there is not anything we can really do past what
Jake F. described with Thrift. We dealt with this with Usergrid back in
incubation two years ago (Jake F. actually helped us get it all sorted at
the time) when we were using https://github.com/usergrid/usergrid as the
source:
http://mail-archives.apache.org/mod_mbox/usergrid-dev/201405.mbox/%3CCANyrgvdTVzZQD7w3C96LUHa=H7-H4Qmu4H7aJsXOAT0gD0fJPw@mail.gmail.com%3E
Here is the Thrift guide again for reference:
https://github.com/apache/thrift/blob/master/CONTRIBUTING.md#contributing-via-github-pull-requests
JClouds also has a nice write up/how-to (we based Usergrid on this,
initially):
https://cwiki.apache.org/confluence/display/JCLOUDS/Git+workflow
Maybe we just amend our 'how-to-commit' with similar details as the two
references above?
http://cassandra.apache.org/doc/latest/development/how_to_commit.html
-Nate
On Mon, Aug 29, 2016 at 10:44 AM, Nate McCall <na...@thelastpickle.com>
wrote:
>
>> Nate, since you have experience with this from Usergrid, can you figure
>> out
>> what we need to do to make this happen and follow up with infra?
>>
>
> Yep - i'll look into this.
>
Re: Github pull requests
Posted by Nate McCall <na...@thelastpickle.com>.
>
>
> Nate, since you have experience with this from Usergrid, can you figure out
> what we need to do to make this happen and follow up with infra?
>
Yep - i'll look into this.
Re: Github pull requests
Posted by Jonathan Ellis <jb...@gmail.com>.
It sounds like we have consensus that enabling pull requests would be a
Very Good Thing.
Nate, since you have experience with this from Usergrid, can you figure out
what we need to do to make this happen and follow up with infra?
On Sun, Aug 28, 2016 at 3:07 PM, Nate McCall <na...@thelastpickle.com> wrote:
> +1
>
> Github PRs have worked well for Usergrid:
> https://cwiki.apache.org/confluence/display/usergrid/
> Usergrid+Contribution+Workflow
>
>
> On Sat, Aug 27, 2016 at 4:15 AM, Jake Luciani <ja...@gmail.com> wrote:
>
> > Jake could you show an example issue and how the pipeline works?
> >
> > On Fri, Aug 26, 2016 at 12:03 PM, Jake Farrell <jf...@apache.org>
> > wrote:
> >
> > > We just switched Apache Thrift over to using Github for all our inbound
> > > contributions, have not made Github canonical yet. We wanted to have
> one
> > > unified way to accept patches and also make it easier for automated CI
> to
> > > validate the patch prior to review. Much easier now that we have a set
> > > pipeline
> > >
> > > -Jake
> > >
> > > On Fri, Aug 26, 2016 at 11:44 AM, Ben Coverston <
> > > ben.coverston@datastax.com>
> > > wrote:
> > >
> > > > I think it would certainly make contributing to Cassandra more
> > > > straightforward.
> > > >
> > > > I'm not a committer, so I don't regularly create patches, and every
> > time
> > > I
> > > > do I have to search/verify that I'm doing it right.
> > > >
> > > > But pull requests? I make pull requests every day, and GitHub makes
> > that
> > > > process work the same everywhere.
> > > >
> > > > On Fri, Aug 26, 2016 at 9:33 AM, Jonathan Ellis <jb...@gmail.com>
> > > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > Historically we've insisted that people go through the process of
> > > > creating
> > > > > a Jira issue and attaching a patch or linking a branch to
> demonstrate
> > > > > intent-to-contribute and to make sure we have a unified record of
> > > changes
> > > > > in Jira.
> > > > >
> > > > > But I understand that other Apache projects are now recognizing a
> > > github
> > > > > pull request as intent-to-contribute [1] and some are even making
> > > github
> > > > > the official repo, with an Apache mirror, rather than the other way
> > > > > around. (Maybe this is required to accept pull requests, I am not
> > > sure.)
> > > > >
> > > > > Should we revisit our policy here?
> > > > >
> > > > > [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%
> 3Aclosed
> > > > >
> > > > > --
> > > > > Jonathan Ellis
> > > > > Project Chair, Apache Cassandra
> > > > > co-founder, http://www.datastax.com
> > > > > @spyced
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Ben Coverston
> > > > DataStax -- The Apache Cassandra Company
> > > >
> > >
> >
> >
> >
> > --
> > http://twitter.com/tjake
> >
>
>
>
> --
> -----------------
> Nate McCall
> Wellington, NZ
> @zznate
>
> CTO
> Apache Cassandra Consulting
> http://www.thelastpickle.com
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced
Re: Github pull requests
Posted by Nate McCall <na...@thelastpickle.com>.
+1
Github PRs have worked well for Usergrid:
https://cwiki.apache.org/confluence/display/usergrid/Usergrid+Contribution+Workflow
On Sat, Aug 27, 2016 at 4:15 AM, Jake Luciani <ja...@gmail.com> wrote:
> Jake could you show an example issue and how the pipeline works?
>
> On Fri, Aug 26, 2016 at 12:03 PM, Jake Farrell <jf...@apache.org>
> wrote:
>
> > We just switched Apache Thrift over to using Github for all our inbound
> > contributions, have not made Github canonical yet. We wanted to have one
> > unified way to accept patches and also make it easier for automated CI to
> > validate the patch prior to review. Much easier now that we have a set
> > pipeline
> >
> > -Jake
> >
> > On Fri, Aug 26, 2016 at 11:44 AM, Ben Coverston <
> > ben.coverston@datastax.com>
> > wrote:
> >
> > > I think it would certainly make contributing to Cassandra more
> > > straightforward.
> > >
> > > I'm not a committer, so I don't regularly create patches, and every
> time
> > I
> > > do I have to search/verify that I'm doing it right.
> > >
> > > But pull requests? I make pull requests every day, and GitHub makes
> that
> > > process work the same everywhere.
> > >
> > > On Fri, Aug 26, 2016 at 9:33 AM, Jonathan Ellis <jb...@gmail.com>
> > wrote:
> > >
> > > > Hi all,
> > > >
> > > > Historically we've insisted that people go through the process of
> > > creating
> > > > a Jira issue and attaching a patch or linking a branch to demonstrate
> > > > intent-to-contribute and to make sure we have a unified record of
> > changes
> > > > in Jira.
> > > >
> > > > But I understand that other Apache projects are now recognizing a
> > github
> > > > pull request as intent-to-contribute [1] and some are even making
> > github
> > > > the official repo, with an Apache mirror, rather than the other way
> > > > around. (Maybe this is required to accept pull requests, I am not
> > sure.)
> > > >
> > > > Should we revisit our policy here?
> > > >
> > > > [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed
> > > >
> > > > --
> > > > Jonathan Ellis
> > > > Project Chair, Apache Cassandra
> > > > co-founder, http://www.datastax.com
> > > > @spyced
> > > >
> > >
> > >
> > >
> > > --
> > > Ben Coverston
> > > DataStax -- The Apache Cassandra Company
> > >
> >
>
>
>
> --
> http://twitter.com/tjake
>
--
-----------------
Nate McCall
Wellington, NZ
@zznate
CTO
Apache Cassandra Consulting
http://www.thelastpickle.com
Re: Github pull requests
Posted by Jake Farrell <jf...@apache.org>.
We still include both processes in our how to contribute, but github is the
new preferred method (thanks for the reminder to update that doc)
https://github.com/apache/thrift/blob/master/CONTRIBUTING.md
and an example of the cross commenting: THRIFT-3876 with matching PR 1045
https://github.com/apache/thrift/pull/1045
https://issues.apache.org/jira/browse/THRIFT-3876
On Fri, Aug 26, 2016 at 12:15 PM, Jake Luciani <ja...@gmail.com> wrote:
> Jake could you show an example issue and how the pipeline works?
>
> On Fri, Aug 26, 2016 at 12:03 PM, Jake Farrell <jf...@apache.org>
> wrote:
>
> > We just switched Apache Thrift over to using Github for all our inbound
> > contributions, have not made Github canonical yet. We wanted to have one
> > unified way to accept patches and also make it easier for automated CI to
> > validate the patch prior to review. Much easier now that we have a set
> > pipeline
> >
> > -Jake
> >
> > On Fri, Aug 26, 2016 at 11:44 AM, Ben Coverston <
> > ben.coverston@datastax.com>
> > wrote:
> >
> > > I think it would certainly make contributing to Cassandra more
> > > straightforward.
> > >
> > > I'm not a committer, so I don't regularly create patches, and every
> time
> > I
> > > do I have to search/verify that I'm doing it right.
> > >
> > > But pull requests? I make pull requests every day, and GitHub makes
> that
> > > process work the same everywhere.
> > >
> > > On Fri, Aug 26, 2016 at 9:33 AM, Jonathan Ellis <jb...@gmail.com>
> > wrote:
> > >
> > > > Hi all,
> > > >
> > > > Historically we've insisted that people go through the process of
> > > creating
> > > > a Jira issue and attaching a patch or linking a branch to demonstrate
> > > > intent-to-contribute and to make sure we have a unified record of
> > changes
> > > > in Jira.
> > > >
> > > > But I understand that other Apache projects are now recognizing a
> > github
> > > > pull request as intent-to-contribute [1] and some are even making
> > github
> > > > the official repo, with an Apache mirror, rather than the other way
> > > > around. (Maybe this is required to accept pull requests, I am not
> > sure.)
> > > >
> > > > Should we revisit our policy here?
> > > >
> > > > [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed
> > > >
> > > > --
> > > > Jonathan Ellis
> > > > Project Chair, Apache Cassandra
> > > > co-founder, http://www.datastax.com
> > > > @spyced
> > > >
> > >
> > >
> > >
> > > --
> > > Ben Coverston
> > > DataStax -- The Apache Cassandra Company
> > >
> >
>
>
>
> --
> http://twitter.com/tjake
>
Re: Github pull requests
Posted by Jake Luciani <ja...@gmail.com>.
Jake could you show an example issue and how the pipeline works?
On Fri, Aug 26, 2016 at 12:03 PM, Jake Farrell <jf...@apache.org> wrote:
> We just switched Apache Thrift over to using Github for all our inbound
> contributions, have not made Github canonical yet. We wanted to have one
> unified way to accept patches and also make it easier for automated CI to
> validate the patch prior to review. Much easier now that we have a set
> pipeline
>
> -Jake
>
> On Fri, Aug 26, 2016 at 11:44 AM, Ben Coverston <
> ben.coverston@datastax.com>
> wrote:
>
> > I think it would certainly make contributing to Cassandra more
> > straightforward.
> >
> > I'm not a committer, so I don't regularly create patches, and every time
> I
> > do I have to search/verify that I'm doing it right.
> >
> > But pull requests? I make pull requests every day, and GitHub makes that
> > process work the same everywhere.
> >
> > On Fri, Aug 26, 2016 at 9:33 AM, Jonathan Ellis <jb...@gmail.com>
> wrote:
> >
> > > Hi all,
> > >
> > > Historically we've insisted that people go through the process of
> > creating
> > > a Jira issue and attaching a patch or linking a branch to demonstrate
> > > intent-to-contribute and to make sure we have a unified record of
> changes
> > > in Jira.
> > >
> > > But I understand that other Apache projects are now recognizing a
> github
> > > pull request as intent-to-contribute [1] and some are even making
> github
> > > the official repo, with an Apache mirror, rather than the other way
> > > around. (Maybe this is required to accept pull requests, I am not
> sure.)
> > >
> > > Should we revisit our policy here?
> > >
> > > [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed
> > >
> > > --
> > > Jonathan Ellis
> > > Project Chair, Apache Cassandra
> > > co-founder, http://www.datastax.com
> > > @spyced
> > >
> >
> >
> >
> > --
> > Ben Coverston
> > DataStax -- The Apache Cassandra Company
> >
>
--
http://twitter.com/tjake
Re: Github pull requests
Posted by Jake Farrell <jf...@apache.org>.
We just switched Apache Thrift over to using Github for all our inbound
contributions, have not made Github canonical yet. We wanted to have one
unified way to accept patches and also make it easier for automated CI to
validate the patch prior to review. Much easier now that we have a set
pipeline
-Jake
On Fri, Aug 26, 2016 at 11:44 AM, Ben Coverston <be...@datastax.com>
wrote:
> I think it would certainly make contributing to Cassandra more
> straightforward.
>
> I'm not a committer, so I don't regularly create patches, and every time I
> do I have to search/verify that I'm doing it right.
>
> But pull requests? I make pull requests every day, and GitHub makes that
> process work the same everywhere.
>
> On Fri, Aug 26, 2016 at 9:33 AM, Jonathan Ellis <jb...@gmail.com> wrote:
>
> > Hi all,
> >
> > Historically we've insisted that people go through the process of
> creating
> > a Jira issue and attaching a patch or linking a branch to demonstrate
> > intent-to-contribute and to make sure we have a unified record of changes
> > in Jira.
> >
> > But I understand that other Apache projects are now recognizing a github
> > pull request as intent-to-contribute [1] and some are even making github
> > the official repo, with an Apache mirror, rather than the other way
> > around. (Maybe this is required to accept pull requests, I am not sure.)
> >
> > Should we revisit our policy here?
> >
> > [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
> >
>
>
>
> --
> Ben Coverston
> DataStax -- The Apache Cassandra Company
>
Re: Github pull requests
Posted by Ben Coverston <be...@datastax.com>.
I think it would certainly make contributing to Cassandra more
straightforward.
I'm not a committer, so I don't regularly create patches, and every time I
do I have to search/verify that I'm doing it right.
But pull requests? I make pull requests every day, and GitHub makes that
process work the same everywhere.
On Fri, Aug 26, 2016 at 9:33 AM, Jonathan Ellis <jb...@gmail.com> wrote:
> Hi all,
>
> Historically we've insisted that people go through the process of creating
> a Jira issue and attaching a patch or linking a branch to demonstrate
> intent-to-contribute and to make sure we have a unified record of changes
> in Jira.
>
> But I understand that other Apache projects are now recognizing a github
> pull request as intent-to-contribute [1] and some are even making github
> the official repo, with an Apache mirror, rather than the other way
> around. (Maybe this is required to accept pull requests, I am not sure.)
>
> Should we revisit our policy here?
>
> [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>
--
Ben Coverston
DataStax -- The Apache Cassandra Company
Re: Github pull requests
Posted by Jason Brown <ja...@gmail.com>.
@Jeremiah, makes sense to send to commits@
On Fri, Aug 26, 2016 at 12:55 PM, Jeremiah D Jordan <
jeremiah.jordan@gmail.com> wrote:
> +1 for PR’s but if we start using them I think we should get them sent to
> commits@ instead of the dev@ they are currently sent to.
>
> -Jeremiah
>
> > On Aug 26, 2016, at 1:38 PM, Andres de la Peña <ad...@stratio.com>
> wrote:
> >
> > +1 to GitHub PRs, I think it will make things easier.
> >
> > El viernes, 26 de agosto de 2016, Jason Brown <ja...@gmail.com>
> > escribió:
> >
> >> D'oh, forgot to explicitly state that I am +1 one on the github PR
> proposal
> >> :)
> >>
> >> On Fri, Aug 26, 2016 at 11:07 AM, Jason Brown <jasedbrown@gmail.com
> >> <javascript:;>> wrote:
> >>
> >>> It seems to me we might get more contributions if we can lower the
> >> barrier
> >>> to participation. (see Jeff Beck's statement above)
> >>>
> >>> +1 to Aleksey's sentiment about the Docs contributions.
> >>>
> >>> On Fri, Aug 26, 2016 at 9:48 AM, Mark Thomas <markt@apache.org
> >> <javascript:;>> wrote:
> >>>
> >>>> On 26/08/2016 17:11, Aleksey Yeschenko wrote:
> >>>>> Mark, I, for one, will be happy with the level of GitHub integration
> >>>> that Spark has, formal or otherwise.
> >>>>
> >>>> If Cassandra doesn't already have it, that should be a simple request
> to
> >>>> infra.
> >>>>
> >>>>> As it stands right now, none of the committers/PMC members have any
> >>>> control over Cassandra Github mirror.
> >>>>>
> >>>>> Which, among other things, means that we cannot even close the
> >>>> erroneously opened PRs ourselves,
> >>>>> they just accumulate unless the PR authors is kind enough to close
> >>>> them. That’s really frustrating.
> >>>>
> >>>> No PMC currently has the ability to directly close PRs on GitHub. This
> >>>> is one of the things on the infra TODO list that is being looked at.
> You
> >>>> can close them via a commit comment that the ASF GitHub tooling picks
> >> up.
> >>>>
> >>>> Mark
> >>>>
> >>>>
> >>>>>
> >>>>> --
> >>>>> AY
> >>>>>
> >>>>> On 26 August 2016 at 17:07:29, Mark Thomas (markt@apache.org
> >> <javascript:;>) wrote:
> >>>>>
> >>>>> On 26/08/2016 16:33, Jonathan Ellis wrote:
> >>>>>> Hi all,
> >>>>>>
> >>>>>> Historically we've insisted that people go through the process of
> >>>> creating
> >>>>>> a Jira issue and attaching a patch or linking a branch to
> demonstrate
> >>>>>> intent-to-contribute and to make sure we have a unified record of
> >>>> changes
> >>>>>> in Jira.
> >>>>>>
> >>>>>> But I understand that other Apache projects are now recognizing a
> >>>> github
> >>>>>> pull request as intent-to-contribute [1] and some are even making
> >>>> github
> >>>>>> the official repo, with an Apache mirror, rather than the other way
> >>>>>> around. (Maybe this is required to accept pull requests, I am not
> >>>> sure.)
> >>>>>>
> >>>>>> Should we revisit our policy here?
> >>>>>
> >>>>> At the moment, the ASF Git repo is always the master, with GitHub as
> a
> >>>>> mirror. That allows push requests to be made via GitHub.
> >>>>>
> >>>>> Infra is exploring options for giving PMCs greater control over
> GitHub
> >>>>> config (including allowing GitHub to be the master with a golden copy
> >>>>> held at the ASF) but that is a work in progress.
> >>>>>
> >>>>> As far as intent to contribute goes, there does appear to be a trend
> >>>>> that the newer a project is to the ASF, the more formal the project
> >>>>> makes process around recording intent to contribute. (The same can be
> >>>>> said for other processes as well like Jira config.)
> >>>>>
> >>>>> It is worth noting that all the ASF requires is that there is an
> >> intent
> >>>>> to contribute. Anything that can be reasonably read that way is fine.
> >>>>> Many PMCs happily accept patches sent to the dev list (although they
> >> may
> >>>>> ask them to be attached to issues more so they don't get forgotten
> >> than
> >>>>> anything else). Pull requests are certainly acceptable.
> >>>>>
> >>>>> My personal recommendation is don't put more formal process in place
> >>>>> than you actually need. Social controls are a lot more flexible than
> >>>>> technical ones and generally have a much lower overhead.
> >>>>>
> >>>>> Mark
> >>>>>
> >>>>>>
> >>>>>> [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%
> 3Aclosed
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >
> >
> > --
> > Andrés de la Peña
> >
> > Vía de las dos Castillas, 33, Ática 4, 3ª Planta
> > 28224 Pozuelo de Alarcón, Madrid
> > Tel: +34 91 828 6473 // www.stratio.com // *@stratiobd
> > <https://twitter.com/StratioBD>*
>
>
Re: Github pull requests
Posted by Jeremiah D Jordan <je...@gmail.com>.
+1 for PR’s but if we start using them I think we should get them sent to commits@ instead of the dev@ they are currently sent to.
-Jeremiah
> On Aug 26, 2016, at 1:38 PM, Andres de la Peña <ad...@stratio.com> wrote:
>
> +1 to GitHub PRs, I think it will make things easier.
>
> El viernes, 26 de agosto de 2016, Jason Brown <ja...@gmail.com>
> escribió:
>
>> D'oh, forgot to explicitly state that I am +1 one on the github PR proposal
>> :)
>>
>> On Fri, Aug 26, 2016 at 11:07 AM, Jason Brown <jasedbrown@gmail.com
>> <javascript:;>> wrote:
>>
>>> It seems to me we might get more contributions if we can lower the
>> barrier
>>> to participation. (see Jeff Beck's statement above)
>>>
>>> +1 to Aleksey's sentiment about the Docs contributions.
>>>
>>> On Fri, Aug 26, 2016 at 9:48 AM, Mark Thomas <markt@apache.org
>> <javascript:;>> wrote:
>>>
>>>> On 26/08/2016 17:11, Aleksey Yeschenko wrote:
>>>>> Mark, I, for one, will be happy with the level of GitHub integration
>>>> that Spark has, formal or otherwise.
>>>>
>>>> If Cassandra doesn't already have it, that should be a simple request to
>>>> infra.
>>>>
>>>>> As it stands right now, none of the committers/PMC members have any
>>>> control over Cassandra Github mirror.
>>>>>
>>>>> Which, among other things, means that we cannot even close the
>>>> erroneously opened PRs ourselves,
>>>>> they just accumulate unless the PR authors is kind enough to close
>>>> them. That’s really frustrating.
>>>>
>>>> No PMC currently has the ability to directly close PRs on GitHub. This
>>>> is one of the things on the infra TODO list that is being looked at. You
>>>> can close them via a commit comment that the ASF GitHub tooling picks
>> up.
>>>>
>>>> Mark
>>>>
>>>>
>>>>>
>>>>> --
>>>>> AY
>>>>>
>>>>> On 26 August 2016 at 17:07:29, Mark Thomas (markt@apache.org
>> <javascript:;>) wrote:
>>>>>
>>>>> On 26/08/2016 16:33, Jonathan Ellis wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Historically we've insisted that people go through the process of
>>>> creating
>>>>>> a Jira issue and attaching a patch or linking a branch to demonstrate
>>>>>> intent-to-contribute and to make sure we have a unified record of
>>>> changes
>>>>>> in Jira.
>>>>>>
>>>>>> But I understand that other Apache projects are now recognizing a
>>>> github
>>>>>> pull request as intent-to-contribute [1] and some are even making
>>>> github
>>>>>> the official repo, with an Apache mirror, rather than the other way
>>>>>> around. (Maybe this is required to accept pull requests, I am not
>>>> sure.)
>>>>>>
>>>>>> Should we revisit our policy here?
>>>>>
>>>>> At the moment, the ASF Git repo is always the master, with GitHub as a
>>>>> mirror. That allows push requests to be made via GitHub.
>>>>>
>>>>> Infra is exploring options for giving PMCs greater control over GitHub
>>>>> config (including allowing GitHub to be the master with a golden copy
>>>>> held at the ASF) but that is a work in progress.
>>>>>
>>>>> As far as intent to contribute goes, there does appear to be a trend
>>>>> that the newer a project is to the ASF, the more formal the project
>>>>> makes process around recording intent to contribute. (The same can be
>>>>> said for other processes as well like Jira config.)
>>>>>
>>>>> It is worth noting that all the ASF requires is that there is an
>> intent
>>>>> to contribute. Anything that can be reasonably read that way is fine.
>>>>> Many PMCs happily accept patches sent to the dev list (although they
>> may
>>>>> ask them to be attached to issues more so they don't get forgotten
>> than
>>>>> anything else). Pull requests are certainly acceptable.
>>>>>
>>>>> My personal recommendation is don't put more formal process in place
>>>>> than you actually need. Social controls are a lot more flexible than
>>>>> technical ones and generally have a much lower overhead.
>>>>>
>>>>> Mark
>>>>>
>>>>>>
>>>>>> [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>
> --
> Andrés de la Peña
>
> Vía de las dos Castillas, 33, Ática 4, 3ª Planta
> 28224 Pozuelo de Alarcón, Madrid
> Tel: +34 91 828 6473 // www.stratio.com // *@stratiobd
> <https://twitter.com/StratioBD>*
Re: Github pull requests
Posted by Andres de la Peña <ad...@stratio.com>.
+1 to GitHub PRs, I think it will make things easier.
El viernes, 26 de agosto de 2016, Jason Brown <ja...@gmail.com>
escribió:
> D'oh, forgot to explicitly state that I am +1 one on the github PR proposal
> :)
>
> On Fri, Aug 26, 2016 at 11:07 AM, Jason Brown <jasedbrown@gmail.com
> <javascript:;>> wrote:
>
> > It seems to me we might get more contributions if we can lower the
> barrier
> > to participation. (see Jeff Beck's statement above)
> >
> > +1 to Aleksey's sentiment about the Docs contributions.
> >
> > On Fri, Aug 26, 2016 at 9:48 AM, Mark Thomas <markt@apache.org
> <javascript:;>> wrote:
> >
> >> On 26/08/2016 17:11, Aleksey Yeschenko wrote:
> >> > Mark, I, for one, will be happy with the level of GitHub integration
> >> that Spark has, formal or otherwise.
> >>
> >> If Cassandra doesn't already have it, that should be a simple request to
> >> infra.
> >>
> >> > As it stands right now, none of the committers/PMC members have any
> >> control over Cassandra Github mirror.
> >> >
> >> > Which, among other things, means that we cannot even close the
> >> erroneously opened PRs ourselves,
> >> > they just accumulate unless the PR authors is kind enough to close
> >> them. That’s really frustrating.
> >>
> >> No PMC currently has the ability to directly close PRs on GitHub. This
> >> is one of the things on the infra TODO list that is being looked at. You
> >> can close them via a commit comment that the ASF GitHub tooling picks
> up.
> >>
> >> Mark
> >>
> >>
> >> >
> >> > --
> >> > AY
> >> >
> >> > On 26 August 2016 at 17:07:29, Mark Thomas (markt@apache.org
> <javascript:;>) wrote:
> >> >
> >> > On 26/08/2016 16:33, Jonathan Ellis wrote:
> >> >> Hi all,
> >> >>
> >> >> Historically we've insisted that people go through the process of
> >> creating
> >> >> a Jira issue and attaching a patch or linking a branch to demonstrate
> >> >> intent-to-contribute and to make sure we have a unified record of
> >> changes
> >> >> in Jira.
> >> >>
> >> >> But I understand that other Apache projects are now recognizing a
> >> github
> >> >> pull request as intent-to-contribute [1] and some are even making
> >> github
> >> >> the official repo, with an Apache mirror, rather than the other way
> >> >> around. (Maybe this is required to accept pull requests, I am not
> >> sure.)
> >> >>
> >> >> Should we revisit our policy here?
> >> >
> >> > At the moment, the ASF Git repo is always the master, with GitHub as a
> >> > mirror. That allows push requests to be made via GitHub.
> >> >
> >> > Infra is exploring options for giving PMCs greater control over GitHub
> >> > config (including allowing GitHub to be the master with a golden copy
> >> > held at the ASF) but that is a work in progress.
> >> >
> >> > As far as intent to contribute goes, there does appear to be a trend
> >> > that the newer a project is to the ASF, the more formal the project
> >> > makes process around recording intent to contribute. (The same can be
> >> > said for other processes as well like Jira config.)
> >> >
> >> > It is worth noting that all the ASF requires is that there is an
> intent
> >> > to contribute. Anything that can be reasonably read that way is fine.
> >> > Many PMCs happily accept patches sent to the dev list (although they
> may
> >> > ask them to be attached to issues more so they don't get forgotten
> than
> >> > anything else). Pull requests are certainly acceptable.
> >> >
> >> > My personal recommendation is don't put more formal process in place
> >> > than you actually need. Social controls are a lot more flexible than
> >> > technical ones and generally have a much lower overhead.
> >> >
> >> > Mark
> >> >
> >> >>
> >> >> [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed
> >> >
> >> >
> >>
> >>
> >
>
--
Andrés de la Peña
Vía de las dos Castillas, 33, Ática 4, 3ª Planta
28224 Pozuelo de Alarcón, Madrid
Tel: +34 91 828 6473 // www.stratio.com // *@stratiobd
<https://twitter.com/StratioBD>*
Re: Github pull requests
Posted by Jason Brown <ja...@gmail.com>.
D'oh, forgot to explicitly state that I am +1 one on the github PR proposal
:)
On Fri, Aug 26, 2016 at 11:07 AM, Jason Brown <ja...@gmail.com> wrote:
> It seems to me we might get more contributions if we can lower the barrier
> to participation. (see Jeff Beck's statement above)
>
> +1 to Aleksey's sentiment about the Docs contributions.
>
> On Fri, Aug 26, 2016 at 9:48 AM, Mark Thomas <ma...@apache.org> wrote:
>
>> On 26/08/2016 17:11, Aleksey Yeschenko wrote:
>> > Mark, I, for one, will be happy with the level of GitHub integration
>> that Spark has, formal or otherwise.
>>
>> If Cassandra doesn't already have it, that should be a simple request to
>> infra.
>>
>> > As it stands right now, none of the committers/PMC members have any
>> control over Cassandra Github mirror.
>> >
>> > Which, among other things, means that we cannot even close the
>> erroneously opened PRs ourselves,
>> > they just accumulate unless the PR authors is kind enough to close
>> them. That’s really frustrating.
>>
>> No PMC currently has the ability to directly close PRs on GitHub. This
>> is one of the things on the infra TODO list that is being looked at. You
>> can close them via a commit comment that the ASF GitHub tooling picks up.
>>
>> Mark
>>
>>
>> >
>> > --
>> > AY
>> >
>> > On 26 August 2016 at 17:07:29, Mark Thomas (markt@apache.org) wrote:
>> >
>> > On 26/08/2016 16:33, Jonathan Ellis wrote:
>> >> Hi all,
>> >>
>> >> Historically we've insisted that people go through the process of
>> creating
>> >> a Jira issue and attaching a patch or linking a branch to demonstrate
>> >> intent-to-contribute and to make sure we have a unified record of
>> changes
>> >> in Jira.
>> >>
>> >> But I understand that other Apache projects are now recognizing a
>> github
>> >> pull request as intent-to-contribute [1] and some are even making
>> github
>> >> the official repo, with an Apache mirror, rather than the other way
>> >> around. (Maybe this is required to accept pull requests, I am not
>> sure.)
>> >>
>> >> Should we revisit our policy here?
>> >
>> > At the moment, the ASF Git repo is always the master, with GitHub as a
>> > mirror. That allows push requests to be made via GitHub.
>> >
>> > Infra is exploring options for giving PMCs greater control over GitHub
>> > config (including allowing GitHub to be the master with a golden copy
>> > held at the ASF) but that is a work in progress.
>> >
>> > As far as intent to contribute goes, there does appear to be a trend
>> > that the newer a project is to the ASF, the more formal the project
>> > makes process around recording intent to contribute. (The same can be
>> > said for other processes as well like Jira config.)
>> >
>> > It is worth noting that all the ASF requires is that there is an intent
>> > to contribute. Anything that can be reasonably read that way is fine.
>> > Many PMCs happily accept patches sent to the dev list (although they may
>> > ask them to be attached to issues more so they don't get forgotten than
>> > anything else). Pull requests are certainly acceptable.
>> >
>> > My personal recommendation is don't put more formal process in place
>> > than you actually need. Social controls are a lot more flexible than
>> > technical ones and generally have a much lower overhead.
>> >
>> > Mark
>> >
>> >>
>> >> [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed
>> >
>> >
>>
>>
>
Re: Github pull requests
Posted by Jonathan Haddad <jo...@jonhaddad.com>.
+1 to officially supporting GitHub PRs.
On Fri, Aug 26, 2016 at 11:07 AM Jason Brown <ja...@gmail.com> wrote:
> It seems to me we might get more contributions if we can lower the barrier
> to participation. (see Jeff Beck's statement above)
>
> +1 to Aleksey's sentiment about the Docs contributions.
>
> On Fri, Aug 26, 2016 at 9:48 AM, Mark Thomas <ma...@apache.org> wrote:
>
> > On 26/08/2016 17:11, Aleksey Yeschenko wrote:
> > > Mark, I, for one, will be happy with the level of GitHub integration
> > that Spark has, formal or otherwise.
> >
> > If Cassandra doesn't already have it, that should be a simple request to
> > infra.
> >
> > > As it stands right now, none of the committers/PMC members have any
> > control over Cassandra Github mirror.
> > >
> > > Which, among other things, means that we cannot even close the
> > erroneously opened PRs ourselves,
> > > they just accumulate unless the PR authors is kind enough to close
> them.
> > That’s really frustrating.
> >
> > No PMC currently has the ability to directly close PRs on GitHub. This
> > is one of the things on the infra TODO list that is being looked at. You
> > can close them via a commit comment that the ASF GitHub tooling picks up.
> >
> > Mark
> >
> >
> > >
> > > --
> > > AY
> > >
> > > On 26 August 2016 at 17:07:29, Mark Thomas (markt@apache.org) wrote:
> > >
> > > On 26/08/2016 16:33, Jonathan Ellis wrote:
> > >> Hi all,
> > >>
> > >> Historically we've insisted that people go through the process of
> > creating
> > >> a Jira issue and attaching a patch or linking a branch to demonstrate
> > >> intent-to-contribute and to make sure we have a unified record of
> > changes
> > >> in Jira.
> > >>
> > >> But I understand that other Apache projects are now recognizing a
> github
> > >> pull request as intent-to-contribute [1] and some are even making
> github
> > >> the official repo, with an Apache mirror, rather than the other way
> > >> around. (Maybe this is required to accept pull requests, I am not
> sure.)
> > >>
> > >> Should we revisit our policy here?
> > >
> > > At the moment, the ASF Git repo is always the master, with GitHub as a
> > > mirror. That allows push requests to be made via GitHub.
> > >
> > > Infra is exploring options for giving PMCs greater control over GitHub
> > > config (including allowing GitHub to be the master with a golden copy
> > > held at the ASF) but that is a work in progress.
> > >
> > > As far as intent to contribute goes, there does appear to be a trend
> > > that the newer a project is to the ASF, the more formal the project
> > > makes process around recording intent to contribute. (The same can be
> > > said for other processes as well like Jira config.)
> > >
> > > It is worth noting that all the ASF requires is that there is an intent
> > > to contribute. Anything that can be reasonably read that way is fine.
> > > Many PMCs happily accept patches sent to the dev list (although they
> may
> > > ask them to be attached to issues more so they don't get forgotten than
> > > anything else). Pull requests are certainly acceptable.
> > >
> > > My personal recommendation is don't put more formal process in place
> > > than you actually need. Social controls are a lot more flexible than
> > > technical ones and generally have a much lower overhead.
> > >
> > > Mark
> > >
> > >>
> > >> [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed
> > >
> > >
> >
> >
>
Re: Github pull requests
Posted by Jason Brown <ja...@gmail.com>.
It seems to me we might get more contributions if we can lower the barrier
to participation. (see Jeff Beck's statement above)
+1 to Aleksey's sentiment about the Docs contributions.
On Fri, Aug 26, 2016 at 9:48 AM, Mark Thomas <ma...@apache.org> wrote:
> On 26/08/2016 17:11, Aleksey Yeschenko wrote:
> > Mark, I, for one, will be happy with the level of GitHub integration
> that Spark has, formal or otherwise.
>
> If Cassandra doesn't already have it, that should be a simple request to
> infra.
>
> > As it stands right now, none of the committers/PMC members have any
> control over Cassandra Github mirror.
> >
> > Which, among other things, means that we cannot even close the
> erroneously opened PRs ourselves,
> > they just accumulate unless the PR authors is kind enough to close them.
> That’s really frustrating.
>
> No PMC currently has the ability to directly close PRs on GitHub. This
> is one of the things on the infra TODO list that is being looked at. You
> can close them via a commit comment that the ASF GitHub tooling picks up.
>
> Mark
>
>
> >
> > --
> > AY
> >
> > On 26 August 2016 at 17:07:29, Mark Thomas (markt@apache.org) wrote:
> >
> > On 26/08/2016 16:33, Jonathan Ellis wrote:
> >> Hi all,
> >>
> >> Historically we've insisted that people go through the process of
> creating
> >> a Jira issue and attaching a patch or linking a branch to demonstrate
> >> intent-to-contribute and to make sure we have a unified record of
> changes
> >> in Jira.
> >>
> >> But I understand that other Apache projects are now recognizing a github
> >> pull request as intent-to-contribute [1] and some are even making github
> >> the official repo, with an Apache mirror, rather than the other way
> >> around. (Maybe this is required to accept pull requests, I am not sure.)
> >>
> >> Should we revisit our policy here?
> >
> > At the moment, the ASF Git repo is always the master, with GitHub as a
> > mirror. That allows push requests to be made via GitHub.
> >
> > Infra is exploring options for giving PMCs greater control over GitHub
> > config (including allowing GitHub to be the master with a golden copy
> > held at the ASF) but that is a work in progress.
> >
> > As far as intent to contribute goes, there does appear to be a trend
> > that the newer a project is to the ASF, the more formal the project
> > makes process around recording intent to contribute. (The same can be
> > said for other processes as well like Jira config.)
> >
> > It is worth noting that all the ASF requires is that there is an intent
> > to contribute. Anything that can be reasonably read that way is fine.
> > Many PMCs happily accept patches sent to the dev list (although they may
> > ask them to be attached to issues more so they don't get forgotten than
> > anything else). Pull requests are certainly acceptable.
> >
> > My personal recommendation is don't put more formal process in place
> > than you actually need. Social controls are a lot more flexible than
> > technical ones and generally have a much lower overhead.
> >
> > Mark
> >
> >>
> >> [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed
> >
> >
>
>
Re: Github pull requests
Posted by Mark Thomas <ma...@apache.org>.
On 26/08/2016 17:11, Aleksey Yeschenko wrote:
> Mark, I, for one, will be happy with the level of GitHub integration that Spark has, formal or otherwise.
If Cassandra doesn't already have it, that should be a simple request to
infra.
> As it stands right now, none of the committers/PMC members have any control over Cassandra Github mirror.
>
> Which, among other things, means that we cannot even close the erroneously opened PRs ourselves,
> they just accumulate unless the PR authors is kind enough to close them. That\u2019s really frustrating.
No PMC currently has the ability to directly close PRs on GitHub. This
is one of the things on the infra TODO list that is being looked at. You
can close them via a commit comment that the ASF GitHub tooling picks up.
Mark
>
> --
> AY
>
> On 26 August 2016 at 17:07:29, Mark Thomas (markt@apache.org) wrote:
>
> On 26/08/2016 16:33, Jonathan Ellis wrote:
>> Hi all,
>>
>> Historically we've insisted that people go through the process of creating
>> a Jira issue and attaching a patch or linking a branch to demonstrate
>> intent-to-contribute and to make sure we have a unified record of changes
>> in Jira.
>>
>> But I understand that other Apache projects are now recognizing a github
>> pull request as intent-to-contribute [1] and some are even making github
>> the official repo, with an Apache mirror, rather than the other way
>> around. (Maybe this is required to accept pull requests, I am not sure.)
>>
>> Should we revisit our policy here?
>
> At the moment, the ASF Git repo is always the master, with GitHub as a
> mirror. That allows push requests to be made via GitHub.
>
> Infra is exploring options for giving PMCs greater control over GitHub
> config (including allowing GitHub to be the master with a golden copy
> held at the ASF) but that is a work in progress.
>
> As far as intent to contribute goes, there does appear to be a trend
> that the newer a project is to the ASF, the more formal the project
> makes process around recording intent to contribute. (The same can be
> said for other processes as well like Jira config.)
>
> It is worth noting that all the ASF requires is that there is an intent
> to contribute. Anything that can be reasonably read that way is fine.
> Many PMCs happily accept patches sent to the dev list (although they may
> ask them to be attached to issues more so they don't get forgotten than
> anything else). Pull requests are certainly acceptable.
>
> My personal recommendation is don't put more formal process in place
> than you actually need. Social controls are a lot more flexible than
> technical ones and generally have a much lower overhead.
>
> Mark
>
>>
>> [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed
>
>
Re: Github pull requests
Posted by Jeff Beck <be...@gmail.com>.
I would love to be able to send PRs, there have a been a few minor
improvements I wanted to submit that are sitting in local branches for me
for when I have time to really learn how to submit a patch where PRs are
much more approachable now.
Jeff
On Fri, Aug 26, 2016 at 11:11 AM Aleksey Yeschenko <al...@apache.org>
wrote:
> Mark, I, for one, will be happy with the level of GitHub integration that
> Spark has, formal or otherwise.
>
> As it stands right now, none of the committers/PMC members have any
> control over Cassandra Github mirror.
>
> Which, among other things, means that we cannot even close the erroneously
> opened PRs ourselves,
> they just accumulate unless the PR authors is kind enough to close them.
> That’s really frustrating.
>
> --
> AY
>
> On 26 August 2016 at 17:07:29, Mark Thomas (markt@apache.org) wrote:
>
> On 26/08/2016 16:33, Jonathan Ellis wrote:
> > Hi all,
> >
> > Historically we've insisted that people go through the process of
> creating
> > a Jira issue and attaching a patch or linking a branch to demonstrate
> > intent-to-contribute and to make sure we have a unified record of changes
> > in Jira.
> >
> > But I understand that other Apache projects are now recognizing a github
> > pull request as intent-to-contribute [1] and some are even making github
> > the official repo, with an Apache mirror, rather than the other way
> > around. (Maybe this is required to accept pull requests, I am not sure.)
> >
> > Should we revisit our policy here?
>
> At the moment, the ASF Git repo is always the master, with GitHub as a
> mirror. That allows push requests to be made via GitHub.
>
> Infra is exploring options for giving PMCs greater control over GitHub
> config (including allowing GitHub to be the master with a golden copy
> held at the ASF) but that is a work in progress.
>
> As far as intent to contribute goes, there does appear to be a trend
> that the newer a project is to the ASF, the more formal the project
> makes process around recording intent to contribute. (The same can be
> said for other processes as well like Jira config.)
>
> It is worth noting that all the ASF requires is that there is an intent
> to contribute. Anything that can be reasonably read that way is fine.
> Many PMCs happily accept patches sent to the dev list (although they may
> ask them to be attached to issues more so they don't get forgotten than
> anything else). Pull requests are certainly acceptable.
>
> My personal recommendation is don't put more formal process in place
> than you actually need. Social controls are a lot more flexible than
> technical ones and generally have a much lower overhead.
>
> Mark
>
> >
> > [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed
>
>
Re: Github pull requests
Posted by Aleksey Yeschenko <al...@apache.org>.
Mark, I, for one, will be happy with the level of GitHub integration that Spark has, formal or otherwise.
As it stands right now, none of the committers/PMC members have any control over Cassandra Github mirror.
Which, among other things, means that we cannot even close the erroneously opened PRs ourselves,
they just accumulate unless the PR authors is kind enough to close them. That’s really frustrating.
--
AY
On 26 August 2016 at 17:07:29, Mark Thomas (markt@apache.org) wrote:
On 26/08/2016 16:33, Jonathan Ellis wrote:
> Hi all,
>
> Historically we've insisted that people go through the process of creating
> a Jira issue and attaching a patch or linking a branch to demonstrate
> intent-to-contribute and to make sure we have a unified record of changes
> in Jira.
>
> But I understand that other Apache projects are now recognizing a github
> pull request as intent-to-contribute [1] and some are even making github
> the official repo, with an Apache mirror, rather than the other way
> around. (Maybe this is required to accept pull requests, I am not sure.)
>
> Should we revisit our policy here?
At the moment, the ASF Git repo is always the master, with GitHub as a
mirror. That allows push requests to be made via GitHub.
Infra is exploring options for giving PMCs greater control over GitHub
config (including allowing GitHub to be the master with a golden copy
held at the ASF) but that is a work in progress.
As far as intent to contribute goes, there does appear to be a trend
that the newer a project is to the ASF, the more formal the project
makes process around recording intent to contribute. (The same can be
said for other processes as well like Jira config.)
It is worth noting that all the ASF requires is that there is an intent
to contribute. Anything that can be reasonably read that way is fine.
Many PMCs happily accept patches sent to the dev list (although they may
ask them to be attached to issues more so they don't get forgotten than
anything else). Pull requests are certainly acceptable.
My personal recommendation is don't put more formal process in place
than you actually need. Social controls are a lot more flexible than
technical ones and generally have a much lower overhead.
Mark
>
> [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed
Re: Github pull requests
Posted by Mark Thomas <ma...@apache.org>.
On 26/08/2016 16:33, Jonathan Ellis wrote:
> Hi all,
>
> Historically we've insisted that people go through the process of creating
> a Jira issue and attaching a patch or linking a branch to demonstrate
> intent-to-contribute and to make sure we have a unified record of changes
> in Jira.
>
> But I understand that other Apache projects are now recognizing a github
> pull request as intent-to-contribute [1] and some are even making github
> the official repo, with an Apache mirror, rather than the other way
> around. (Maybe this is required to accept pull requests, I am not sure.)
>
> Should we revisit our policy here?
At the moment, the ASF Git repo is always the master, with GitHub as a
mirror. That allows push requests to be made via GitHub.
Infra is exploring options for giving PMCs greater control over GitHub
config (including allowing GitHub to be the master with a golden copy
held at the ASF) but that is a work in progress.
As far as intent to contribute goes, there does appear to be a trend
that the newer a project is to the ASF, the more formal the project
makes process around recording intent to contribute. (The same can be
said for other processes as well like Jira config.)
It is worth noting that all the ASF requires is that there is an intent
to contribute. Anything that can be reasonably read that way is fine.
Many PMCs happily accept patches sent to the dev list (although they may
ask them to be attached to issues more so they don't get forgotten than
anything else). Pull requests are certainly acceptable.
My personal recommendation is don't put more formal process in place
than you actually need. Social controls are a lot more flexible than
technical ones and generally have a much lower overhead.
Mark
>
> [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed