Re: [Discussion] Branch Usage and Release Versioning

[Bhavin Thaker]

Hi Sheng,

+1 to  proposals 1, 2, 4 and 5.

Proposal 3, while ideal, seems less practical because it needs significant
time-effort to maintain code changes across multiple branches and test them
to do periodic releases.

Our todo list is huge in terms of getting tests fixed, PR reviews backlog
getting cleared, having more test cases, etc, etc. I do NOT foresee a
practical way to maintain multiple branches. I propose to maintain only the
latest branch and do releases from the master branch only — at least fit
the short term — and revisit this proposal in future when things are more
smoother.

In short, your proposal #3 is good and ideal but seems less practical based
on my observations so far.

Bhavin Thaker.

On Thu, Jan 18, 2018 at 12:58 AM Marco de Abreu <
marco.g.ab...@googlemail.com> wrote:

> Hi Sheng,
>
> very good suggestions! How long do we plan to support old versions?
>
> While the structure of our CI-setup for Ubuntu-based tasks allows proper
> versioning because the entire behaviour is defined in the tests/ci-build
> repository, this is currently not the case for the Windows-tasks. While we
> plan to redesign the entire Windows-slave soon, we're currently in a state
> which does not allow versioning. Reason being here that the old
> Windows-slave setup, which we had no chance to redesign yet, uses a lot of
> scripts and binaries stored on the Windows-slave itself. Just to give some
> examples of what's stored on the slave and not managed within GitHub:
> - build_vc14_*.bat: Defines build behaviour for msbuild
> - test_cpu/gpu.bat: Defines test behaviour for python
> - Libraries: Precompiled binaries like Openblas, OpenCV and cudnn
> In case an update on the master requires upgrading a library or changing
> one of the scripts, all other builds would break. It's definitely part of
> the Windows-slave-revamp to have the entire behaviour defined inside the
> Jenkinsfile and tests/ci-build.
>
> I totally agree that we should also run protected mode on version-branches,
> but I'm afraid that the CI is not in a state to support this at the moment.
>
> Best regards,
> Marco
>
>
> On Wed, Jan 17, 2018 at 8:01 PM, Sheng Zha  wrote:
>
> > Dear community members,
> >
> > Now that we're preparing a new release under the 1.0 version, I'd like to
> > propose that we discuss, clarify, and decide how we use versions and
> > branches.
> >
> > Current practice is:
> > 1. we use master branch for development.
> > 2. we fork from master branch and create release branch for specific
> > versions, such as 1.0.0
> > 3. no formal process for bug fixes on those release branches after
> release
> > 4. not agreed on using Semantic Versioning for deciding version number:
> > https://semver.org/ (though technically not breaking it either, because
> we
> > only had one release for 1.0 so far, which defines the promised set of
> > public APIs)
> >
> > I propose the following changes:
> > 1. we continue to use master branch for development (not really a change,
> > duh)
> > 2. we create release branches for minor versions, such as 1.0.x, 1.1.x,
> and
> > release from the head of those branches with version numbers according to
> > semantic versioning.
> > 3. we regularly apply relevant bug fixes to release branches and provide
> > maintenance releases.
> > 4. we use the same protected branch and CI features to protect our
> release
> > branches (i.e. PR-only, tested at every step)
> > 5. we promise the practice of semantic versioning to users.
> >
> > Note that in order to be able to perform proposed item 3, we need clarity
> > on whether a PR introduces a new API, and record the version in which it
> > was released. Note that this applies to new argument to existing API, and
> > new semantic meaning of existing APIs and arguments. This way, we know
> > which bug fixes are relevant to which versions.
> >
> > Your thoughts and suggestions are welcome. Thank you for your time.
> >
> > -sz
> >
>

Please Help Fix MXNet Licensing Issues for the next Release!

[Meghna Baijal]

Hello All!

I am currently attempting to fix the licensing issues in MXNet. These are
being tracked in this wiki -

*https://cwiki.apache.org/confluence/display/MXNET/MXNet+Source+Licenses
*

You can follow the links in this wiki to find the following details -
1. Links to relevant email threads which point the license issues out.
2. Links to Github Issues created based on these emails.
3. Apache pages which details the licensing policies.
4. *The PRs created to fix these issues.* (These need review and all help
is welcome!)
5. A table to track the high level issues and their progress.
6. And a list of open *issues/questions/doubts/concerns* that need some
answers.

I would appreciate any comments/ feedback/ suggestions from the community
regarding this work and it would be particularly helpful if you could help
review and validate the PRs and other planned changes.

This is still a work in progress and there are a few files/folders that are
currently excluded from the Apache RAT checks. Also, there are around 30
files that are still failing Apache RAT check (both lists are in the wiki).
If you know how to fix any of these remaining issues, please let me know or
even better create a PR!

Do let me know if I can provide more details on any of the points.

Thanks,
Meghna Baijal

Request for comments: Proposal for import/export model formats module into MXNet

[Roshani Nagmote]

Hello all,

I have written an initial design proposal for a `serde`(temporary name)
module for importing and exporting different model formats like onnx,
coreml to and from MXNet.

Please take a look and feel free to provide suggestions in the comment
section.

https://cwiki.apache.org/confluence/display/MXNET/Proposal%3A+ImportExport+module

Note: I will be traveling next week with limited access to emails. So,
responses might be delayed.

Thanks,
Roshani