Re: [DISCUSSION] Adding labels to PRs

2018-01-15 Thread Pedro Larroy
+1 Agree with Bhavin, Marco and Sheng. I would also like to point out good commit practices such as, keeping each individual commit small and on-topic, meaning if that you are changing whitespace and a one liner fix, it's better practice to separate those commits. Or having two separate commits

Re: [DISCUSSION] Adding labels to PRs

2018-01-14 Thread Bhavin Thaker
+1 to having committers act as role models for descriptive PR title and descriptions. I am sorry to say this explicitly because I found a few committers to have no descriptions in their PRs with PR titles that seemed vague to me as a contributor of Apache MXNet. Bhavin Thaker. On Sun, Jan 14,

Re: [DISCUSSION] Adding labels to PRs

2018-01-14 Thread Sheng Zha
+1. Also, I think committers should act as role models in this regard, and ensure that our own code changes have sufficient details in the PR. Since I proposed the PR template, I also want to re-state that any suggestions to improving the PR template are welcome. By being open about it, we can

Re: [DISCUSSION] Adding labels to PRs

2018-01-14 Thread Bhavin Thaker
While this email thread had 3 proposals earlier and most comments were on Jira Vs Github issues, I want to bring attention to and request all committers to NOT merge a code change unless the PR title and description has sufficient details as required in the PR template. Both the PR title and the

Re: [DISCUSSION] Adding labels to PRs

2017-11-13 Thread Stephen Bull
As a complete noob here and someone without a JIRA account, it seems I can at least view JIRA issues (so a plus for regular users when it comes to release notes). And when it comes time to start contributing, I don't see having to create a JIRA account to be a big deal, especially if the

Re: [DISCUSSION] Adding labels to PRs

2017-11-13 Thread Bhavin Thaker
+1 for better [1] PR Titles. As suggested by Madan and use by Spark, the current PR template seems to be ignored by folks and so we may want to simplify it to: Q1. What changes were proposed in this pull request? Q2. How was this patch tested? +1 to either [2] Jira OR [3] PR labels. Bhavin

Re: [DISCUSSION] Adding labels to PRs

2017-11-10 Thread Markus Weimer
Option 2 works for us over in REEF. We are a bit (too) religious about it [0], but it creates really nice commit messages[1]. We require each commit message to start with a one line summary which names the JIRA in brackets and describes the change, e.g. `[REEF-1234] Added integration with mxnet`.

Re: [DISCUSSION] Adding labels to PRs

2017-11-10 Thread kellen sunderland
I have a weak preference for option #2, as this option really helps make releases easy, and encourages a well thought-through commit process. However a combo of #1 and #3 would also work well, and is less overhead. Note: probably obvious, but whichever mechanism we choose, let's remember to

Re: [DISCUSSION] Adding labels to PRs

2017-11-09 Thread Marco de Abreu
I think option 1 and 3 would be good in combination. Meaningful titles should always be encouraged and adding a label during the merge process should only be a matter of seconds. I dislike option 2 because introduces an additional step, which also requires creating an account for JIRA, into the

Re: [DISCUSSION] Adding labels to PRs

2017-11-09 Thread Suneel Marthi
When u create a Jira - the jira carries a label of 'New Feature', 'Bug', 'Task' etc..., there's no need to again label each PR individually as long as the Jira### is referenced in the PR. On Fri, Nov 10, 2017 at 4:13 AM, Meghna Baijal wrote: > Hello All, > >

Re: [DISCUSSION] Adding labels to PRs

2017-11-09 Thread madan jampani
I really like (2). Yes it is work to link each PR to a Jira. But it really helps users understand what they are getting. The Jira can contain the necessary context. Spark does this well: https://github.com/apache/spark/commits/master Madan > On Nov 9, 2017, at 2:43 PM, Meghna Baijal

[DISCUSSION] Adding labels to PRs

2017-11-09 Thread Meghna Baijal
Hello All, Currently, there is no process in place to identify the new features that go into every release. All the commits since the previous release are manually parsed to find the important changes that go into the release notes. In order to improve this process, I want to start a