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
