There's LOTS of cruft left from the days of yore, and there's also some remaining cleanup/finalization to be done following the refactor, which was a bit rough around the edges. This is gonna be a touch of a meta issue until I finish up the high-level visioning that I've been working on this week. Will have those details posted here after the weekend.

Comments

marvil07’s picture

marvil07 commented

I am really interested on those details :-), since we need to clean this until it is ready

sdboyer’s picture

sdboyer commented

OK, I ended up making an enormous post on my blog that, towards the end, lays out the remaining things we really need to tackle. Let me just copy in a bit of that here:

* Maintain repository list - check. VersioncontrolRepository(Controller) has probably gotten more love than any other class. One major addition would be support for incorporating a backend-specific repo interaction classes, along the lines of svnlib or glip. That would make VCAPI into an excellent platform for doing repository interactions that are way outside the original scope; just load up the repository object from VCAPI, then go to town.
* User mapping - unfinished - VersioncontrolAccount is one of the classes has barely been touched thus far.
* ACLs - unchanged since 1.x, and in need of revisiting in light of all the other changes; best addressed at the same time we're revisiting VersioncontrolAccount.
* Repository content tracking - almost there. We're going to undo a conflation made in 1.x; see these issues. VersioncontrolOperation will go away in favor of
* Repo content<->user link - check. Despite the need for cleanup on VersioncontrolAccount, I believe this linkage is 100%.
* Sane defaults + backend overridability - check, thanks to the move to good OO patterns.
* Third-party utility - getting there. The advent of the OO API makes navigating VCAPI's internal datastructures much easier, but we still need to think about where & how we allow for alteration. Y'know, where we put our alter hooks.
* Admin UI - not yet. We've backtracked from 1.x a bit, taking out some of the more hardcoded UI elements and are fixing to replace them with more flexible pieces. For the most part, that means building lots of Views, e.g., this issue. As with everything else in VCAPI, some of the difficulty comes in offering a dual-level API - one to the backends, the other to third parties.
* Portable UI elements - zero. We're not going to provide a single block via hook_block() if we can at all avoid it. Views-driven all the way. Complicated, though, because the 'dual-level API' problems mentioned under Admin UI very much apply.

What's now emerging in 2.x is a layered, intelligible API that is thoroughly backend-manipulable, while still presenting third-party code with a consistent, usable interface. And with a repo interaction wrapper like I described above, VCAPI would be a launching point for the "deep integration" we all want. We're not there yet, but we're getting close. There's a general, central push to get a LOT more test coverage (especially testing sample data & standard use cases), without which we'll just never _really_ be sure how well the monstrosity works. There are still some crufty areas - "source item" tracking, "authorization method" for repository account creation - that we need to decide whether we discard, leave, or improve. And we need to come up with a consistent pattern for implementing dual-level Views: every backend needs to be able to generate a list of repository committers or an activity stream, for example, but each backend may be a bit different. So VCAPI provides a sane default, which can then be optionally replaced by a backend-'decorated' version.

That's not a bullet list of TODOs, per se, but it covers all the bases I can think of. What have I missed?

sdboyer’s picture

sdboyer commented
Status: Active » Needs review

Marking needs review, need some feedback & comments on this.

marvil07’s picture

marvil07 commented

Great for the write up again :-)

Well, I'm ok with your targets, I just want to map them to issues if possible ;-)

* Maintain repository list - check. VersioncontrolRepository(Controller) has probably gotten more love than any other class. One major addition would be support for incorporating a backend-specific repo interaction classes, along the lines of svnlib or glip. That would make VCAPI into an excellent platform for doing repository interactions that are way outside the original scope; just load up the repository object from VCAPI, then go to town.

I think we're ok for now with controller classes, and I second that this make the difference as it tries to unify the behaviour of all classes.

* User mapping - unfinished - VersioncontrolAccount is one of the classes has barely been touched thus far.

Yep, that class need attention, but maybe we should rely on other modules that let extend it, and we should just make a simple abstract map method(that could be our default, like it is now: 1-to-1 mapping for users based on the email, at git backend): #720664: Create a "ssh_key" module, to allow upload of SSH keys to drupal.org user profiles.

* ACLs - unchanged since 1.x, and in need of revisiting in light of all the other changes; best addressed at the same time we're revisiting VersioncontrolAccount.

Completely related to the last on, the relevant issue: #223891: API change: make authentication management pluggable

* Repository content tracking - almost there. We're going to undo a conflation made in 1.x; see these issues. VersioncontrolOperation will go away in favor of

Maybe there is a piece that was cutted-off here :-p

See #879600: Meta: introduce an activity stream separate from commit logs and #879730: Replace the entire VersioncontrolOperation "subsystem" with VersioncontrolCommit

* Repo content<->user link - check. Despite the need for cleanup on VersioncontrolAccount, I believe this linkage is 100%.

See issue at ACLs section

* Sane defaults + backend overridability - check, thanks to the move to good OO patterns.

\o/

* Third-party utility - getting there. The advent of the OO API makes navigating VCAPI's internal datastructures much easier, but we still need to think about where & how we allow for alteration. Y'know, where we put our alter hooks.

IIRC hooks are completely documented, maybe we need a propper issue to review them.

In the other side, for details about the identification crisis about hooks and interaction with backends, there is a list in the presentation I made for a blog post some time ago, but I think it is still updated since we did not change the interaction points(see specially slides from 9 to 11).

* Admin UI - not yet. We've backtracked from 1.x a bit, taking out some of the more hardcoded UI elements and are fixing to replace them with more flexible pieces. For the most part, that means building lots of Views, e.g., this issue. As with everything else in VCAPI, some of the difficulty comes in offering a dual-level API - one to the backends, the other to third parties.
* Portable UI elements - zero. We're not going to provide a single block via hook_block() if we can at all avoid it. Views-driven all the way. Complicated, though, because the 'dual-level API' problems mentioned under Admin UI very much apply.

Now that the base views integration is in place, we only have the family of issues about views integration:

- #781400: Create a per-repository commit view
- #781398: Create a per-user commit view
- #782618: Create a global git commit view
- #854926: Replace admin/project/versioncontrol-repositories/list with Views-driven UI

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Issue tags: +git sprint 3
sdboyer’s picture

sdboyer commented
Status: Needs review » Fixed

That's an excellent summary of what all needs doing here, thanks marvil07. What you've listed there kinda breaks down into three groups - creating the UI, fixing operations, and account/auth-related issues. For sprint 3, we're tackling the first two. We'll go after the account/auth-related issues in the next sprint when we're getting towards the project* integration, as that brings us a little closer to having to care about users.

Marking this fixed, as it was never intended to be anything more than a meta-issue.

Status: Fixed » Closed (fixed)
Issue tags: -git phase 2, -git sprint 2, -git sprint 3

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

Issue tags: +git phase 2, +git sprint 2, +git sprint 3

Restoring issue tags, see #2125755: System messages removed all issue tags during D7 upgrade.