agree on the steps, but we need to fix the travis CI first, I have put a fix on it, https://github.com/apache/incubator-livy/pull/362
larry mccay <lmc...@apache.org> 于2022年11月6日周日 02:03写道： > I've run a dependency check on the project and identified that there are a > decent number of CVEs reported. > You can run the same with the following from OWASP dependency-check-maven > > mvn org.owasp:dependency-check-maven:7.3.0:aggregate > > There are a few that have existing JIRAs but with obsolete target versions. > I think that we should file new ones and resolve the outstanding but > obsolete ones as "Won't Fix" or something along those lines. > > I also think that we should start identifying the Target Version for a > JIRA so that we know which are outstanding for the next release so that we > don't block the current release or lose track of those being pushed out to > 0.9.0. > > Additionally, it seems that we need to add new community members to the > JIRA project in order to start executing on this, including myself. > I can't set Target Version or move anything out until I have access. > > @jbono...@apache.org <jbono...@apache.org> - can you help here? Maybe just > add me for now? > > > On Fri, Nov 4, 2022 at 12:37 PM larry mccay <lmc...@apache.org> wrote: > > > 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 > >>> > >>> >
