Hi, Marco,

Thanks for the questions

> "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.

For this I would still prefer keep it as a case without a JIRA (though not
a tiny fix), the hotfix here actually refers to the process of "identify
which commit broke the build, revert the commit". After the hotfix, we
should "reopen the JIRA associated with the commit, and let the original
author resume the work on that"

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

the general idea is that:

non-committers:

* create/modify/close their own JIRAs,

* link JIRAs, etc.

committers:

* create/modify/close all JIRAs,

* assign JIRA to someone (note, this action should be done when a PR is
available, otherwise, anyone can work on this JIRA)

* set target version of JIRA (i.e. committers should plan the dev work),
this action can be performed before/after PR is merged

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

Yes, that's also my understanding

> 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"

my concern is that potential bottleneck on more experienced people, we
would encourage the new devs follow the management strategy of the
community from their first day, and getting familiar with Apache's JIRA can
be part of it.

I think "please create a ticket" might be painful in the first few weeks as
people always needs to get used to something new.

I would suggest all committers collaborate together to ensure that the idea
(if it is good) can be accepted in the community-wide and realized as fast
as possible

Your thoughts?

Best,

Nan



On Fri, Feb 23, 2018 at 9:56 AM, Marco de Abreu <
marco.g.ab...@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" <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
>
> Best,
>
> Nan
>

Reply via email to