Meeting will happen in #d10readiness on drupal.slack.com.

Hello and welcome to this Drupal 10 readiness meeting!

This meeting:
➤ Is for core and contributed project developers as well as people who have integrations and services related to core. Site developers who want to stay in the know to keep up-to-date for the easiest Drupal 10 upgrade of their sites are also welcome.
➤ Usually happens every other Monday at 19:00 UTC.
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to: `https://www.drupal.org/project/drupal/issues/3265231`
➤ *Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

0️⃣ Who is here today? Comment in the thread below to introduce yourself.

daffie Hi, I am core contributer
hestenet (he/him) Tim from the DA following along
Björn Brala (bbrala) Lurking
Spokje Spokje, local village-idiot aspiring to take over the world, but considering becoming a town-idiot as a stepping stone first.
dww Derek. Summoned by ping. :wink:
shaal Ofer Shaal, DrupalPod, Florida :sunglasses:
ckrina Cristina from Barcelona :wave:
keboca Hola :flag-cr:
saschaeggi Sascha, Zurich :wave:
larowlan Hi
Gábor Hojtsy (he/him) hey, Gábor from Hungary
bircher hello
andypost Andy, Ukraine
Ilcho Vuchkov (vuil) Ilcho, Bulgaria :flag-eu:
quietone Hi
longwave Dave, UK, catching up
kimb0 Kim, Sydney AU
sharique Sharique, Pune, India
Kristen Pol (she/her) Kristen, California, catching up

1️⃣ Do you have suggested topics you are looking to discuss? Post in this thread and we'll open threads for them as appropriate.

daffie I have 2 issues I would like to talk about: #3266252: [policy] Release a Drupal 9.10 that uses Symfony 5.4 and CKEditor 5, and is supported until 2024
Björn Brala (bbrala) I think it's important to point to the removal policy issue and page
Björn Brala (bbrala) I'm on mobile let me try and find it
Björn Brala (bbrala) The relevant issue: [#3266219]The current posted policy is still somewhat under construction :slightly_smiling_face:
Gábor Hojtsy (he/him) @Björn Brala (bbrala) I added that to the modules thread.
Björn Brala (bbrala) Nice, thanks
bircher maybe a topic: Is there any hope to align the DIC with symfony ie [#3021900]I know we do crazy things like installing modules in a request, so our container is optimised for different things and it quickly gets hairy. So I just wanted to know if there is some effort or if that will be something once other fires have been put out.
bircher @Gábor Hojtsy (he/him)
Gábor Hojtsy (he/him) @bircher for the next meeting probably (next week) and we are well out of time now :smile:
bircher thanks! I came a bit late, I am happy also if it is discussed next time
bircher have a good evening!
Gábor Hojtsy (he/him) @bircher next meeting is #3267083: Drupal 10 readiness meeting / 7 March 2022 if you can add it there, that would be great, thanks!
Kristen Pol (she/her) For later, one thing to consider that's nice in the bugsmash meetings is one thread for letting people point out any recent “wins” they've had on the initiative… I think it sets a good vibe

2️⃣ Alpha2 is now released, including PHP 8.1 requirement and Symfony 6. Congrats!

Gábor Hojtsy (he/him) Release notes at https://www.drupal.org/project/drupal/releases/10.0.0-alpha2
Gábor Hojtsy (he/him) Note that there were/are some drush compatibility issues. There is not a fixed release yet I believe but https://github.com/drush-ops/drush/commit/d3deb23d22df6b6ae201fafd28f78f... resolved some of the known problems. The drush maintainers are on top of it. :clap:
Gábor Hojtsy (he/him) This was posted prior to alpha2 to make sure the PHP 8.1 requirement is known far and wide. https://www.drupal.org/about/core/blog/drupal-10-will-require-php-81

3️⃣ We are not trending to get ready for the mid-March beta window, so the June release is now off the table. The next release window is in August, if beta requirements are done by mid-May. We need your help to get these things done in time! Sub-threads below for specific topics you can help with! (edited) 

daffie Are there any PHP issues that need helping with?
Gábor Hojtsy (he/him) Opening threads now ;)
danflanagan8 Is there still momentum for removing Classy? I was working on these awhile back. I'd be willing to pick it back up again if I can get reviews. #3083275: [meta] Update tests that rely on Classy to not rely on it anymore
Gábor Hojtsy (he/him) @danflanagan8 I will open a thread for that :)
Gábor Hojtsy (he/him) We also posted https://www.drupal.org/about/core/blog/drupal-10-in-august-2022 with similar info as we have here in the threads :slightly_smiling_face:

