You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mxnet.apache.org by pracheer gupta <pr...@hotmail.com> on 2017/09/16 00:45:31 UTC
Retrospective: MXNet release process
Hi dev@,
As you are aware MXNet recently had its first release under the Apache banner.
As a first-time release, there was a lot of learning for all of us involved. Keeping that in mind, I wanted to reach out to the community to understand what aspects of the release process should be improved for the future releases (or maybe even the things that we did well).
(I will capture it in the wiki<https://cwiki.apache.org/confluence/display/MXNET/Release+Process> as guidelines for posterity)
Here are the few things that I thought could be improved:
1. Voting for the release: Does a +1 voter need to test, at least, all the new major features before giving her vote? Does it make sense for every +1 voter to call out why she thinks so (i.e. what is it that she tested successfully that made her feel that RC is ready for prime time)? This may help the community feel more confident about the RC.
2. Bigger/clearer heads up on the deadline to all the contributors pushing their code changes to make it into the RC. 2 weeks advance notice may be?
3. Something that wasn't very obvious (please correct me if I'm wrong): Did we do an end-to-end testing (distributed training on a cluster and run inferences) on some big model to ensure our performance hasn't degraded since our previous release (or degraded due to some last minute change we made). Or are the tests that are running as part of Jenkins infrastructure good enough?
What are the other things we should improve on?
Note that, adding some knobs and refining the process shouldn’t come at cost of faster releases. This is just meant to provide some ideas that will help improve the quality of MXNet while making the release process cleaner and overall community effort more efficient.
Let me know what you think.
-Pracheer
Re: Retrospective: MXNet release process
Posted by Naveen Swamy <mn...@gmail.com>.
its been always on apache.org
https://dist.apache.org/repos/dist/release/incubator/mxnet/.
When a new tag(0.11.0) is created, GitHub automatically creates a release
for it.
On Sun, Sep 17, 2017 at 11:23 PM, Seb Kiureghian <se...@gmail.com> wrote:
> In addition to your points, releases should be on apache.org and its
> mirror
> network. Not on github.com.
>
> On Fri, Sep 15, 2017 at 5:45 PM, pracheer gupta <
> pracheer_gupta@hotmail.com>
> wrote:
>
> > Hi dev@,
> >
> > As you are aware MXNet recently had its first release under the Apache
> > banner.
> >
> >
> > As a first-time release, there was a lot of learning for all of us
> > involved. Keeping that in mind, I wanted to reach out to the community to
> > understand what aspects of the release process should be improved for the
> > future releases (or maybe even the things that we did well).
> >
> > (I will capture it in the wiki<https://cwiki.apache.org/
> > confluence/display/MXNET/Release+Process> as guidelines for posterity)
> >
> >
> > Here are the few things that I thought could be improved:
> >
> > 1. Voting for the release: Does a +1 voter need to test, at least, all
> > the new major features before giving her vote? Does it make sense for
> every
> > +1 voter to call out why she thinks so (i.e. what is it that she tested
> > successfully that made her feel that RC is ready for prime time)? This
> may
> > help the community feel more confident about the RC.
> > 2. Bigger/clearer heads up on the deadline to all the contributors
> > pushing their code changes to make it into the RC. 2 weeks advance notice
> > may be?
> >
> > 3. Something that wasn't very obvious (please correct me if I'm
> wrong):
> > Did we do an end-to-end testing (distributed training on a cluster and
> run
> > inferences) on some big model to ensure our performance hasn't degraded
> > since our previous release (or degraded due to some last minute change we
> > made). Or are the tests that are running as part of Jenkins
> infrastructure
> > good enough?
> >
> >
> > What are the other things we should improve on?
> >
> >
> >
> > Note that, adding some knobs and refining the process shouldn’t come at
> > cost of faster releases. This is just meant to provide some ideas that
> will
> > help improve the quality of MXNet while making the release process
> cleaner
> > and overall community effort more efficient.
> >
> >
> >
> > Let me know what you think.
> >
> > -Pracheer
> >
>
Re: Retrospective: MXNet release process
Posted by Seb Kiureghian <se...@gmail.com>.
In addition to your points, releases should be on apache.org and its mirror
network. Not on github.com.
On Fri, Sep 15, 2017 at 5:45 PM, pracheer gupta <pr...@hotmail.com>
wrote:
> Hi dev@,
>
> As you are aware MXNet recently had its first release under the Apache
> banner.
>
>
> As a first-time release, there was a lot of learning for all of us
> involved. Keeping that in mind, I wanted to reach out to the community to
> understand what aspects of the release process should be improved for the
> future releases (or maybe even the things that we did well).
>
> (I will capture it in the wiki<https://cwiki.apache.org/
> confluence/display/MXNET/Release+Process> as guidelines for posterity)
>
>
> Here are the few things that I thought could be improved:
>
> 1. Voting for the release: Does a +1 voter need to test, at least, all
> the new major features before giving her vote? Does it make sense for every
> +1 voter to call out why she thinks so (i.e. what is it that she tested
> successfully that made her feel that RC is ready for prime time)? This may
> help the community feel more confident about the RC.
> 2. Bigger/clearer heads up on the deadline to all the contributors
> pushing their code changes to make it into the RC. 2 weeks advance notice
> may be?
>
> 3. Something that wasn't very obvious (please correct me if I'm wrong):
> Did we do an end-to-end testing (distributed training on a cluster and run
> inferences) on some big model to ensure our performance hasn't degraded
> since our previous release (or degraded due to some last minute change we
> made). Or are the tests that are running as part of Jenkins infrastructure
> good enough?
>
>
> What are the other things we should improve on?
>
>
>
> Note that, adding some knobs and refining the process shouldn’t come at
> cost of faster releases. This is just meant to provide some ideas that will
> help improve the quality of MXNet while making the release process cleaner
> and overall community effort more efficient.
>
>
>
> Let me know what you think.
>
> -Pracheer
>