mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From pracheer gupta <pracheer_gu...@hotmail.com>
Subject Retrospective: MXNet release process
Date Sat, 16 Sep 2017 00:45:31 GMT
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

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