3️⃣.1️⃣ Help needed on issues in CKEditor 5 roadmap to stable in core.

Gábor Hojtsy (he/him) #3238333: Roadmap to CKEditor 5 stable in Drupal 9
Gábor Hojtsy (he/him) @wimleers (he/him) is leading this effort
lauriii We are posting weekly updates on the #ckeditor5 channel at the moment. Link for the latest update from there https://drupal.slack.com/archives/C01GWN3QYJD/p1646048538745639

3️⃣.2️⃣ Removing Aggregator from core. Aggregator is a top priority because it is a Drupal 10 beta blocker (due to a risky third party dependency).

Gábor Hojtsy (he/him) #3188549: [Meta] Tasks to deprecate both Aggregator and our dependency on Laminas Feed is the issue
Gábor Hojtsy (he/him) I think the fantastic work on the other module removal issues paved the way well for this. Eg removing the intertwined connections with HAL.
daffie I shall start helping with this.
larowlan I'm about for reviews on this, please ping me
dww Do we already have a sucker^H volunteer for contrib maintainer? :wink:
Gábor Hojtsy (he/him) Per the issue summary @larowlan and @andypost signed up. @andypost is in a war now :(. I think @larowlan can do this :)
larowlan yeah I've got a client using it, happy to step up

3️⃣.3️⃣ Removing other modules from core (not beta blockers but great progress!): Forum, HAL, Tracker, QuickEdit, etc.

