GitLab Acceleration Initiative meeting on 8 September, 2021 [#3231987]

This meeting:
➤ Is for core developers, initiative contributors, the Drupal Association and anyone interested in the initiative.
➤ Usually happens every other Wednesday at 11:00 PT / Thursday 06: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!
➤ Lots of threads get posted all at once! Don't worry - start at the top and then jump into the threads that most interest you.
➤ Has a public agenda anyone can add to in the issue
➤ *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.

Transcript

0️⃣ Who is here today? Comment in the thread below to introduce yourself and tell us why you are joining us- and maybe one fun thing you have planned for the weekend.

hestenet (he/him)	Tim from the Drupal Association - running these meetings for the moment :slightly_smiling_face:
markdorison	Mark from Chromatic. Interested in efforts to further GitLab integration. This weekend I might do some climbing. :person_climbing:
webchick	Angie from MongoDB; interested in lowering the barrier to contributing; I'm not sure if we'll actually participate but there are zucchini races going on this weekend and that just sounds like a blast. :smile: https://www.mcspaddencountyfair.ca/zucchini-races
moshe	Here ... Will do a longer open water swim this weekend
tim	Tim here helping to migrate data. .Maybe test
larowlan	Lee, this weekend hoping my daughter's team wins the Div 1 ladies :soccer: final
bradjones1	Joining very late, mostly reviewing everyone's notes and chiming in with some random thoughts. I'm in Ogden, UT this weekend so exploring a new town to me.

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.

webchick

DrupalCon / The Driesnote is coming up soon(ish), is there a particular target we're trying to reach with this initiative before then, and how can people help?

markdorison

I’d like to bring up this issue again: Gitlab MRs are unsuitable for use with Composer PatchesI think it should either be renamed/refactored to not be directly related to a particular workflow/composer patches or a new ticket should be created around improving tthe experience of accessing MR patches regardless of workflow:It would be really fantastic if we could make it easier to obtain the patch file when an MR is submitted or updated. Is that something that is possible/feasible? I am imagining a patch file being included in the activity data that is already coming back from GitLab to the issue with each commit.

2️⃣ Enabling GitLab pages for our friends in the Decoupled Menus/Javascript project space.

hestenet (he/him)	With the help of Tag1 and specifically @nnewton we have this work prioritized and will try to make progress in the coming weeks.
hestenet (he/him)	I think DCON Europe (Oct 4-7) is probably not out of reach? But we'll see.
webchick	What's the context for this request?
hestenet (he/him)	So what we've already done with the Decoupled Menus Initiative team is enable additional features of 'vanilla' GitLab for them to use 'out of the box'
hestenet (he/him)	One we already did was enabling GitLab CI/Pipelines so they can do NPM publishing.For this one they requested was GitLab Pages to use for developer/api style documentation. (end-user docs should still be in drupal.org guide content types, I firmly believe)
hestenet (he/him)	This is on the path towards 'allowing some projects to start trying this out more unconstrained'
hestenet (he/him)	When we're a little closer @larowlan has volunteered to try running a few contrib projects in a 'pretty vanilla' state.
webchick	Ok, that's awesome!

3️⃣ Update on migrating user stories into GitLab

hestenet (he/him)	Thanks to some tremendous and time consuming work by @tim - most of the user stories from the Google doc: https://docs.google.com/document/d/18VOCpmDRljM2845Fz0nFFWbR8xL4IDMtDIH-... our GitLab project: https://gitlab.com/drupal-infrastructure/gitlab-acceleration/user-storie... need to collectively do some triage/labeling/and update the associated kanban board so everything makes sense:https://gitlab.com/drupal-infrastructure/gitlab-acceleration/user-storie...
hestenet (he/him)	@webchick it would be wonderful if you could help skim and make sure that the key information did actually get captured and carried over from the doc
hestenet (he/him)	and @tim maybe you can summarize the progress you made and what is still to do
webchick	On it! And @tim WOW! Thank you SO much for all of your amazing work here. :heart:
webchick	@tim What's your twitter username? I can give you a #DrupalThanks shout-out! :slightly_smiling_face:
webchick	Oh WOW you even brought over the images in the Google Doc! :open_mouth: e.g. https://gitlab.com/drupal-infrastructure/gitlab-acceleration/user-storie...
tim	I dont have a twitter account. :)
webchick	Oh ok. :slightly_smiling_face: Well thank you nevertheless!! AMAZING work!
tim	yes I would love to make sure all was moved properly and even more what still needs to be done past the gdoc
tim	We (including @quietone if wanted) need to finish TOC maybe if you think its needed.
tim	Questions in doing the types of links in the TOC (table of contents). Look at what was done so far. Which link style is preferred? https://gitlab.com/drupal-infrastructure/gitlab-acceleration/user-storie... (edited)
webchick	Hm. My initial reaction is I think the TOC is probably less useful when each user story is broken out into its own ticket, with its own metadata. People can just use filters/search to find them.
webchick	That document was an extremely clunky "information purgatory" thing since at the time it was created we didn't know where we would be tracking this effort (that's since been resolved)
webchick	So going forward, I would expect we don't use the doc at all, and instead add to/modify/comment on the user story tickets themselves. (edited)
tim	@webchick I did have a question on 1 or 2 issues. I marked those with followup label
webchick	Oh, let me take a look... https://gitlab.com/drupal-infrastructure/gitlab-acceleration/user-storie...
webchick	On https://gitlab.com/drupal-infrastructure/gitlab-acceleration/user-storie... I can sketch out some basics... they will not be 100% right but somewhat in the ballpark. Someone from the security team would be good to vet that one.
tim	i put in a comment
webchick	Yeah, on that one I don't think we need a link... they're not related. It was more saying "Don't assume that a maintainer is doing all of this front to back... it bounces around between unknown weirdo, maintainer, and sec. team member"
webchick	@tim Ok, does this make more sense? https://gitlab.com/drupal-infrastructure/gitlab-acceleration/user-storie...
tim	To summarize what I did - I created a new issueCopied title from gdoc to new issue.If the issue had 'new' content ie wasnt a repeat cause some looked like a template, I copied issue data to issue. If content was template I would copy from another tab that I kept open to html of an issue that had been previously formatted correct. Since doing it that way Ifound a better way using macros that @webchick had documented.I typically go through marking bold, ul and ol , adding images, and making sure links workedAdding labels as appropriate.Helpful markdown that I used** To bold# For headings- For ul 1. For ol\ For escaping or forcing newlineGitlab documentation for their custom html is good.
webchick	Oh that's fantastic. :slightly_smiling_face:
webchick	Sorry, I don't quite parse this comment: https://gitlab.com/drupal-infrastructure/gitlab-acceleration/user-storie...
tim	For https://gitlab.com/drupal-infrastructure/gitlab-acceleration/user-storie... proper edict I can remove or delete my comment?@webchick
webchick	@tim We can remove the tag, if you feel it answers your concern.
webchick	Ok, went through that list of follow-ups and got rid of the ones I could.
webchick	The remainder actually do need follow-up and I'm not well-positioned to do that right now
webchick	Spot-checking, these all look perfect to me (using a macro was a great idea, glad the document was well-formatted enough to support that) and if there are 1-2 missing/messsed up, I'm sure we can fix them in post. :slightly_smiling_face:
webchick	@hestenet (he/him) What do you see as the next step here? Should a group of us get on a zoom for an hour or so and slot those into their appropriate buckets on the kanban board?
tim	Regarding https://gitlab.com/drupal-infrastructure/gitlab-acceleration/user-storie... the tiny link at the end?We. Or I could change that so that the whole title is a link.Advantages to having whole thing underlined: easier friendlier for the user. The link is bigger.Advantages to keeping it like it is right now: Currently it is using gitlab markdown to link link to the other issue. If things were to change in the future hopeful this link would follow if it moved.Which way is preferred?I tried I wasn't able to use markdown and link the whole title, the best of both worlds.If you want an example of the 2 styles I did both styles in the TOC issue .... Although we might not be doing that now... But you can see as an example.
tim	I removed the tag. Feel free to remove tag if you think its good for others.My question is more is it bad to remove my comment?
hestenet (he/him)	@webchick Probably yes
tim	@hestenet (he/him) Small thing should we modify the show stopper label to be like the priority labels? With the priority labels you can only pick one. The same should be with show stopper label.
hestenet (he/him)	:thinking_face: Hm - maybe
hestenet (he/him)	But maybe we want to know both if something is a 'show stopper' and also if it is low med or high priority
hestenet (he/him)	Need to pay around with a few of these now that they are in there.
tim	Ok maybe. Maybe should look at changing the low or high. Can look at in time....Sorting issues wont be an issue if we dont have a TOC :)
tim	Oh totally forgot @webchick @hestenet (he/him) there is a section in the gdoc near security section that just had regular text, outside of an issue. This has not been ported over yet. Also the text that is currently in TOC I will rename the title to whats this and constraints? Remove the links to the user stories at the bottom??
tim	Just maybe add the security section into the above, then its included. Add security to the title...?
larowlan	awesome work here folks

