Re: Proposal: github pull requests for all code changes

2017-12-20 Thread Jeff Jirsa

Inline

-- 
Jeff Jirsa


> On Dec 20, 2017, at 8:38 PM, kurt greaves  wrote:
> 
> It would definitely be nice if PR's were made against the actual repo.
> Makes commenting/reviewing code a lot easier. I'd say as long as PR's are
> kept permanently (after closing) so we can go back and look over
> comments/patches would be a big plus. Not a fan of going through JIRA
> tickets and finding the linked branches have been deleted.

Same 

> 
> However not sure about having different identifiers/labels everywhere.
> Considering we'll still be creating JIRA tickets it makes sense to me to
> use JIRA for labelling/categorisation, and github simply for reviewing
> code. Don't really want to go assigning JIRA tickets then have to repeat
> the proceduce for github and make sure all labels align.
> 
> Also, if we're adding "closes #123" to commit messages that implies we'll
> have "patch by y, reviewed by x for CASSANDRA- closes #123"?

Yes, and we’re already doing that 
https://github.com/apache/cassandra/commit/db81f6bffef1a8215fec28bb0522dc9684870627

> I don't
> know if there is a way to do it (doubtful), but it'd certainly be nice if
> JIRA ticket numbers aligned with PR numbers.

Not possible as far as I know 


> 
>> On 21 December 2017 at 02:56, mck  wrote:
>> 
>> 
>>> There's also no way for us to label, assign or otherwise use PR related
>>> features, so I'm really wondering why it would make sense to more
>>> heavily using them.
>> 
>> 
>> Apache does now offer the GitBox service. This makes the github repository
>> writable. The asf and github repos are kept in sync, rather than one being
>> a mirror of the other.
>> 
>> I'm not entirely sure this would be the right move for C*, given that
>> patches and branches are merged in a manner that GitHub pull requests don't
>> do (unless you're only committing to trunk). But it would mean PRs can be
>> closed otherwise by any of the committers, and to use the reviewers,
>> assignees, labels, projects and milestone fields.
>> 
>> Mick.
>> 
>> 
>> ref:
>> - http://apache-nifi.1125220.n5.nabble.com/DISCUSS-Apache-
>> Gitbox-td18273.html
>> - https://s3.amazonaws.com/files-dist/AnnualReports/
>> FY2017-ASF-AnnualReport-FINAL.pdf
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 


Re: Proposal: github pull requests for all code changes

2017-12-20 Thread kurt greaves
It would definitely be nice if PR's were made against the actual repo.
Makes commenting/reviewing code a lot easier. I'd say as long as PR's are
kept permanently (after closing) so we can go back and look over
comments/patches would be a big plus. Not a fan of going through JIRA
tickets and finding the linked branches have been deleted.

However not sure about having different identifiers/labels everywhere.
Considering we'll still be creating JIRA tickets it makes sense to me to
use JIRA for labelling/categorisation, and github simply for reviewing
code. Don't really want to go assigning JIRA tickets then have to repeat
the proceduce for github and make sure all labels align.

Also, if we're adding "closes #123" to commit messages that implies we'll
have "patch by y, reviewed by x for CASSANDRA- closes #123"? I don't
know if there is a way to do it (doubtful), but it'd certainly be nice if
JIRA ticket numbers aligned with PR numbers.

On 21 December 2017 at 02:56, mck  wrote:

>
> > There's also no way for us to label, assign or otherwise use PR related
> > features, so I'm really wondering why it would make sense to more
> > heavily using them.
>
>
> Apache does now offer the GitBox service. This makes the github repository
> writable. The asf and github repos are kept in sync, rather than one being
> a mirror of the other.
>
> I'm not entirely sure this would be the right move for C*, given that
> patches and branches are merged in a manner that GitHub pull requests don't
> do (unless you're only committing to trunk). But it would mean PRs can be
> closed otherwise by any of the committers, and to use the reviewers,
> assignees, labels, projects and milestone fields.
>
> Mick.
>
>
> ref:
>  - http://apache-nifi.1125220.n5.nabble.com/DISCUSS-Apache-
> Gitbox-td18273.html
>  - https://s3.amazonaws.com/files-dist/AnnualReports/
> FY2017-ASF-AnnualReport-FINAL.pdf
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: Proposal: github pull requests for all code changes

2017-12-20 Thread mck

> There's also no way for us to label, assign or otherwise use PR related
> features, so I'm really wondering why it would make sense to more
> heavily using them.


Apache does now offer the GitBox service. This makes the github repository 
writable. The asf and github repos are kept in sync, rather than one being a 
mirror of the other.

I'm not entirely sure this would be the right move for C*, given that patches 
and branches are merged in a manner that GitHub pull requests don't do (unless 
you're only committing to trunk). But it would mean PRs can be closed otherwise 
by any of the committers, and to use the reviewers, assignees, labels, projects 
and milestone fields.

Mick.


ref:
 - http://apache-nifi.1125220.n5.nabble.com/DISCUSS-Apache-Gitbox-td18273.html
 - 
https://s3.amazonaws.com/files-dist/AnnualReports/FY2017-ASF-AnnualReport-FINAL.pdf
 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Proposal: github pull requests for all code changes

2017-12-12 Thread Stefan Podkowinski
There's nothing that stops people from using github to discuss code
changes. Many jiras already link to gh branches that can be used to
review and comment code. But it's not always the best place to do so.

The high level discussion should always take place on Jira. Although I'd
have no problem to see in-depth code reviewing happening on gh, I'd hate
to see significant parts of the discussion as a whole spread across Jira
and different PRs related to the ticket.

The missing gh integration with Jira and lack of administrative
permissions is another problem. If we close a Jira ticket, the
corresponding PRs will still stay open. We either have to ask the
contributor to close it or have an ever growing number of open PRs.
There's also no way for us to label, assign or otherwise use PR related
features, so I'm really wondering why it would make sense to more
heavily using them.


On 12.12.2017 09:02, Marcus Eriksson wrote:
> To be able to use the github code review UI and closer CI integration we
> should make it obligatory to submit github pull requests for all code
> changes.
> 
> The process would be:
> 1. Create or find a JIRA ticket
> 2. Submit GH pull request
>  - one PR per branch (one for 3.0, one for 3.11 etc)
>  - the PR title should mention the JIRA ticket so that the PR gets
> linked on the JIRA
> 3. Have it reviewed and approved on GH
> 4. Committer needs to do the manual work of getting the code committed to
> the apache repo like today
>- having "closes #123" in the commit message closes the pull request.
> Adding the same line to the merge commit messages should close the PRs for
> the different branches
> 
> Apache Spark does something similar and their guidelines are here:
> https://spark.apache.org/contributing.html
> 
> Anyone got any concerns or improvement suggestions to this?
> 
> /Marcus
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Proposal: github pull requests for all code changes

2017-12-12 Thread Marcus Eriksson
To be able to use the github code review UI and closer CI integration we
should make it obligatory to submit github pull requests for all code
changes.

The process would be:
1. Create or find a JIRA ticket
2. Submit GH pull request
 - one PR per branch (one for 3.0, one for 3.11 etc)
 - the PR title should mention the JIRA ticket so that the PR gets
linked on the JIRA
3. Have it reviewed and approved on GH
4. Committer needs to do the manual work of getting the code committed to
the apache repo like today
   - having "closes #123" in the commit message closes the pull request.
Adding the same line to the merge commit messages should close the PRs for
the different branches

Apache Spark does something similar and their guidelines are here:
https://spark.apache.org/contributing.html

Anyone got any concerns or improvement suggestions to this?

/Marcus