Automatic Updates Initiative meeting on Feb 7, 2023 [#3340048]

Transcript

0️⃣ Who is here today? Comment in the thread below to introduce yourself and tell us why you are joining us.

tedbow	Ted at Acquia from Ithaca, NY
wimleers (he/him)	:wave: Wim at Acquia from Ghent, Belgium :european_castle:
tedbow	making a coffee then have a couple topic to post

1️⃣ Do you have any topics to propose for the meeting today? Feel free to propose them in this thread, and then I will give them their own unique threads for discussion. Conversation moving slow? Go ahead and open your own thread in the next numeric order.

wimleers (he/him)

Status for the signing support of packages on d.o? :nerd_face: Status for the JSON:API endpoints that Project Browser needs?:point_up: The answers to these determine if we should try to get Automatic Updates or Project Browser in core first.Or maybe that usually happens in a different venue?

2️⃣ Summary of recent changes/news about php-tuf and composer? Could someone summarize the recent stuff above?

tedbow	@phenaproxima php-tuf ?
phenaproxima	We did a pretty big internal refactor
phenaproxima	The hope is that it’ll open up more testability

3️⃣ Progress on Automatic Updates contrib module.....

tedbow	Been working on issues related to [meta] Attempt to remove our runtime dependency on composer/composer (can probably remove "Attempt" now)#3335908: The 'fake_site' fixture cannot be using with `composer show` because the packages are not installed means now the text fixture for our kernel and functional test is made from an actually composer install which means we can run actual composer command on it to get config and installed packagesSo I am moving on to #3334994: Add new InstalledPackagesList which does not rely on Composer API to get package infoand removing instances in ongoing issue to ensure we use the our New ComposerInspector which runs composer config to read config instead of the Composer php API
tedbow	Fixed Limit trusted Composer plugins to a known list, allow user to add more which ensure random Composer plugins don't interfere without staged composer operation workflow
tedbow	Create a follow-up to determine what support other Composer plugins would entail Determine how new Composer plugins will be supported

4️⃣ Rugged/TUF infrastructure side - signing support on d.oThis should be able to get some more attention soon, with more recent fires more put out. Round 2 of the grant application questionnaire was submitted. (edited)

hestenet (he/him)	Maybe @drumm can speak to where he's looking to pick this back up and what his next steps will be
hestenet (he/him)	On the funding side (which again, is hopefully to support a security audit as well as any more dev/support time from consensus) we're currently just waiting on next steps from the grant foundation.
wimleers (he/him)	@effulgentsia :point_up:
drumm	I’m expecting to pick this back up this week
drumm	I’m resuming from this thread & documentation, https://drupal.slack.com/archives/C7QJNEY3E/p1672952656411169?thread_ts=.... The 4 milestones are: zip files going in to get signed, making that signing accessible somewhere, Composer metadata going in to get signed, making that signing accessible somewhere
drumm	And at least 2 phases of shifting from production to prodMove from staging packaging to production. We want to exercise this with normal loads, that’s productionFresh TUF root keys generated securely

5️⃣ JSON endpoint for project browser

hestenet (he/him)	@fjgarlin can likely speak to this (there's probably a recent update somewhere in the backscroll of #project-browser )We are using the events.drupal.org and api.drupal.org d9/d10 deployments to validate our modern drupal hosting infra and our CDN strategy for routing some paths to the new site/service, and some to the old site/service. I think we'd be working towards that endpoint release immediately following. (edited)
wimleers (he/him)	@timplunkett (he/him) :point_up:
wimleers (he/him)	@effulgentsia :point_up:
fjgarlin	Correct. Once events and api are live we’d be in a much better position for the d.o new endpoint. The set up is a bit more complex (ie: migrations) but those two will defo open the way. (edited)
hestenet (he/him)	This meeting:➤ Is for core developers, initiative contributors, the Drupal Association and anyone interested in the initiative.➤ Usually happens every other Tuesday at 1700 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➤ Transcript will be exported and posted to the agenda issue. For anonymous comments, start with a 👤 emoji. To take a comment or thread off the record, start with a 🚫 emoji.

6️⃣ Starting to think about [3.x] Make breaking API changes in 8.x-3.x (+ adopt PHP 8.1-only capabilities + require Drupal >=10)

tedbow	The idea would be that the 3.x would be mostly for getting ready from Drupal core.We have made deprecations in the 2.x branch that would not to make sense to bring into coreSo 3.x would beremove all deprecationsonly support php 8.1 - core 10.1 requirement and php 7.4 is EOLThe current plan we would not make a releases on 3.x until we get into core. We may look into making releases if we don't get into 10.1.xwhen we get into core we could release 3.0.0 that would require core's package_manager (which is currently a submodule) and only provide functionality not provided by core
tedbow	Honestly I think we would develop faster in 3.xsince we are not making releases we would never have to pu any new BC layers inWe would not have to support php 7.4 and we could worry less about our 9.5.x tests failing
tedbow	To be clear if we switched to 3.x we would probably stop developing 2.x and it would get very little attention except for security fixes.but we only have 130 sites using it. And we very rarely get any bugs from users. I think we are getting such low numbers because what people really want is cron updates which we can't give them now

7️⃣ If anybody has seen this problem Recurring random failure in caused by "PHP temp directory (/tmp) does not exist or is not writable to Composer." in kernel testsit only seems to happen on Drupalci

tedbow	It started to happen when we switch to running a composer config process to determine config instead of Composer's PHP API.
tedbow	I am guessing it has something to do with kernel test running in parallel on drupalci
drumm	I recommend switching to GitLab CI
tedbow	but I thought core won't be on gitlab CI probably before we want to merge into core so any changes on in our test suite that would only work on gitlab CI would have to be reversed before we mergewe also won't know if our tests would pass on drupalci
drumm	Ah, I forgot about the core requirement.
drumm	Random failures that seem like GitLab CI like this are going to be really hard to get worthwhile time on.
hestenet (he/him)	^^ Like DrupalCI rather.
hestenet (he/him)	Oof this is an annoying one isn't it?
hestenet (he/him)	I haven't seen it before for sure.. .
tedbow	we probably run Process more that a lot of code
tedbow	but we were asked not to depend on compose/composer so calling composer process is what we have
hestenet (he/him)	Gotcha..
hestenet (he/him)	It's not obvious to me how to solve for this - but I will try to noodle on it. If you have any directional ideas I can try to follow those thoughts down... hm..
tedbow	I haven't had a chance to look into but I will post what I find here
hestenet (he/him)	'k - I'm following the issue now as well, so should see any details you post