Thank you for raising the point, Luca and Tiago. > Maybe we could try and define high-level “must-haves” for each of the next > releases,
As an input for the discussion, checking https://issues.apache.org/jira/browse/LEGAL-469 for the license issues in the EPIC https://github.com/apache/incubator-kie-issues/issues/1707 : === * EMF License Compliance: Addressing EPL Licensed in Codebase #1709 -> Minor (Includes Category B source code) * Replace/Remove MPL 2.0 Licensed search-ui.js from drools-docs #1710 -> Minor (Includes Category B source code) * Remove Minified JavaScript/CSS Files from Source Code Release #1711 -> Not defined ( https://lists.apache.org/thread/wb574kpwmgvxh9pt7jw38g0qt4vnbct1 : "Minified code should, if possible, be kept out of a source release.") * Remove Open Font Licensed Files from Source Code Release #1712 -> Minor (Includes Category B source code) * review use of hibernate jar #1685 -> Minor (Has Category X dependencies) * Test cases in kogito repos GHA fail with "pull access denied for vectorized/redpanda" #1682 (remove redpanda depedency) -> Not an issue (https://issues.apache.org/jira/browse/LEGAL-693 : "it is optional") === "Minor Issue" are described as "Release, then add to DISCLAIMER-WIP and file a JIRA to fix before graduation". So they are not "must-haves" for 10.1. Of course, it's better to begin tackling them anyway, because they may require a long time. Toshiya On Fri, Dec 20, 2024 at 11:51 PM Tiago Bento <[email protected]> wrote: > Luca, > > I don’t think we want to tie our next release to the graduation, as we > might want to release incremental improvements to our > builds/pipelines/processes first… > > I’m not exactly sure how the graduation process works, but if I were to > guess I think having a well rounded release process is kind of a > requirement, showing the IPMC and the community we can maintain a good > pace. > > With the thread Toshyia started about documentation/websites I believe > those two areas should be the focus for a 10.1.0 release, then one or two > more minor releases with nice release notes, migration guides etc I think > would put ourselves in a good place for becoming a TLP, provided, of > course, we solve all legal issues too. > > Having said that, we currently don’t have a place/strategy to scope a next > release, and we’re mostly just “moving forward”. I’m not sure what’s the > best way to do that, though, but probably via labels in the issues > themselves? Maintaining a GitHub board has proven to be very challenging in > my experience, especially in a de-centralized “work environment” such as > the one we currently have. > > Maybe we could try and define high-level “must-haves” for each of the next > releases, while we keep the rest of contributions free flowing not to limit > our experimentation and innovation nature. This would reduce the “project > management” work as we wouldn’t be mapping the entire scope of a release > before-hand, while also having meaningful goals set for each release we do. > > On Fri, Dec 20, 2024 at 11:17 AM Luca Molteni <[email protected]> wrote: > > > > > > > > On 12 Dec 2024, at 23:17, Alex Porcelli <[email protected]> wrote: > > > > > > Now that we have completed our first Apache release, I'd like to start > > > a discussion about our path to graduation. We have identified several > > > compliance issues that need to be addressed before we can request a > > > Top Level Project (TLP) graduation. > > > > > > Will graduation be included in the next release? > > > > If not, is there a place where we are tracking the specific tasks > required > > for the immediate next release? > > > > Thank you > > > > Luca >
