mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Olivier <cjolivie...@gmail.com>
Subject Re: [VOTE] tracking code changes with JIRA by associating pull requests
Date Sun, 25 Feb 2018 17:30:27 GMT
+1


On Fri, Feb 23, 2018 at 9:56 AM Marco de Abreu <marco.g.abreu@googlemail.com>
wrote:

> 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,
> Marco
>
> Am 23.02.2018 6:07 nachm. schrieb "CodingCat" <codingcat@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
>
> Best,
>
> Nan
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message