You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@magpie.apache.org by "liwenjie200543 (via GitHub)" <gi...@apache.org> on 2026/09/26 07:47:40 UTC

Re: [I] release-verify-rc: validate rc jars [magpie]

liwenjie200543 commented on issue #1173:
URL: https://github.com/apache/magpie/issues/1173#issuecomment-5844373562

   I'd like to pick this up. To keep the first PR reviewable, I'd split
   the work:
   
   - **PR 1 — blocking checks 1–3, local artifacts only:**
     - `.pom` license / `<developers>` / `<scm>` check (check 1)
     - podling incubation disclaimer in the POM `<description>` (check 2)
     - companion `-sources.jar` / `-javadoc.jar` presence, each with its
       own `.asc` and checksums (check 3)
     - implemented as a Python tool under `tools/` (stdlib XML parsing,
       no new dependencies), with unit tests over fixture POMs and jars,
       wired into `release-verify-rc` where the source tree is verified
       today.
   
   - **PR 2+ —** the Nexus staging-repository check (4), which needs
     network egress and an endpoint contract, then the informational
     checks (5–7).
   
   Two questions before I start:
   
   1. Does this slicing order match what you had in mind, or would you
      rather see the informational checks first since they never block?
   2. For check 4, should the Nexus probe live as a `tools/` adapter with
      declared egress (per the framework's egress rules), or be scripted
      inline in the skill?
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org