Hi Madhawa - Thanks for the links and suggestion for pending pull requests that should be included as well. At least for engaged representatives of the PRs and others will need to be moved to the next release or backlog.
Release Policy should be pretty clear for everyone here. I was talking about the actual process for releasing a Livy release - for example, you can see the Knox process page [1]. Thanks again! --larry 1. https://cwiki.apache.org/confluence/display/KNOX/Release+Process On Mon, Oct 31, 2022 at 11:40 AM Madhawa Gunasekara <madhaw...@gmail.com> wrote: > Hi Larry, > > Thanks for bringing up this topic. Here you can find the Apache release > policy [1], we should follow the same. > I did find previous releases mentioned on the site [2] [3]. As a > suggestion, we can add a "Download" section to the menu as well, for better > visibility. > > We can try merging pending pull requests as well [4] before the release. > > [1] https://www.apache.org/legal/release-policy.html > [2] https://livy.apache.org/download/ > [3] https://livy.apache.org/history/ > [4] https://github.com/apache/incubator-livy/pulls > > Thanks, > Madhawa > > > On Mon, Oct 31, 2022 at 3:45 PM 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 > > >