4️⃣ A goal last week was to try and break the 5 'Targets' from the meta broken down into individual plans and next steps: [#3227737]No real progress there just yet - certainly open to raised hands on this one too :slightly_smiling_face:

5️⃣ DA capacity support. We've been putting out contracts for dev resources and a project manager to help manage internal DA priorities, so we can help focus more of @drumm and @mixologic’s time on this initiative specifically, and so that the new PM can help me out with managing the scale of a project this large.Not too much more to report yet, but letting folks know this is happening.

webchick	Is there a job posting we can help promote, or similar?
hestenet (he/him)	That was a while back - so we're in final interview stages.
hestenet (he/him)	One dev contract offer made - another coming up - final rounds of PM interviews - getting close!
webchick	Oh wonderful! :smile:

6️⃣ DrupalCon Europe is less than a month a way - what milestones do we want to reach and what do we want to be able to talk about?

hestenet (he/him)	Raised by @webchick
hestenet (he/him)	I think some key elements are:What is the plan we've developed? What are some of the key personas whose use cases we are considering, and what are the show-stopper edge cases that we can reassure the community we are thinking about solvingHave we made any incremental wins? What are the upcoming next steps - how can other folks get involved? (contrib beta testing?)
webchick	That sounds like a great list. :slightly_smiling_face:

7️⃣ GitLab is not moving very quickly yet on providing a contribution attribution feature - despite a pretty well defined feature request.We have two options:Begin writing an alternative - a bot that posts to closed MRs/Issues on GitLab and creates a 'credit node' of some kind where attributions can be added. Find some ruby talent and attempt to contribute upstream.

hestenet (he/him)	Dries has also offered to directly reach out to Syd if we can define exactly what we're asking for - and ask them to fund us to do the dev work. (i.e: Fund us to hire a ruby dev to build it exactly the way we need it)
webchick	Should we find such a magical Ruby-knowing person, just a note that GitLab has a Hackathon happening in a couple of weeks: https://about.gitlab.com/community/hackathon/
webchick	This is an opportunity to have "face time" (over text :smile: ) with their product/dev teams
webchick	So might be a good place to advocate in a "richer" context for that feature, and/or at least get a roadmap of what the steps would be.
moshe	I vote for 1, because 2 will never be high enough of a priority for Gitlab IMO.
hestenet (he/him)	I'm worried that you're right - despite the encouraging noises we hear from them, I'm getting more skeptical about it bubbling up.
bradjones1	Is there anything like this bubbling up in other communities? I wonder if there isn't some sort of bot/starting point found elsewhere on that front? E.g., if it can be parsed from git commits or something that isn't GitLab/Drupal domain specific this seems like the kind of thing that could be open-sourced itself, independent of Drupal
bradjones1	(That is, option 1)
hestenet (he/him)	Not that I've yet seen, but to be fair I haven't looked too deeply.
moshe	Follow github link from https://gitlab.com/gitlab-org/gitlab/-/issues/20421 (edited)
bradjones1	Totally a wild guess but I think if there is already some ruby involved in doing the squash with git fundamentals that adding that specific co-authored-by feature might not be a super heavy lift
bradjones1	Since it is already generating a proposed merge commit message
webchick	You know, I was pondering on this. I kind of think we need to do #1 either way...There are many, many activities done in the Drupal community that we would like to capture and give credit for that have _absolutely nothing_ to do with contributing to code, and trying to shoe-horn things like board meetings or event planning or, heck, even meeting attendance :slightly_smiling_face: into that system vs. one of our own devising specifically geared towards capturing the full breadth of technical and non-technical contributions seems like an uphill battle. (And has been to date, trying to tie it to issues in our issue queue, which is basically a different flavour of shoe-horn.) (edited)
mixologic	^^ this 1000%. Initially the crediting system was built around issues because it was the low hanging fruit, and a way to prototype/prove that crediting matters, and works. Now that we know its something we dont want to live without, and that we’re undergoing ways to expand it, it makes sense to design this as a separate system entirely that is able to consume various types of activities from various sources.
bradjones1	Is there anything in particular blocking this from being decoupled from primary tooling? E.g., some sort of tote-board that can consume data from "wherever"? Pluggable sources that are identity-aware?

8️⃣ Static patch artifacts for use in deployment workflows- i.e: this issue: Gitlab MRs are unsuitable for use with Composer Patches

hestenet (he/him)	raised by @markdorison who says: I think it should either be renamed/refactored to not be directly related to a particular workflow/composer patches or a new ticket should be created around improving tthe experience of accessing MR patches regardless of workflow:It would be really fantastic if we could make it easier to obtain the patch file when an MR is submitted or updated. Is that something that is possible/feasible? I am imagining a patch file being included in the activity data that is already coming back from GitLab to the issue with each commit.
hestenet (he/him)	I have really strong architectural opinions that hotlinking to externally hosted patch files is bad even if their contents are static - but I know that people have been doing it for more than a decade on Drupal.org - so I may have to resign myself to coming up with an alternative.
hestenet (he/him)	The trick is- if we're moving away from d.o issues - we don't have a place to generate our own static patch file and attach it to, really... What's the alternative that uses 'off the shelf' gitlab tooling?
markdorison	That’s what I am trying to separate this from. Right now, even if you want to grab the patch and track it locally, the current workflow makes that very hard.
moshe	This is an issue that I think Gitlab is incentivized to work on, and its not that hard
drumm	Add .patch or .diff to the merge request URL. There are a couple links to those on the merge request page. If you are patching your codebase, you should be skilled enough to save that locally.
moshe	@hestenet (he/him) A culture of checking in patches into your codebase leads to companies not sharing their patches even more than today.
markdorison	It’s one thing to get the patch if the MR has just been created or you are the one who created it, but if I show up in the issue months later, and there are multiple commits from multiple people on an MR, it is currently very hard to get a patch that doesn’t include all of the commits. (edited)
moshe	Oh yeah, a squashed patch would be nice
hestenet (he/him)	Cherry picking a patch from a particular compare (as per the GitLab issue you opened Moshe) would be the ideal.
hestenet (he/him)	I linked to that and a few related/dupe issues here: https://gitlab.com/gitlab-org/gitlab/-/issues/293749#semi-urgent
drumm	Either way, I certainly don’t think we should consider any workaround tooling to save patches somewhere.
hestenet (he/him)	But I think your issue descibes it best: https://gitlab.com/gitlab-org/gitlab/-/issues/217206 (edited)
hestenet (he/him)	@drumm Agree
hestenet (he/him)	The whole point is to avoid special snowflaking the architecture - so if this is one that really makes sense upstream (and it does) than we need to push them on it.
markdorison	ok, that makes sense to me.
hestenet (he/him)	The credit thing is the one that's probably unavoidable (but that's the other thread)
markdorison	I would propose that this issue be re-titled/updated to try to force it away from the workflow/hot-linking discussion as this problem exists in many cases even if you want to obtain a patch file to track locally. Does anyone have a concern with that?
drumm	(Another approach might be teaching composer patches to stash a local copy of the diff. Or have the Drupal Composer scaffold detect known anti-patterns in your composer.json)
hestenet (he/him)	@markdorison - no objection - maybe if you do update title update issue summary to Moshe's open issue at GitLab as the proposed resolution.
hestenet (he/him)	(The one linked above)
markdorison	OK. I will try to take a pass at this by the end of the week.
markdorison	Which issue is the “Moshe” issue. I don’t think either one linked here was created by him.
moshe	See 3rd issue at https://gitlab.com/drupalspoons/webmasters/-/issues/17
hestenet (he/him)	Oh yeah - I linked the wrong one above.
hestenet (he/him)	https://gitlab.com/gitlab-org/gitlab/-/issues/217206
markdorison	Thank you both!
larowlan	Either way, I certainly don’t think we should consider any workaround tooling to save patches somewhere.agree 100%
larowlan	save the patches locally and ensure you're not vulnerable to supply chain attacks
darvanen	Having the ability to export a patch off a particular comparison would really streamline rescue operations on MRs that have become corrupted. (example: #3008292: ImageItem::getUploadValidators() should be the source of truth for validating uploaded images#comment-14212891)though... granted, we could just publish the method for getting such a patch if it's always repeatable.
drumm	I have a git command alias set up to have the tree view of the commit log easily accessible, GitLab’s commit graph https://git.drupalcode.org/issue/drupal-3008292/-/network/3008292 works too. That makes finding the commit id of the branch point, or when commits started diverging, easy. So can git diff with that id, rather than getting some other branch into a specific state.
bbrala	I'd like to share a thread on this, it seems you can create a static diff using diff it's.https://drupal.slack.com/archives/CGKLP028K/p1630925187033500?thread_ts=... (edited)
darvanen	@bbrala but that only works for the current revision, next time a commit is pushed, that diff is going to change.
bbrala	@darvanen If you into the thread i end up testing force pushing and using the original diff_id that still results in the original patch.
Bevan W	Relevant gitlab docs. .though they lack the detail of adding .patch - this documentation outlines our merge request versions work.https://docs.gitlab.com/ee/user/project/merge_requests/versions.htmlIt does no definitively answer the question as to whether those diff versions can be changed by using a force push. If a version of a mr diff can be modified that way it's probably worth considering it a bug in gitlab and opening an issue with them too.