This time of the year, under normal circumstances, we would have the Alpine City Sprint in Innsbruck. So, given the special nature of the sprint it is not possible to turn it into a remote sprint.
Anyway, we will sprint remote and online on all Plone core topics on February 10th to 12th.
We will use Jitsi and Discord to coordinate, have stand-ups (or sit-ups).
Details will follow soon.
--
Regarding to the actual Alpine City Sprint 2021: If it will happen, then this time in summer 2021 and probably outdoors in the mountains around. I still have no clue if it is possible. Stay tuned, healthy and first join us remote!
Let it begin!
Each day standups at the announced Jitsi General sprint channel are (the document above) are planned at 10am and 5pm CET. Besides this we are available in the General or announced topci channels.
Plone Classic Barceloneta Bootstrap 5: @agitator and @petschki fixed failing tests, are down to 21 failures
Issues with Jenkins left: does not show the right build numbers. Mr.Jenkins needs some love!
ES6 Mockup: @thet and @MrTango Work done, but no report today, stay tuned.
Current Plone Installer: @jensens fixed the current one, one combination at GH actions fails (Py3.7/macos) all others are green, help needed here @fredvd will try it out. Todo: Test and fix on Windows.
Future Plone Installer: Discussion with about 10 people on Zoom, separate article about it follows.
plone.autoinclude: @tschorr worked on it with help from @mauritsvanrees - report about it at Installers meeting.
Plone DX SiteRoot @alert worked on it, mainly cleaning up and getting into it.
Relations helpers and controlpanel: progress on fixing bugs @pbauer And polishing
EEA Facetednavigation for Plone 6 classic: @balavec worked on it found issues and discussed with @avoinea
Report of Thursday (stat from Friday morning standup):
Plone Classic Barceloneta Bootstrap 5: @petschki@agitator tests are green, next step: bumb all touched to new major version, branch before merge as .x,
Mockup ES 6: Lots of progress by @MrTango and @thet - TinyMCE pattern challanging, because new version of TinyMCE is quite different.
plone.autoinclude - adding tests by @mauritsvanrees and @tschorr (integration and unit tests) are in the works. Test are difficult here. May end up with two different calls. Also testing it with all Plone packages is challenging.
We discussed pip coredev development and integration testing with all tests pip installed.
Dexterity Site Root: @alert basically works, builds green. next: test upgrades and more
Installer: Still trying to figure out what happens on Python 3.7/Macos - the only failing combination at GH actions @fredvd checked on his local Macos, all works. @alert experimented to get better output. Seems to be a GH Actions specific problem. We will skip the combination for now. Next is to make it work on windows and add GH actions testing for it.
@jensens@mauritsvanrees question about upgradesteps: besides the new staticresources there are several packages with profile changes (mainly icon_expr in typeinfo or controlpanel) which needs to be updated ... each package gets an upgradestep separately for this, but how is this "bundled" together in plone.app.upgrade? is there an upgradestep there which calls each separate package upgrade?
@petschki
When you run @@plone-upgrade, first the stuff in plone.app.upgrade is run. Then the MigrationTool looks at a list of add-ons. It applies any upgrade steps for them. For example plone.app.contenttypes is in that list, so if you add an upgrade step to plone.app.contenttypes it will be applied automatically at the end of the @@plone-upgrade run.
It is fine to add more packages in this list.
I guess there is no clear line on when a package should be in this list and when you should add code in plone.app.upgrade instead. I would say: use plone.app.upgrade when you need control over the order in which steps are run, or when the upgrade step is not about a single package.