We’ve discussed with Stefan & Zyga
Jasmine Alpha release shortly. Especially:
- what is feasible
- what we could afford for for that release (in terms of time, capacity etc)
Here are some conclusions:
- central signing => not feasible for alpha, however, we want to try to get our hands dirty with tags signing (the sooner the better)
- Stefan to assess how to use h/w key (dongle) and if feasible, later to sign & share h/w token with WRC team
- at some point in time, we should start signing tags & tarballs by default
- scripting for release => only some of basic release-mechanics operations for the moment
Binaries preparation (blueprints)
Release preparation checklist
- Stefan to update / adjust if necessary
Release notes improvements
- Seb to figure out how to best approach to requirements mapping into functionalities available in release notes (e.g. how much of “clang” is available in given release), not for Alpha
- how to improve on release timing (e.g. feature freezes, merging windows etc)
- how to automate (central?) signing
- how to integrate with CI
Please comment if I’ve missed any point or you have simply more thoughts on this.
I would keep it very easy to avoid creating unnecessary overhead and focus all our firepower against features. I am thinking of this Alpha as a checkpoint to see where we are with critical items, such as roadmap, marketing, IP SBOM, etc. - like when you are running a marathon and you take your time at 10km to see if you’ll make a good time.
Was there any discussion about the list of release artifacts?
No, only very shortly. I have some points to be checked. I’ll keep you (all) updated for that.
Why aim for hw dongles for signing just now? We can do just GPG signing as most projects do.
Other things to be considered:
- what is exactly in the release (which modules, sources only? binaries of the blueprints?)
- how it is published? tag only, tarballs somewhere etc
- scope of the IP check
- scope of the release hardening (if none, that should be clearly said)
I will try to suggest a time boxed approach here - let us invest no more than 8 hours in total including go - no go meetings etc for this alpha, shall we? Including the time needed to read and reply here
Just to try with that. It’s a broader discussion, (e.g. key & responsibilities sharing), where to store keys etc. Definitely not for Alpha.
Indeed, we want to treat it as a checkpoint. If we want to have a formal voting, I can organize it for Fri. Not sure, however, if that is needed (it’s still Alpha). If not, I’ll prepare some summary for sprint review. I’ve planned to be off next week, so probably I’ll ask Adam or you to carry out the review.
Due to the nature of this milestone I would recommend to drop go/no-go and save everyone’s time. It served it’s purpose being a reminder for making a checkpoint and forcing to reflect on how are we progressing.
As a reference here is the public key part to verify our signed tags with git tag -v
-----BEGIN PGP PUBLIC KEY BLOCK-----
-----END PGP PUBLIC KEY BLOCK-----
This should be hosted on our static website at a later stage. Maybe beta, or at least the final release.