Brainstorm - Roadmap Discussion

[vaughanknight]

This thread is to drive discussion around the roadmap - moreso how we handle it, how we capture what is in the roadmap, and how we agree on roadmap ideas. Once we get this in place we can create a process document or markdown document to capture it, and ADR's if required.

[nttDamien]

I discussed a bit with Suenaga san, on NTT Data side the following is seen:

• release a v1.1 soon (end of summer at the latest ?)
• would like to have PR Add 4-release.yaml to publish container image for the release #342 (WeAPI container) in v1.1, probably needs a bit more discussion with Dan
• finish PR [Feature Contribution]: Initial DevOps and github actions clean up #252 discussions
• multiple data source support [Feature Contribution]: Multiple data source support #345 probably aiming for v1.2
• also some work on client libraries for Java, JS, mentioned in PR [Feature Contribution]: Initial DevOps and github actions clean up #252 comments (here)

more generally we were wondering if the github projects function should not be leveraged (kanban style).
Also the labels for tagging which PR is planned for which version, it seems to be used sometimes, but not systematically.
Maybe once we agree on the how, we could do a session on clearly identifying what is 1.1, owners of other PR, when would be 1.2, and what would be a target for 1.2 ?

[Willmish]

I discussed a bit with Suenaga san, on NTT Data side the following is seen:

• release a v1.1 soon (end of summer at the latest ?)
• would like to have PR

#342 (WeAPI container) in v1.1, probably needs a bit more discussion with Dan
#342 (WeAPI container) in v1.1, probably needs a bit more discussion with Dan

Hi and thanks for kicking this off. I agree to aim v1.1 realese sooner rather than later, probably much earlier before summer as all PRs we want in v1.1 are already in the repo, or sitting in review (as before-mentioned by you #342 for example). What we are missing is:

• the CHANGELOG which @vaughanknight I believe wanted to collect with the use of Github Copliot X - which can do some LLM processing of the merged PR data with GPT-like model underneath (AFAIK).
• FInal PRs merged in - what I'd like to see in v1.1 is updated documentation to refer to the new arch diagram #353 Add 4-release.yaml to publish container image for the release #342 Integration tests coverage for WebAPI and CLI #294
• Would be nice to have more samples (but not crucial for v1.1), including: Add example for 'podman play kube' #340 and [Sample]: Jupyter notebook Demo of web API  #114 (although this one Im holding off until we decide how we move forward with client libraries).

• also some work on client libraries for Java, JS, mentioned in PR [Feature Contribution]: Initial DevOps and github actions clean up #252 comments ([Feature Contribution]: Initial DevOps and github actions clean up #252 (comment))

On this, as I mentioned for #114 - i'd would be good if we know how we move forward with distributing client libraries. Its great to see @YaSuenag working on support for Java and JS! Are you only using the OpenAPI generated libraries? or also modifying the code for them /docs? Ideally I'd like to have them distributed with each release as packages, and this would be a great DRIVNG feature for v1.1.1 or v1.2!
I personally really would like to have a Python package easily accessible, for the Data Science use cases in Jupyter notebook, let me know your approach and thoughts on this.

[Willmish]

Oh and @nttDamien , regarding github projects kanban board, we used to have a project manager looking after this and some volunteers from @vaughanknight 's team, but It would be good to bring it back, at least for high level release planning, open to other suggestions.

Also the labels for tagging which PR is planned for which version, it seems to be used sometimes, but not systematically.
Maybe once we agree on the how, we could do a session on clearly identifying what is 1.1, owners of other PR, when would be 1.2, and what would be a target for 1.2 ?
This honestly was used to mark major PRs that we really wanted to see in a specific version. However, I do agree that maybe we should stick to either tagging all or none. What I suggest is if a PR comes through and we know this is not on schedule for the next release (eg. v1.1) we should create/use tag for next minor release(e.g v1.2). Thoughts on this? @YaSuenag @vaughanknight @danuw @nttDamien ?

[YaSuenag]

Are you only using the OpenAPI generated libraries?

Yes, I uploaded my proposal to generate client library for Java.
https://github.com/Green-Software-Foundation/carbon-aware-sdk/pull/359/files#diff-cb4680a5aa9b7d275727859c1bc0fbec123b4ffa635ff67f06ec031fb621dacdR42-R50

Ideally I'd like to have them distributed with each release as packages,

In Java, we can get Javadoc (API document for Java) via GitHub Packages (see "javadoc" libraries in "Assets"):
https://github.com/YaSuenag/carbon-aware-sdk/packages/1814194

I personally really would like to have a Python package easily accessible, for the Data Science use cases in Jupyter notebook, let me know your approach and thoughts on this.

Completely agree, but how can we publish? Unfortunately GitHub Packages have not yet supported pip... It has been requested, but we cannot see the schedule: github/roadmap#94

We can use PyPI of course, but I guess GSF does not have an organization account in PyPI.