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 >>> >>>
