The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.We need a generic log parser interface, and to move all the log parsing 'work' into classes implementing the interface. They don't necessarily need to be ctools plugins, but I do want them encapsulated.
The other piece of this then is moving what remains in versioncontrol_git_repo_manager into worker-oriented code, as was already done with the repomgr plugins.
I've already begun work towards this in the generic-parser-framework branch.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 1092062-generic-reposync-coding-style.patch | 2.04 KB | Niklas Fiekas |
Comments
Comment #1
sdboyer commentedNote that I see this as a release blocker, as we need the functionality in that repo_manager submodule to be moved somewhere, and this is the only logical approach I can think of.
There are reasons this is just a *good* idea in general, but that's what makes this a blocker.
Comment #2
sdboyer commentedStep one - update the title to the new naming scheme reflected in the ongoing work. Yeah, there's a topic branch I'm working on for this.
Comment #3
sdboyer commentedOK, the topic branch (generic-parser-framework) is pretty much ready to be merged in. I want to wait until the relevant work in the git backend has been done before merging it in, though. "Relevant work" encompasses two issues:
In the meantime, though, the topic branch could definitely use review. It's been stop-and-go development, so it's quite possible that I've missed something.
Comment #4
marvil07 commentedwill take a look at it soon, tagging and assigning to avoid forgetting it
Comment #5
marvil07 commentedfirst thing to do for 6.x-2.0
Comment #6
marvil07 commentedI finally read through the commits on the topic branches(see that with the name update, we are refering to
generic-reposynctopic branches) here and on git backend. I can say it totally makes sense :-)I still need to try it(sadly I could only read it), but I am really glad we are taking a good direction. New developers arriving here will thank this because the way this is implemented follows the pattern of other plugins inside the api.
Moving back to Sam, since IIRC he will be taking a look at these on weekend again.
Comment #7
Niklas Fiekas commentedI read the diff, too and found only the minor coding style issues the attached patch fixes. Do we need to add another update function clearing the autoload cache?
From what I've heard and read the Versioncontrol API part is ready. The real work is left in the Git backend.
Comment #8
Niklas Fiekas commentedComment #9
Niklas Fiekas commentedAnd tagging.
Comment #10
marvil07 commentedI have been looking at the generic-reposync branch changes today again, testing them more, and after several changes(on vcgit) I have merged this, including the last patch mentioned here into 6.x-2.x.
I am closing this, since the big change is merged.
Please open other issues if necessary.