Gábor Hojtsy (he/him) Thanks folks for the fantastic work on this. I don't know if I could name all the names but least @Spokje, @Björn Brala (bbrala), @larowlan, @quietone, @catch, @dww and others have been instrumental here.
Spokje So hal has left the Core building, a lot of people put a lot of effort into making a solid base (and more!) to getting the whole process formalized (https://i.imgflip.com/669nbn.jpg).Besides aggregator being the top-priority, is there:A preferred order for the other nominated modules?A possibility to deprecate core modules that didn't make the deprecation-cut for D9.4.0 in minor versions of D10 for deprecation in D11? (I don't see all nominated modules making it and want to prevent us from starting too late Yet again as we seemingly did in 8.9 and probably will in 9.3)(edited)
Gábor Hojtsy (he/him) #3266219: [policy, no patch] Document the approach and issue scope for removing modules from core is the policy as pointed out by @Björn Brala (bbrala) (for the recording and those who are not aware yet)
Gábor Hojtsy (he/him) @Spokje I don't think there is an order other than aggregator being the top priority due to the risky depenendcy and YES we should continue to evaluate and deprecate modules in Drupal 10 going forward.
catch I don't think there's a preferred order either but we might want to come up with an informal one to make things easier on ourselves.
catch Well maybe 1. Aggregator 2. Quickedit since quickedit removes some JavaScript surface. After that afaik no order yet.
Spokje I would propose after that Core modules that already have a release out in Contrib? Like for example https://www.drupal.org/project/forum
catch Yeah anything with some work done means less to remove.
dww QE is actually pretty close. The main removal issue is down to blocked on 2, and one of those is nearly RTBC.
mstrelan Added a very rough draft MR to the second QE blocker. Needs work.
quietone Update the deprecation meta based on this discussion.
quietone Also, trialing the steps in the module deprecation policy with the tracker migration. I'll do that same for aggregator, quickedit and forum if anyone thinks it would help (and not interfere with what is already happening).
Spokje quickedit might be a special snowflake, since it was our first stab at deprecation/removal, so we kinda whacked a whole lot in one issue.I think for that one it might help (certainly won't hurt), for the others I can see only good things coming out of it.(Reducing of MR size, no unexpected blockers, etc.).So for me it's a big YES! (FWIW)
quietone OK, I will embark on some issue admin.
quietone aggregator, quickedit and forum now have a Meta to track the entire process. I am sure it still needs adjustments as we find our way. The meta for each module can be found on #3118154: [meta] Deprecate dependencies, libraries, modules, and themes that will be removed from Drupal 10 core by 9.4.0-beta1#comment-14428998
dww Fabulous, thanks!
quietone Your welcome. And RDF has been added to the can be worked on list because the policy issue is RTBC.
Spokje Awesome work = awesome!

3️⃣.4️⃣ Over half of the deprecated APIs are removed from core already. Thanks y'all!

Gábor Hojtsy (he/him) Visual at https://twitter.com/gaborhojtsy/status/1494378131934916612?t=VuUbV3Qwq5I...
Gábor Hojtsy (he/him) And it's from more than 10 days ago even :)
andypost Sadly I can't continue removals but hope soon war will over
Gábor Hojtsy (he/him) @andypost thanks for all you are doing, and make sure to take care of yourself first!
andypost Metas are[#3213895]

3️⃣.5️⃣ Claro maintainers spent time to review the roadmap and removed the items not required for stable. While the rest of the Claro queue is being reviewed for potential blockers, the roadmap has items that need help.

Gábor Hojtsy (he/him) #3066007: Roadmap to stabilize Claro
Gábor Hojtsy (he/him) This is kept up to date by @ckrina, @lauriii, @saschaeggi and @bnjmnm and various blockers have been recently committed. It’s a good place to work on things and get moving. (edited)
saschaeggi #3085219: Installer is not very usable in Claro
Kristen Pol (she/her) I've been mentoring coworkers on contributing to Claro issues the last couple weeks… we've mostly been testing but there's a developer who can help with patches too. If there are some simpler issues that you'd like eyes on, please let me know and I'll see if they/I can help

3️⃣.6️⃣ Olivero needs some backend help to become the default core theme! @tstoeckler has been active here, but we need more hands involved.

Gábor Hojtsy (he/him) #3219958: [META] Make Olivero the default theme
Gábor Hojtsy (he/him) @mherchel can help point you to the backend issues if they are not jumping out :) (edited)
mherchel Yes! Olivero is stable, but we need some backend expertise to make it the default theme for D10. (Super thanks to @tstoeckler who's been working on it a bit). Most of the work is fixing PHPUnit tests.All of the issues are in the meta issue above. The first on the list that we need help with is #3260592: Change Bartik-specific tests to Olivero (or appropriate alternative) in preparation for making Olivero the default, which is a subissue of the main that helps break the work out in reasonable chunks. Any help is GREATLY appreciated (meaning that I will buy you drinks in Portland or Prague!)
catch That test issue is probably just splitting an existing patch into two parts, the actual changes are already done, so easy one to do if in someone is up for it.
Kristen Pol (she/her) I've been mentoring coworkers on contributing to Olivero issues the last couple weeks… we've mostly been testing but there's a developer who can help with patches too. If there are some simpler issues that you'd like eyes on, please let me know and I'll see if they/I can help. Maybe that one? ^
catch @Kristen Pol (she/her) it should be just reconstructing a smaller patch out of a bigger patch, possibly re-rolling, so a good one to start with I think.
Kristen Pol (she/her) Sounds good!

4️⃣ While not a beta blocker it would be really nice to be able to stabilise Starterkit in time, so we can remove Classy, etc.

Gábor Hojtsy (he/him) This would involve the child issues of #2659890: [Policy] [Plan] Drupal 9 and 10 markup and CSS backwards compatibility
Gábor Hojtsy (he/him) @danflanagan8 was proposing this topic with a specific interest to get reviews on #3083275: [meta] Update tests that rely on Classy to not rely on it anymore
Gábor Hojtsy (he/him) I think at least @mglaman was really keen to contribute in this area.
Gábor Hojtsy (he/him) But there are likely more :)
danflanagan8 It's the kind of unglamorous work I am drawn to for some reason. :slightly_smiling_face:
danflanagan8 It looks like maybe I'd be better off working on 3️⃣.6️⃣ , which is similar but more important
Gábor Hojtsy (he/him) @danflanagan8 yeah that is also useful, that would help us remove Bartik :slightly_smiling_face: which I guess is probably also a pre-requisite anyway to remove Classy, since it depends on Classy
Gábor Hojtsy (he/him) (unless we flatten Classy into it if other core dependencies get removed, which sounds very unattractive :smile: )
xjm @danflanagan8 I actually think this is more important than Olivero
xjm And less glamorous as you mention :slightly_smiling_face: So definitely an area where help is welcome
mglaman I plan on working on the startkit hard soon. Because of my book, and in general it’s a huge experience win. I need to track the other parts which aren’t about the theme generation itself (started on more of that)
danflanagan8 Nice. Maybe I can try to get things moving on the Classy tests then.
mglaman ah yeah, this #3206217: Allow starterkit themes to control how the theme is generated
mglaman Is there any kind of basic scrum for this initiative? I know @lauriii and @mherchel and I had a few talks, that’s about it
mglaman (I know we all don’t need more meetings… but maybe just the #d10readiness meetings on monday suffices?
lauriii I think this is a good place to catch up on
lauriii I already pinged @alexpott about that issue since I’ve discussed it with him earlier
mglaman I saw he :eyes:’d it
Gábor Hojtsy (he/him) @mglaman we already have the Drupal 10 meeting weekly and can raise this as a standing item :)

5️⃣ Increasing SQLite minimum to 3.38?

Gábor Hojtsy (he/him) @daffie raised this #3266764: [11.x] [policy] Treat SQLite as a dev (rather than prod) requirement and allow it to be raised in Drupal minors
daffie @catch Can we talk about this?
catch Yes but probably tomorrow?
andypost Let's wait a week or two if there will be .1 release
daffie Tomorrow is fine and lets wait for the .1 release.
xjm Ooh, we need to be careful about these issues. We told people the SQLite minumum requirement was already finalized.
catch Sorry I meant to come back to this then... didn't. Put a couple of thoughts on the issue, just thoughts nothing concrete really #3266764: [11.x] [policy] Treat SQLite as a dev (rather than prod) requirement and allow it to be raised in Drupal minors#comment-14432534
xjm The person I know who surfaced issues the last time we raised the requirement aggressively (for D9) was Sam Mortenson, but he's mostly not doing Drupal development anymore and I don't know what his usecase was
xjm It also seems awfully short notice to demote it to be dev-only (edited)
daffie The problem is that the added functionality in SQLite 3.38 makes it a lot easier to search JSON field storage data. That is why I am asking for it. See: #3046696: Move from serialized columns to JSON encoded data wherever possible, or use allowed_classes (edited)
xjm @daffie I understand why the issue is desirable, I just don't think we can get away with it for D10
xjm As I stated in my issue comment, the availability of useful features is not what drives our DB support policy and if we wanted to make this change of the "not supported for prod" SQLite driver I think it would need to be a D11 one
daffie @xjm That is fine. Thank you for your time and wait with this one for D11.
xjm We will probably open 11.0.x development in the end of 2023 so it's not all that long of a wait potentially :slightly_smiling_face:

6️⃣ Releasing a version of “Drupal 9” with Symfony 5.4?

Gábor Hojtsy (he/him) Raised by @daffie, see #3266252: [policy] Release a Drupal 9.10 that uses Symfony 5.4 and CKEditor 5, and is supported until 2024
Gábor Hojtsy (he/him) I put “Drupal 9” into quotes in the topic as I don’t think it could semantically be Drupal 9 per say if it would be on Symfony 5.4, but that probably should not stop the discussion by itself :slightly_smiling_face:
daffie I am just worried that after the release of D10 a number of contrib module will need a D10 release. Especially for the by Symfony 6 added return type hints. That will leave site owners ver little time to upgrade to D10. With this "D9" version they will have 2 extra years.
Gábor Hojtsy (he/him) @catch or @xjm would be the respective core committers, but that should not stop others from discussing either :)
catch With return type hints can't contrib just require PHP 8 and be OK?
daffie Not if you are extending a Symfony class that has those added return type hints. (edited)
catch But if you add a return type hints that won't break Symfony 4 compatibility though.
daffie They are required in Symfony 6, not in Symfony 5. There you only get a deprecation warning.
daffie AFAIK an extending class can add return type hints without a problem. We did that in a lot of core issues in preparation for the upgrade to Symfony 6.
catch Yes but you can add a return type hint in a subclass before the parent class does.
catch So modules can support Symfony 6 (at least for this) without breaking Drupal 9/Symfony 4 compatibility.
daffie AFAIK yes, they can.
tr Um.. with caveats.  Some cases require either conditional code or new branches in order to work with both Symfony 4 and Symfony 6. #3252757: Update Drupal 10 to depend on Symfony 6.0#comment-14418128
bircher I think this comes down to "what is the API of Drupal" aka the age old discussion. Because Drupal 9 could require symfony "4|5" and still be semver. I guess the problem is that most contrib/custom don't specify their own requirements explicitly if they implicitly depend on a dependency of core.. But I think the messaging around this should change and we should encourage explicitly defining dependencies when one does depend on drupals dependencies directly. But min-max testing would have to become a thing and maybe there are some tools that can help find such dependencies.
longwave Agree with what @bircher said - but how to get this message across to contrib? And even if we can I am not sure this is achievable this late in the D9 cycle - maybe we can introduce it for D10 but then that doesn't help the problem at hand
longwave "Drupal 9 with Symfony 5" might help contrib, but for end user sites is it worth it, or would we be discouraging users if they have to upgrade to Symfony 5 and then 6 in quick succession? Would it be better to work on automated tools to help with upgrading from D9/SF4 straight to D10?
Gábor Hojtsy (he/him) I think working on automated tools would be better. I updated deprecation status (tool that processes all contrib's upgrade status results) to tell apart third party deprecated API uses detected and symfony was/is not very widely affected.
Gábor Hojtsy (he/him) https://twitter.com/gaborhojtsy/status/1473014759947706369?t=62qnGc4LhHB...
Gábor Hojtsy (he/him) There is a possibility that we are not finding some of them but that it would be a lot more I don't think?
bircher @longwave yes I agree, it is too late for Drupal 9. I meant it is something of a cultural shift we could envision for Drupal 10 or 11. But it comes down to technically Druapl 9 the framework being compatible with Symfony 5 but Drupal 9 the product has as an "API" Symfony 4. I don't know if that is really a problem given that deprecations for symfony in contrib is very low
catch Also no-one has pointed out an actual blocking issue with Symfony 4 to 6 in contrib yet - you can add type hints in Drupal 9, for some type hints you might need to raise your PHP version requirement, but that's still compatible with Drupal 9. If you don't want to raise your PHP minimum requirement, you can conditionally define classes or methods if you really need to. We've added forward compatibility layers for any breaking changes we found in core like the Event class and could add more if they come up. (edited)
daffie If D9.4 will be the last regular D9 release, then my idea was to do a D9.5 release with Symfony 5.4.
catch Right but I still don't understand the use-case or how we'd go about doing it:For contrib, there's no example of an issue forcing a 10.x branch yet that I know of.For sites, we don't want to update them to Symfony 5.4 unnecessarily.We don't have #3020303: Consider using Symfony flex to allow switching between major Symfony versions or min/max testing in place to allow a Symfony 5.4 update in a safe way. If we'd done this before 9.0.0 was released it'd be easier to do something like this now, but it didn't happen.
daffie To me the use case is D9 sites that need more time to upgrade to D10 after D9 has gone EOL. Now with the D10 release date in august, they will have 15 months. That may should like a lot, but they this have to wait for all the contrib modules they are using to be D10 ready. That wait time will be removed from those 15 months. That time can become to short for some sites. A D9.5 with Symfony 5.4 will give them 2 extra years. That to me is the use case.
catch But if contrib has to add Symfony 5.4 compatibility, they might not be able to immediately update to the 'minor' release either.
daffie @catch: You are right about that. Did not think of that problem.
bircher isn't that the same modules that also need to be adjusted for Drupal 10 then? I mean the modules that need to be adjusted to work with Symfony 5 also need to be adjusted for Symfony 6 not necessarily the other way around. So D9.5 with sf5.4 may give some sites more time but not necessarily all of them. I guess the question is what disruption it brings and if 9.4 to 10 is sufficiently easy to make a potentially risky 9.5 obsolete
catch The issue with 8.9 to 9.x wasn't Symfony compatibility, but that there are thousands of unmaintained contrib modules. However things like the permissive packagist endpoint will make that less of a problem this time around. How much less of a problem is hard to tell.
catch The other issue with a 9.5 is that Symfony isn't the only dependency going EOL, so is ckeditor 4 - we can't not ship ckeditor4 in a Drupal 9 version, even if we can (have to in 9.4) ship ckeditor5 as well (edited)
bircher yea the thousands of unmaintained modules is a problem that will not go away no matter what strategy we have for release cycles or LTS versions (also hinting at that issue here because I think that is in a way a problem in the same space as this thread #3238652: [policy] Decide how long major Drupal versions should be supported) (edited)
catch I think if we can get everyone to use >= 8.9 constraints instead of ^8 | ^9, then at least a lot of modules that are really low maintaince would not need it, at the cost of occasionally finding compatibility issues after upgrade instead of before.
bircher I think that is a great idea and one I think we should communicate in various places blogs etc
catch I thought I opened an issue, but maybe not, can't find it now.
catch Opened a new one #3267143: Add a composer plugin that supports 'composer require-lenient' to support major version transitions
xjm We posted an RM decision on #3266252: [policy] Release a Drupal 9.10 that uses Symfony 5.4 and CKEditor 5, and is supported until 2024#comment-14432779 to wontfix that particular proposal. (edited)
bircher by the way I like and respect the decision not to release a 9.10 as described in the issue. But maybe another option is the following:
bircher Release a version of Drupal 9 as it becomes EOL, ie an unsupporded release which relaxes the composer dependencies, "on your own risk" so to say.. or maybe not even a release but a "fork" which allows people to not move to drupal 10 but allows to keep it around..
bircher But also maybe it is worth saying EOL is EOL, upgrade your things in time..
Gábor Hojtsy (he/him) Some release of Drupal 9 will inevitably kick composer updates and update status to tell people to do it. And various people will do it without reading about it assuming it's yet another release and break their site.
xjm I don't see why we should have all the disadvantages of having a release to support until 2024 without any of the advantages.
xjm At Drupal 8's end-of-life, 56% of D8+ sites were still on D8. Three months later, now that we've released a couple required security updates, only 40% of D8+ sites are on D8 and the rest are on D9. That means a third of them upgraded already after three months.There are people who no matter what we do will  not upgrade until they are forced, but from a release management perspective, this is actually going really well and I expect D10 will go even better. My primary concern is for larger sites that need a longer period to upgrade, and whether the 14.5 or 10.5 will be enough for them if they get blocked on contrib.
xjm But I'm not concerned enough to force myself and everyone else to do hundreds of hours of extra work for very little gain.
xjm Symfony deprecations are only 3% of contrib deprecated API uses. Our tools can help them. And they'll be fine.

7️⃣ Tools updates: @mglaman worked on covering a lot more of contrib deprecated APIs in drupal-rector, while Liam Morland did excellent work in finding and fixing various bugs in Upgrade Status recently. Kudos to both!

Gábor Hojtsy (he/him) Also thanks to @agentrickard for reviewing and merging in the rector updates :slightly_smiling_face:
mglaman I was on calls, BUT!drupal-rector should have all of the file module deprecations and othersphpstan-drupal has updated global constantsphpstan-drupal is getting detection rules for the abstract runtimesI’m trying to review CRs to make sure deprecated classes/methods/etc have proper @deprecated tags. Caught one class which was only a runtime deprecations
Gábor Hojtsy (he/him) Woot, thanks @mglaman, I should look to update the list of rector covered deprecation messages in upgrade status and deprecation status. Last I looked there was not yet a release of drupal-rector.
mglaman @Gábor Hojtsy (he/him) ah yeah, it just got released
mglaman https://github.com/palantirnet/drupal-rector/releases/tag/0.12.1
mglaman okay, “just” is last week
Gábor Hojtsy (he/him) :drum:
mglaman I did announce it at FLDC on Saturday as a lightning talk, before the release :laughing:
mglaman I told folks they need to get testin’!
Gábor Hojtsy (he/him) :smile:
Gábor Hojtsy (he/him) Made a reminder for myself to review this tomorrow :slightly_smiling_face:

8️⃣ Thanks all for coming, as we are gearing up for the beta in May, we will now have Drupal 10 readiness meetings every Monday to provide an opportunity to discuss issues. So see you next week! Stay safe!

Comments

Gábor Hojtsy created an issue. See original summary.

Gábor Hojtsy’s picture

Issue summary: View changes

Expanding topics a bit since we already know various things for this next meeting.

Gábor Hojtsy’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes

Fixing thread numbers, sorry.

Gábor Hojtsy credited dww.

Gábor Hojtsy’s picture

Issue summary: View changes

Saving notes.

Gábor Hojtsy’s picture

Gábor Hojtsy credited TR.

Gábor Hojtsy’s picture

Status: Active » Fixed

Adding missing credit. Thanks all!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.