On Tue, 5 Aug 2025 at 09:34, sebb <seb...@gmail.com> wrote: > > On Mon, 4 Aug 2025 at 20:15, Dave Fisher <w...@apache.org> wrote: > > > > I’m going to top post again Whimsy mission as provided in Board reports: > > > > > The mission of Apache Whimsy is the creation and maintenance of software > > > related to tools that help automate various administrative tasks or > > > information > > > lookup activities > > > > With this description there is no preference for the platform used to > > provide such tools. > > > > > On Aug 3, 2025, at 6:16 AM, Shane Curcuru <a...@shanecurcuru.org> wrote: > > > > > > Welcome, and thanks for stepping up Dave! > > > > > > sebb wrote on 7/31/25 7:06 PM: > > >> On Thu, 31 Jul 2025 at 18:37, Dave Fisher <w...@apache.org> wrote: > > > ...snip... > > >>> There are many other useful tools on the Whimsy platform. > > > > > > There are a LOT of other tools that different groups at the ASF use: > > > > > > https://whimsy.apache.org/committers/tools > > > > > >>> I would like to propose that this PMC start to build a Workbench > > >>> platform using Python and the ASFQuart framework using practices > > >>> developed during the creation of the new Board Agenda Tool (svn > > >>> integration and svelte) and the Apache Trusted Releases platform (uv > > >>> and storage integration). > > >> What is 'uv'? I assume it is not ultra-violet. > > > > > > Good question! > > > > > >> I'm not sure what you mean by a Workbench platform; at present the > > >> Whimsy Workbench is for the Secretary tooling only. > > >> Apart from the 3 tools mentioned above, I think all the other Whimsy > > >> tools are largely self-contained, and only share common library code, > > >> so I am not clear what a Workbench would entail. > > > > > > It's clear that "workbench" has a different meaning for the tooling team > > > than here in Whimsy, so each group should provide a definition if we're > > > going to compare things. > > > > For me a workbench is a platform, desk, or station where various tools may > > be used to accomplish various tasks. > > > > > > > > "Whimsy" is also overloaded as a term, it has a LOT of stuff: > > > > > > - A stable server with ruby (and sinatra, passenger, rails, wunderbar, > > > etc. bits for full stack service) and storage and SVN/git integrations > > > > Whimsy does not currently support OAuth or MFA. > > ASF OAuth does not support MFA either! > > Whimsy needs access to user credentials in order to update files; I > don't think that can be done with OAuth. > > > > > > > - The ruby ASF module, which provides a rich and organized interface into > > > the majority of our internal data sources, like LDAP, committee-info, > > > Incubator, board reports, Member Meetings, and more. > > > > And yet Ruby programming skill and the need to test and debug the Whimsy > > monolith has been a blocker for some in contributing to the platform. > > Another blocker is that Whimsy needs access to non-public data, and > there is lots of PII involved. > This makes it challenging to set up development environments, > regardless of the language used. > > > Python support for LDAP exists in Infra’s python platforms and this > > supports the nearly complete Agenda Tool. > > There is support, but it relies on launching an LDAP application for > each request, whereas Ruby has native bindings. > > > > - Lots of user-facing independent applications (see /committers/tools) > > > > Yes. > > > > > - A variety of utility tools and data stores that interact or are used > > > with groups across the ASF: /public/*.json, /site/ > > > > > > - The Board Agenda and Secretary Workbench applications, which include > > > richer functionality (and underlying server bits) than other tools. > > > > From the Tooling team - Agenda Tool replacement is coming very soon and > > Secretary Workbench work will commence soon. > > What about the Roster tool, which is the other main Whimsy app that > handles PII and needs user credentials? > > > > > > >>> If the Whimsy team is interested then we can setup a repository, vm > > >>> host, and start development. > > >>> > > >>> Whimsy could also become the home for member developed extras like > > >>> Daniel’s ASFMM. > > >> That's not really in the Whimsy mission as listed above. > > >> Maybe that could be taken over by ComDev? > > >> That code is all Python. > > > > It may be Python, but it’s not using the preferred asfquart framework. > > My point was that the ASFMM is not in scope for Whimsy. > Seems to me Tooling would be a more natural home for it. > > > > > > > Taking a step back, no-one is asking the real question - the reason the > > > board appointed a VP, Tooling and budgeted funds to hire tooling staff. > > > > > > -> How much volunteer energy do we have for maintaining and building new > > > tools in the Ruby ecosystem? <- > > > > > > Reading Whimsy project reports shows a low and declining amount of energy > > > for Ruby actual work *. In our larger community, I see either > > > disinterest or near hostility towards Ruby as well. > > > > As noted above and as I am suggesting: > > > > 1. Nothing in the Whimsy mission requires Ruby. > > 2. By working on various “whimsical” tools using Infra’s preferred > > platforms all new and rewritten tools can be more easily made essential > > should the Board find it necessary. > > > > > Since the Infra Team has long standardized on python, the obvious next > > > organizational question is: how do we create a place where volunteers can > > > build useful and stable things like Whimsy bits, but do so in an > > > environment that mirrors the python world that Infra natively supports? > > > Because in that case, if a popular tool becomes "critical", then it's > > > merely a simple redeployment of the tool, not re-engineering it from our > > > Ruby ASF:: modules into Infra's asfquart land. > > > > So, Tooling is living in asfquart land and the offer here is for future > > Whimsy to also be in asfquart land. There are many examples. > > > > If the PMC wishes to remain only with the Ruby platform then future > > whimsical tooling will have a harder lift towards being useful as an > > essential tool. > > I personally prefer Ruby, as its syntax and features make it very > flexible; it's very easy to create easy-to-use shortcuts for > generating HTML and JSON etc. It's also very good at text manipulation > and matching. (I think Ruby is the basis for Puppet, as used by > Infra). > > However I also use Python, and there is already some Python code in Whimsy. > > But as noted above, Ruby is not the only blocker: there is also the > need to handle PII and non-public data, which will continue to be an > issue. > This mainly affects the Agenda, Secretary and Roster apps, but any > tool that uses LDAP or non-public resources will need credentials. > This makes setting up development harder. > > I am not saying that Whimsy cannot move to using Python and asfquart. > But AFAICS doing so will not magically eliminate all the barriers to > participation.
There is also the issue of the UI. Ruby makes it very easy to generate HTML. For example [1] and [2] AFAICT, there is no Python equivalent. [1] https://github.com/apache/whimsy/blob/master/examples/board.rb [2] https://github.com/apache/whimsy/blob/master/www/test/example.cgi > > Best, > > Dave > > > > > > > > -- > > > - Shane > > > Member > > > The Apache Software Foundation > > > > > > * Note that while our amazing sebb may have the strength of 10 engineers, > > > one human can't run a whole project alone. > >
