<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 7, 2021 at 11:52 AM Mehdi AMINI <<a href="mailto:joker.eph@gmail.com">joker.eph@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks for working on this Stella! <div><br></div><div>I'm wondering about the versioning: these packages that we'd publish continuously are necessarily "unstable" to some extent. How do we handle the versioning and the alignment with LLVM releases?</div></div></blockquote><div><br></div><div>The way I envision this is that daily/snapshot releases are just at a floating llvm-project head. Currently, automation bumps that head twice per day by committing a new commit hash to the <a href="https://github.com/stellaraccident/mlir-py-release/blob/main/llvm-project.version">llvm-project.version file</a>, allocating a new/unique/monotonic snapshot-YYYYMMDD.NN tag and scheduling the build of a new release at that tag (GitHub releases are 1:1 with a tag). The source revision and tag information is published in the built wheels themselves. I had it set up so that a downstream project that was able to do an "import mlir" could also track back to the installed headers and shared libraries that produced it and could be used to build against it, up to and including its own wheels that depend on the exact version published. I ended up backing that last part out, not because it was a bad idea per se, but because I decided it would be more effective to straighten out the shared library situation first, before letting the current arrangement spider (currently the released mlir wheel only contains enough to build/link against the C API). These snapshot releases are unstable but we do retain them as fixed reference points that are tested/available for close to at-head downstreams to stay current.</div><div><br></div><div>I expect that once these things mature to the point of being ready for inclusion in official, numbered LLVM releases, we would create a branch in this repo for the release, commit the llvm-project.version file to pin it to the upstream release HEAD, and then schedule an "official" release (something like "llvm-12.0rc1.NN" vs the current "snapshot-YYYYMMDD.NN"), build and deploy it to PyPi. Most of that would be completely shared with the snapshot release pipeline, except there would be a different (or even manual) trigger job, and these would be uploaded to PyPi (snapshot releases just accumulate on the GitHub releases page and can be installed directly from there).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Otherwise I'm fine with a new repo for this, in particular since it involves GitHub action and these can't be isolated (in terms of notification and such) other than at the repository boundary.</div><div><br></div><div>For the LLVM releases, would we need to branch in this repo as well?</div></div></blockquote><div><br></div><div>A branch would be needed to capture the commit relationship, and then each actual build would be a tag to a commit on that branch.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Thanks,</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 7, 2021 at 10:56 AM Stella Laurenzo via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi folks, I would like to propose that we create a new top-level repo in the LLVM organization for organizing the Python MLIR Releases (both daily and official numbered releases, whenever we are ready for such a thing) and corresponding pushes to package repositories, etc.<div><br></div><div>I have prototyped such a release process in a personal repo: <a href="https://github.com/stellaraccident/mlir-py-release" target="_blank">https://github.com/stellaraccident/mlir-py-release</a></div><div><br></div><div>Additional development on that release process is currently blocked on more work on the shared library organization in LLVM (discussed here <a href="https://lists.llvm.org/pipermail/llvm-dev/2021-January/147567.html" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2021-January/147567.html</a> and being worked on independently) but it is useful as is and a reasonable starting point for further work.</div><div><br></div><div>I would propose that we just fork my current repo into a new one in the LLVM organization and then take the necessary steps to get credentials/permissions/secrets set up in the new context.</div><div><br></div><div>Some answers to questions that may come up:</div><div><ul><li><b>Why should this be a repo separate from llvm-project? </b>These kind of automation repos tend to have a lot of "garbage" commits that I think is best if they do not pollute the main repo (and also don't face contention on automatic jobs bumping things, etc). They also tend to require special permissions and secrets that we will want to more tightly control. They also make use of other GitHub features that it seems like we would like not polluting the main development flow ("Releases" tab, Actions, etc). Also, this is the kind of thing that tends to get revised en-masse periodically, and again, it would be good to not pollute the monorepo.</li><li><b>Why not land this in llvm-zorg? </b>llvm-zorg claims to be for "LLVM Testing Infrastructure" and seems well scoped to that statement. What I am managing above is periodic, automated release tooling based on open-source CI systems (currently GitHub Actions), which are fairly standardized across the Python releasing community, easy to set up, etc.</li><li><b>What ultimately will the code in this repo do?</b></li><ul><li>Have periodic GitHub actions to select new LLVM revisions and schedule daily/snapshot releases.</li><li>Have manual actions for triggering official, numbered releases.</li><li>Facilities for building Python wheels for PyPi and house any additional metadata/automation needed for anaconda.</li><li>Builds releases for all supported operating systems (currently Linux/CentOS7/manylinux2014, MacOS, and Windows) and supported Python versions (currently 3.6, 3.7, 3.8, 3.9).</li><li>Publish release artifacts on the Releases tab for daily/snapshot releases.</li><li>Provide a stable reference point for downstream projects that extend MLIR-Python and need to produce version-matched artifacts of their own.</li></ul><li><b>Could this graduate to be more than "MLIR" python?</b> Maybe. I chose the name because that is what I am focused on and didn't want to grab too much land. But there is nothing stopping this from becoming automation for general LLVM monorepo+incubator Python releasing.</li><li><b>What if we don't do this?</b></li><ul><li><b>Option A:</b> We keep running this in a private repo with the disclaimer that is currently at the top: "Note that this is a prototype of a real MLIR release process being run by a member of the community. These are not official releases of the LLVM Foundation in any way, and they are likely only going to be useful to people actually working on LLVM/MLIR until we get things productionized." We would miss opportunities for convergence with other projects and would cause things to fragment.</li><li><b>Option B: </b>We only publish Python bindings in official LLVM release packages, and only for the Python version they are built with. We don't release Python binaries through normal package management channels.</li></ul></ul><div>Opinions?</div></div><div>- Stella</div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div></div>