I'd like to suggest the following in order to get a first release out quickly:
1. Tackle whatever CVE type overhead we have with dependencies, etc as a first order of business 2. Move all outstanding JIRAs and PRs out to the next release and only those with representatives that are willing to pull them in and make sure they work in the resulting line be targeted for this release 3. concentrate on the release process itself Thoughts? On Mon, Oct 31, 2022 at 1:26 PM larry mccay <lmc...@apache.org> wrote: > 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 >> >>
