Skip to content

PSC Meeting 2022 03 18

Jump to bottom Edit New page
TC Haddad edited this page Mar 18, 2022 · 14 revisions

https://web.libera.chat/?channels=#geomoose

Previous Meeting

Attending

Dan, Brent, tchaddad, klassenjs, jmckenna, ..

Agenda

  • closing tickets and last call for 3.8.1 or 3.9
  • Development priorities - "big rocks" that do not necessarily push towards a new version.
  • Direction setting - future vision, what might a "4.0" look like.

Last call for 3.9

  • Jim suggests that the "limit number of features buffered PR" AKA "Adjustable Buffer Count" implies we should call the next release 3.9, and no one has objections to that. See the PR for more info: https://github.com/geomoose/gm3/pull/715
  • general agreement that a change like the above will need docs and/or examples for how to configure
  • Singularity bug may be back - this could now be something that can be user configured, so we will try to confirm and open a new ticket for it

Priorities

  • we should issue a clean 3.9 at least before considering a next major release, and in general should be more regularly dropping the patch releases.

  • Duck mentioned that we have a pile of High level audit warnings right now that we would like to get fixed buuut it'll require an upgrade to Webpack 5 which we are not ready for. Seems like we are close on that.

  • also need the configuration doc update for the 3.9 release

Direction Setting

  • As a bit of a transition point, duck mentions that klassenjs has the position that we "Have a big library" which we sorta do. But in the wild it feels like no one has taken the library and run with it. So do we keep apps and library separate?
  • We could try to mature the "Library" half. Make it work as more independent react components. Keep refactoring to make Redux the best option but not wholly necessary. And the example applications would then require something like create-react-app.
  • OR we could drop the pretense and actually just sharpen the knife, deliver "an app" which can be customized but stamp out, say, a mobile and a desktop version
  • Jim still thinks there is value in having the apps and library separate
  • Brent thinks we need to document some kind of a GeoMoose API, to encourage use of the GeoMoose library
  • Duck thinks this is a fair point: we used to have some sort of automated API generation
  • Jim is curious What a react/redux geomoose app would look like? Could we provide an example that could be easily tweaked similar to what we do now? Would it require a build step?
  • Duck says it depends on how far we go - Could go as far as controlling the whole DOM and only letting the user drop in fragments to the configuration object For things like the header, etc. CSS would still be available. All the same options for the Application class would apply there just wouldn't be the slightly awkward DOM binding we do now
  • Jim was hoping for something more flexible than that. Like the library exposing catalog and map and whatnot and letting the app worry about overall layout
  • Duck Will do some digging and circle back on this
  • Next on Duck's list (with no direction changes): Fix how filters are handled for the results (it should apply to everything) and fix the performance issues in the table by virtual-zing/windowing it (sounds good to everyone else)
Add a custom footer
Clone this wiki locally