[Core Committers] Meeting notes 2019/06/06

Attendance

• @larowlan
• @webchick
• @lauriii
• @pameeela
• @alexpott
• @Gábor Hojtsy
• @effulgentsia

Experimental APIs in core

Interesting workarounds in this issue #3047812: Add a Config Transformation event dispatching during config import and export
We're trying to change parts of CMI, but these are parts of Drupal\Core\Lib. We can't do that because this is an experimental module that we need to be able to turn off. So we're using PHP's class alias feature to make it appear as though the module classes are in the core namespace. The idea being a contrib module could rely on these classes in core via that module and then they can continue to work if the API moves into core.
We should document this as an addition to the experimental modules policy.

Action

• Lee will open an issue to discuss formal agreement on this approach with the view of putting it into the experimental modules policy.

RTBC queue velocity

@Sam152 had commented in an issue that queue velocity feels slow because of the RTBC review velocity. This reflects other contributors feeling too.
The reasoning is multi-faceted:

• Availability
• RTBC triage doesn't happen outside committers, so someone looking through the queue and saying 'this is for Angie' and notifying her would really help
• In addition someone flagging a general RTBC queue health would help
• Each committer has defined responsibilities and initiative focussed work tends to float to the top
• Perhaps we need someone whose role is to commit the stuff that doesn't fall under an initiative and can focus solely on those issues
• Some issues have a nuance that might be concerning but that isn't communicated clearly within the team. At the time of review, you might have a gut-feeling something is wrong but at the time you don't have the emotional resources to convey this at the time, so it is deferred. I.e. the time required to craft a reasoned response is prohibitive relative to the importance of the issue - but someone has worked on the patch and this is your motivation.
• Another issue is the volume of point releases has lead to a larger volume of freezes, but also has reduced our RM capacity
• We should consider never freezing the development branch, even in security release scenarios as it can be done in public later.
• We should consider letting git handle re-rolls on patches when we attempt to apply patches where a minor change causes a conflict. This doesn't mean everyone should do it, but we should allow it as a possibility. Nothing worse than a bug staying open for two years on a re-roll.
• Perhaps we need a bot that auto-posts in d8-triage if an issue is RTBC > 2 weeks that triggers a thread discussion to articulate what hold up is. We can do this manually in the first instance.
• We agreed to trial this approach with the list in the spreadsheet above.

Action

• Lee to document what this slack thread convention might look like. This should allow for searching (because URLs don't).

Jquery UI

Ref: #3051352: [Plan] Remove unused jQuery UI components and replace with a suite of contrib packages for the continuous upgrade path
Do we need an initiative for this if its critical to Drupal's security?
Do we need more visibility from Dries?
Revisit after Jess’ keynote at dev days
Rename issue to make it clear that it’s a blocker for D9
Consensus on the call was that trying to remove jQuery.UI is a critical blocker to Drupal 9, based on the current information available.