Hello Nan,

Good suggestion!

"hotfix which brings the broken build back to track" nitpicking, but I
wouldn't consider this a tiny fix. There should also be a jira that
reported the build being broken, so that shouldn't be a problem to link.

Very good idea with the automated script!

How would we handle permissions? Which actions are non-committers able to
execute and in which cases would a committer be required?

How would we treat GitHub issues in future? As a board for users to ask
usage questions?

In order to improve user experience for new developers, I'd like to suggest
that more experienced people might create jira tickets on behalf of others
instead of telling them "please create a ticket". I think we all made the
experience with people from it department who blocked every request until a
ticket was created and assigned :P

Best regards,

Am 23.02.2018 6:07 nachm. schrieb "CodingCat" <coding...@apache.org>:

Hi, all

To make the changes in code base more trackable,

I would propose to link each PR with the a JIRA from now on:

1. most of PRs should be titled as [MXNET-???][MODULE_NAME] PR short
description, where MXNET-??? is the JIRA ID, MODULE_NAME can be python,
scala, symbol, etc.

2. only the very tiny fix, e.g. fix a typo, remove some unused variables,
or the hotfix which brings the broken build back to track, can be filed
without JIRA ID in title,

In JIRA side, to link the issue with an arrived PR, we can run a script
like https://github.com/apache/spark/blob/master/dev/github_jira_sync.py to
update JIRA status (can be run in Jenkins)

The benefits of applying such a flow include (but not limited to)

1. facilitate the release process:

e.g., as long as tagging each JIRA with the correct affected version and
fixed version, the release manager can quickly identify what are the
changes applied in this version; or we can quickly identify whether there
is any blocker issue in the JIRA

2. trackable changes

any changes in MXNET can be quickly searched through JIRA or even through
Google (JIRA looks like did something makes it more indexable by Google),

If the vote gets pass,  the plan in the near horizon includes

1. update JIRA with the modules names

2. write runbook for release manager/committer for releasing new
version/merging patches, as well as contributors about the usage of JIRA

3. push the changes to the existing and coming PRs (this also needs the
collaboration across the whole committer team)

The vote will end at 12:00 p.m. of March 2nd, 2018



Reply via email to