No branch hell please (just same as in core) ;-) If something is done, it should go into the main branch.
Naturally, dependsbot should only target main to avoid noise. > Am 11.09.2026 um 03:45 schrieb Kristian Rickert <[email protected]>: > > https://issues.apache.org/jira/browse/INFRA-28389 > > I sent out the INFRA ticket for addons. I'll set up the CICD once it is > approved and create a PR for it. Nothing will be merged to main without a > PR. > > Does anyone have thoughts on whether these addons should move to the > sandbox or become separate branches? I think they should all go to the > sandbox if no one claims them, since they haven't been touched in a long > time, but creating separate branches for each is also fine with me. > > Some questions to discuss: > > - Repository & Branch Strategy: Sandbox vs. separate branches for > unclaimed add-ons > - Stale Work & Retirement Rules: Guidelines for marking work as stale or > retiring defunct code > - Graduation to Core: Rules and thresholds (e.g., high > adoption/downloads) for moving an add-on into core > - Tasks & Ownership: Assigning tasks and build/release management (I'll > be glad to take on builds) > - Version Matrix & API Compatibility: Maintaining a 3.x core > compatibility matrix and defining API compatibility promises (my vote: keep > up with latest, new versions of opennlp and we cut a branch and focus on > the latest. Dependabot updates on supported branches that we retire with > Opennlp core) > - CICD & Workflow Setup: Aligning CI/CD, test setups, build triggers, and > manual/automated workflow dispatch with core > - GitHub Issues & Governance: When to enable GitHub Issues, establishing > PR review thresholds (e.g., required approvals), and PR template > requirements > - Security Model: Defining how add-ons align with the existing OpenNLP > security policy, particularly for native code, data downloads, or > third-party dependencies (most of this is defined but we'll formalize it in > the repo) > > Kristian > > >> On Wed, Sep 9, 2026 at 4:48 PM Kristian Rickert <[email protected]> wrote: >> >> I meant for local development. But just poking at the maven plug in, I >> don't think that'll be needed either :) >> >> For cicd I'll put something up tonight. Assuming the expected failure, >> I'll full out the infra ticket >> >>> On Wed, Sep 9, 2026, 3:32 PM Richard Zowalla <[email protected]> wrote: >>> >>> No need for scripts. GH action can due that (via action view you can >>> select the branch to run from… cf. >>> https://github.com/apache/stormcrawler-site/blob/main/.github/workflows/publish-staging.yml >>> You just trigger it for a branch from the action view in GitHub. >>> >>> If you go with scripts, you don’t need credentials or INFRA issues. It >>> works with your normal ASF ldap credentials... >>> >>> >>> >>>> Am 09.09.2026 um 21:25 schrieb Kristian Rickert <[email protected]>: >>>> >>>> rzo1: >>>> >>>> Thanks for the feedback. >>>> >>>> Keeping it fully manual. We can create a dev script to trigger it from >>> the >>>> CLI to avoid click-ops. Nexus also supports grace periods and snapshot >>>> retention days, which we may have access to, but I will keep everything >>>> manual for now. >>>> >>>> Pretty sure you're right about the password requirement, so I will test >>> it >>>> first before submitting an INFRA ticket to avoid crowding their queue. >>>> >>>> I will create a JIRA issue for this. Acceptance testing should be >>>> straightforward.. it just needs to create the JAR in the branch. >>>> >>>> Load-bearing, >>>> Kristian Rickert >>>> >>>> >>>> On Wed, Sep 9, 2026 at 3:15 PM Richard Zowalla <[email protected]> wrote: >>>> >>>>> I wouldn’t deploy each commit on a branch. Perhaps a manual workflow >>>>> (similar to website staging in for example StormCrawler) would do the >>> job? >>>>> You can even select from which branch to run, etc. - that seems to be >>> the >>>>> easiest way and avoids bloating ASF infrastructure with throw away >>>>> snapshots. >>>>> >>>>> For the credentials to be set into the repo: it requires an infra >>> ticket >>>>> afair. >>>>> >>>>> Rungs >>>>> Richard >>>>> >>>>>> Am 09.09.2026 um 21:12 schrieb Kristian Rickert <[email protected]>: >>>>>> >>>>>> Hi Jeff, >>>>>> >>>>>> Yep, that naming convention is exactly right, and these will only go >>> to >>>>>> SNAPSHOTS on repository.apache.org. >>>>>> >>>>>> I'll test this using the Maven Release Plugin, which I believe handles >>>>> this >>>>>> convention out of the box. Since it is on an add-ons branch, it will >>> just >>>>>> error out if it fails, but our existing Nexus account should cover >>> it. If >>>>>> needed, I will submit an INFRA ticket to complete the setup. We can >>>>> always >>>>>> change it too :) >>>>>> >>>>>> Best, >>>>>> Kristian >>>>>> >>>>>> >>>>>> On Wed, Sep 9, 2026 at 8:53 AM Jeff Zemerick <[email protected]> >>>>> wrote: >>>>>> >>>>>>> I don't think I have any objections. Would you make the version >>>>>>> something like `<version>2.0.0-FEATURE-XYZ-SNAPSHOT</version>` when >>> on >>>>>>> the branches to indicate it's from a non-main branch? >>>>>>> >>>>>>> I know the snapshot repository is already in the core pom.xml. I >>> think >>>>>>> the CI would need updated to deploy those snapshots from a non-main >>>>>>> branch? I think we can put a condition on that CI workflow to only do >>>>>>> that if the branch (or pom.xml version) is named in a certain way to >>>>>>> prevent all branches from being deployed. >>>>>>> >>>>>>> Thanks, >>>>>>> Jeff >>>>>>> >>>>>>> On Tue, Sep 8, 2026 at 9:17 PM Kristian Rickert <[email protected] >>>> >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi team, >>>>>>>> >>>>>>>> Can we use Nexus for internal development >>>>>>>> <https://infra.apache.org/repository-faq.html>? Specifically, does >>>>>>> anyone >>>>>>>> object to using it for builds that are not yet merged into main? >>>>>>>> >>>>>>>> I would like to establish a build train between core, add-ons, and >>>>>>> sandbox >>>>>>>> (where core and add-ons deploy, but sandbox does not). Currently, >>> there >>>>>>> is >>>>>>>> no easy way to deploy dependencies until they are released to main. >>>>> While >>>>>>>> Maven handles this well, it requires deployment capabilities. >>> Writing >>>>>>>> custom scripts to bypass this defeats the purpose of our existing >>>>> tools. >>>>>>>> >>>>>>>> Here is what I am proposing: >>>>>>>> >>>>>>>> 1. Create a branch between core and add-ons. >>>>>>>> 2. Allow both to be published as snapshots to local Apache. >>>>>>>> 3. Ensure these JARs are available in GitHub CI/CD to keep core and >>>>>>>> add-ons in sync during development. >>>>>>>> 4. Make the JARs accessible in sandbox CI/CD so all authenticated >>>>>>>> committers can sync builds without manually downloading core or >>>>> add-ons. >>>>>>>> >>>>>>>> This workflow will allow us to test dependent services, such as >>>>> deploying >>>>>>>> the gRPC server internally, without reverting to a pre-Maven style >>> of >>>>>>>> development. >>>>>>>> >>>>>>>> I am happy to set this up, though I would appreciate pairing with >>>>> someone >>>>>>>> via Slack to navigate any system limits and serve as a second set of >>>>>>> eyes. >>>>>>>> >>>>>>>> Please let me know your thoughts on this. >>>>>>>> >>>>>>>> Load-bearing email rung, >>>>>>>> >>>>>>>> Kristian Rickert >>>>>>> >>>>> >>>>> >>> >>>
