+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
+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,
+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
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
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
+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
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`.
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
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
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,
>
>
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
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
12 matches
Mail list logo