Hi Alex - Thanks for those insights!
--larry On Mon, Oct 31, 2022 at 12:25 PM Alex Bozarth <ajboz...@us.ibm.com> wrote: > On the release process, iirc you just need to use the build-release.sh > script in the dev directory of the repo. I do remember have some issues > with it the last time I did a release, but I don’t remember what they were > or how I addressed them after so many years. That release script was copied > from the Spark release script as it was at the time Livy was started, so > their community may be able to help. > > As for dev documentation, there never really was any other than the > README. Afaik all our docs are targeted at users, not devs. > > > Alex Bozarth > Jupyter Architect, IBM CODAIT > GitHub: ajbozarth > > On 10/31/22, 9:45 AM, "larry mccay" <lmc...@apache.org> wrote: > > All - > > I think we should discuss first steps to reviving this project in the > context of a release. > There are numerous forks with features that we are looking to get into > the > revived project but I would suggest that we target an initial release > of > what is already there to ensure that we have the process down and can > address any security issues and document the changes in 0.8.0. > > There are a couple things that I think we could address in this first > step: > > 1. I can't seem to find any Process docs on the site for doing an > actual > release. This needs to be documented, if not for doing the release > then as > an artifact of doing this next release. While we are at it, I believe > that > the site is also missing instructions for getting started as a > developer on > the project. Adding such docs may help get new contributors engaged. I > had > to make a minor change (after hours of googling py-test build > problems) to > the python-api/setup.py script in order for it to build. Likely just a > me > problem. > 2. CVE and dependency hygiene related tasks to make sure there is a > clean > version available to start from. This may require some github or other > magic for determining problem dependencies that should be put in place > and/or documented. > 3. Delta between 0.7.0 and 0.8.0 release in terms of provided features, > bugs and improvements. > > In parallel we can discuss the various changes and how to roll them > into > future releases rather than trying to boil the ocean all at once. A > separate DISCUSS thread can be started to do an inventory of proposed > features and improvements that will require one-pager wikis (LIPs) to > describe the problem statement, usecases, approach. We will undoubtedly > need to reconcile multiple implementations of some things by either > convergence or optional pluggable implementations. > > Does anyone have enough context for the release process in order to be > Release Manager for 0.8.0? > > Any other thoughts? > > Thanks! > > --larry > >
