You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@steve.apache.org by Greg Stein <gs...@gmail.com> on 2022/03/06 07:58:09 UTC

Various items for discussion

Hello all,

I wrote this on Slack [on March 3] to get a rough feeling and initial
feedback. I got a non-binding +1 and no other comments, so I'll just
copy/paste it all here:

   - Jim just asked [elsewhere] about the asfbot, and I suggested that the
   code should likely [be] brought up to current ASF Infrastructure patterns:
   py3, git, and a pipservice-based daemon.
   - obviously, STeVe is not part of Infra
   - but I do believe that we have created a nice pattern for daemons, and
   a little bit for webapps (still fleshing out a good way to build
   flask-based apps, which I think is the correct long-term path for $reasons)
   - we defo want to drop elasticsearch, and switch to sqlite, too
   - should there be energy, then I would suggest moving to git as a first
   step. Bring up a website on the asf-site branch (per ASF standard) and use
   Pelican and .asf.yaml to build that site from a "site" directory (which the
   svn repo already has, but is empty)
   - (not a separate repo; there is no need for that; git peeps tend to
   create a repo when the wind shifts; it makes no sense, from a version
   control perspective)
   - we can recover the old site's .md files from svn. It was rm'd last
   August, but is easy to bring back (I replied to sebb with the revision#, so
   the hard archaeology is already complete)
   - I also suggest rm'ing all the obsolete stuff from the repository. We
   have several generations in there, mostly unused and only serving to
   distract.

Thoughts welcome. I suggest the above as steps that I think we can shift
Apache STeVe towards, fix up some basic structure to provide a more
inviting community (eg. shifting some items to GitHub to create better
interactions).

I hadn't thought about it, when I wrote the above, but would also suggest a
move to using GitHub Issues rather than Jira. (and yes, this implies a need
to handle the existing Jira issues, or to move them).

Ideas? Concerns?

Cheers,
-g