Re: [CMWG] December 6 Meeting

[Melissa Logan]

Meeting notes and recording are below. Hope to see many of you next week at
Summit!

Meeting Notes:
https://cwiki.apache.org/confluence/display/CASSANDRA/2023-12-06+Meeting

Recording:
https://us02web.zoom.us/rec/share/rb3pazIQx2wld5hG3IZVwQr1rotLFFCwaDhuVGqrbDn70fOVIrUgXhI2xjCmi7pK.Z6iR7Ut6UK3-BAlq
Passcode: N51LWfm!


On Tue, Dec 5, 2023 at 3:16 PM Melissa Logan  wrote:

> Tomorrow is the last Cassandra Marketing Working Group meeting of the
> year! Join us at *8:00am PT / 4:00pm UTC, Wednesday Dec. 6*.
>
> Agenda below. If you have something to add, please do so here
> .
> Details and how to join are in the document.
>
> Agenda
>
>-
>
>Cassandra Summit 
>+ AI.Dev 
>-
>
>Catalyst program launched!
>-
>
>   https://cassandra.apache.org/_/cassandra-catalyst-program.html
>   -
>
>   Nominate someone or apply
>   
> 
>   -
>
>Should we keep using X?
>
>
> Ways to Participate
>
>-
>
>Social media promotions
>
> 
>-
>
>Cassandra Catalyst program
>
>
>
> Upcoming
>
>-
>
>12-13 December Cassandra Summit
>, San Jose
>-
>
>3 January CMWG
>-
>
>25 January Town Hall - AI Panel with Jon Haddad, Dinesh Joshi (others
>pending)
>-
>
>30 January Contributor Meeting - CEP-38 with Maxim Muzafarov
>
>
> Melissa
>

Re: [Discuss] ​​CEP-35: Add PIP support for CQLSH

[Jeff Widman]

👋 I'm the other current maintainer of https://github.com/jeffwidman/cqlsh.

*> Knowing nothing about the pypi release/publish process, I'm curious how
you would stage and then publish the signed convenience package.
Background: what we publish post-release-vote needs to be signed and
identical to what is staged when the release vote starts. See the two
scripts prepare_release.sh and finish_release.sh
in https://github.com/apache/cassandra-builds/tree/trunk/cassandra-release
 ,
where all the packaging is done in prepare_ and finish_ is just about
pushing what's in staging to the correct public locations.  I am assuming
that the CEP would be patching these two files, as well as adding files
in-tree to the pylib/ directory*

>From a tactical implementation standpoint, there's a few ingredients to a
release:

   1. Packaging code used by PyPI such as `pyproject.toml`:
   2. Code freeze of the functional code.
   3. Versioning.
   4. Secret management of the PyPI credentials
   5. The actual publishing to PyPI.
   6. Maintaining the above, ie, fixing breakage and keeping it up to date.

Looking at them in more detail:

   1. Packaging code used by PyPI such as `pyproject.toml` - This should be
   easy to add into the tree. Brad / myself would be happy to contribute and
   we should be able to pull most of it directly from
   https://github.com/jeffwidman/cqlsh.
   2. Code freeze of the functional code - This already happens today upon
   every Cassandra release.
   3. Versioning - Versioning is a pain since currently CQLSH versions are
   not aligned with Cassandra. Furthermore the internal CQLSH version number
   doesn't always increment when a new version of Cassandra / CQLSH is
   released. However, PyPI requires every release artifact to have a unique
   version number. So we work around this currently by saying "Here's pypi
   version X, which contains the cqlsh version from Y extracted from Cassandra
   version Z".
  1. If you want to keep CQLSH releases in-lockstep with Cassandra,
  then life would be _much_ simpler if the CQLSH version directly
pulled from
  the Cassandra version.
  2. However, there's still the problem that sometimes the CQLSH python
  packaging may have a bug, which forces a new release of CQLSH.
Seems a bit
  heavyweight to require a new release of Cassandra just to fix a
bug in the
  python packaging.
  3. Another option is to have CQLSH release *not* tied at the hip to
  Cassandra releases. Extract it to a separate project/repo and
then pull in
  specific releases of CQLSH into the Cassandra final release. Probably too
  heavyweight right now given we are trying to simplify life, but wanted to
  mention it.
  4. I don't feel strongly on the above, other than the current state
  of affairs of requiring three different versions is worse than either of
  the above options.
  4. Secret management of the PyPI credentials
  1. I'm not sure if Apache projects have a special "apache account"
  that they typically use, or if they add multiple maintainers as admins on
  PyPI, and then add/remove them as they join/drop the core team. Either
  works for me.
  2. We'd probably want to keep Brad / myself as admins on PyPI as
  we'll be more attentive to breakage / fixing things but that's
really up to
  the discretion of the core team... I'm fine if you folks prefer to remove
  our access.
  3. Making the secrets available to the publishing tool can be managed
  using PyPI's trusted publishing:
  
https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/#configuring-trusted-publishing
  .
   5. The actual publishing to PyPI.
  1. The "staged" releases could be pushed to
  https://test.pypi.org/project/cqlsh/ and then the final released
  pushed to the normal https://pypi.org/project/cqlsh/
  2. The commands to publish to PyPI could be added to the
  prepare_release.sh and finish_release.sh.
  3. Alternatively, could add a CI/CD action such as a github action
  directly to the Cassandra repo that watches for new git tags on the repo
  and pushes those versions out to PyPI.
  4. I'm not particularly wedded to a solution, but if I had to choose,
  I'd go with the GitHub action. The reason being that it's a simple,
  commonly followed way of doing things within the Python world, so if it
  breaks, it's easy for a drive-by contributor who's familiar with
  Python/PyPI to contribute a fix.
   6. Maintaining the above, ie, fixing breakage and keeping it up to date.
  1. Brad and I are both happy to help with this on an ongoing basis.
  2. I suspect the core team won't want to give us commit rights
  (understandably) so we'll still need someone on the core team to approve
  any PR's that w