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 Lebr
>> 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
g
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
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 wrote:
>
> Don't we need something on the infra side to turn a merged pull request
> into a co
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
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
wrote:
> >
> >
> > Infra is exploring options for giving PMCs greater control over GitHub
> > config (including allowing GitHub to be the master wi
>
>
> 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
>
>
> 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.
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 wrote:
> +1
>
> Gith
+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 wrote:
> Jake could you show an example issue and how the pipeline works?
>
> On Fri, Aug 26, 2016 at 12:03 PM, Jake Fa
@Jeremiah, makes sense to send to commits@
On Fri, Aug 26, 2016 at 12:55 PM, Jeremiah D Jordan <
jeremiah.jor...@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,
+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 wrote:
>
> +1 to GitHub PRs, I think it will make things easier.
>
> El viernes, 26 de agosto de 2016,
+1 to GitHub PRs, I think it will make things easier.
El viernes, 26 de agosto de 2016, Jason Brown
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 > wrote:
>
> > It seems to me we might get more cont
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 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 abo
+1 to officially supporting GitHub PRs.
On Fri, Aug 26, 2016 at 11:07 AM Jason Brown 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, A
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 wrote:
> On 26/08/2016 17:11, Aleksey Yeschenko wrote:
> > Mark, I,
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
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/
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 Lucia
Jake could you show an example issue and how the pipeline works?
On Fri, Aug 26, 2016 at 12:03 PM, Jake Farrell 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 patc
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
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
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.
>
> Bu
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
wrote:
> I think it would certainly make contributing to Cassandra more
> strai
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
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
26 matches
Mail list logo
