Re: Proposal: github pull requests for all code changes
Inline -- Jeff Jirsa > On Dec 20, 2017, at 8:38 PM, kurt greaveswrote: > > 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
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, mckwrote: > > > 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
> 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
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
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