Lassie goes for a walk! (dog Roadmap)

Since the authorship changes on edit, please note: this was originally written by sdboyer, so first-person pronouns refer to him. He prefers IRC for talking about dog - use #drupal-vcs or #drush

After the dog BoFs, discussion, and presentation at Drupalcon London, it seems to me to be a good time to put a real roadmap out there for dog. There are a ton of people interested in helping, and given that the project is only just now emerging from its prototype phase, the only way we can all really coordinate efforts is if we're working off roughly the same game plan. The purpose of this roadmap is to roughly outline that which is required to bring dog to a functioning, 1.0 (or at least RC) release.

Architectural notes

The task that dog is trying to solve requires it to be rock solid. Which, to my mind, is impossible unless you're building on a good architectural foundation. And everyone's got ideas about what that looks like...but since this is my (sdboyer's) house, I get to make the rules in this case :) With that in mind, some quick notes to folks who want to contribute:

• I'm applying the-same-or-stricter requirements wrt code documentation on patches: if you haven't written a standard-form docblock, including typed parameter and return values, your patch will not go in.
• Inversion of control (hooks) is a great pattern, but it is not the be-all-end-all. In particular, it is essentially impossible to definitively know the state of the system when you access it via hooks; at best you know what it should look like, but you have no control over other things that might be altering the system, too. It's also impossible to see all the logic that goes into a particular component in a single location. Put another way, hooks are great for altering, but absolute shit for building. dog's goals dictate that a site owner has clear and unambiguous control over certain build processes. So while we'll be doing a bit with hooks in some places, we'll be relying instead on OO patterns for most of our flexibility: composition & strategy patterns, extension and dynamic autoload discovery, and the like.
• dog copies its own full lib tree into a site tree as part of the dog-init process. This ensures that a) all users need only have drush installed locally, not dog and b) that everyone working on a dog project will be using exactly the same version. This is actually a pretty big benefit for us while we develop dog, since it means we don't have to be as concerned about breaking shit with our changes.
• dog uses a PSR-0-compliant strategy for arranging its classes. It's what all the cool php kids are doing nowadays.

Work I need to wrap up

There are a few architectural pattern-defining things about dog which I unfortunately wasn't quite able to wrap up before Drupalcon. They're the sort of things that define some of the most basic patterns utilized by the project, and as such I tend to prefer to work on them myself so that other folks coming in have a cleaner, clearer base to work from.

• The Dog\Repository family of classes need to be split and have their initialization logic moved into a separate set of paired classes that will live at Dog\Repository\Creator. This clarifies the purpose of each class family by making creators deal only with uninitialized repositories, whereas the normal repository objects represent only repositories that should exist on disk. The benefits to code clarity should be obvious.
• I have working code locally that actually defines the logic for writing and reading the sled file. Writing is done, reading isn't quite there, but that's an essential thing that needs to go in before anything else can really happen.
• The DogHouse (the outer wrapping repository which contains all other repos) doesn't exist yet, at all.
• dog is all about clusters of git repos. But it knows these repos might have different properties, different roles; I know the way I want to do this with

Other core work

I don't mean to suggest that nobody else can work on anything before the preceding list gets tackled. Not at all - it's just that these are core parts of the library without which dog cannot function, and it needs to be me that writes them. Now they are core bits, so working on other stuff may be well and properly blocked on them. I'm trying to work fast. Anyway, if you have real, concrete plans to tackle an area, please pop your name into a cell. Don't do it if you just have loose interest, please, and make sure to talk to sdboyer (irc) when you do volunteer! And I'm fine with multiple people working on the same thing if y'all are. Just please make sure to linkify your name to your d.o account so I know how I can get a hold of you.

I've made these cells somewhat self-descriptive, but chances are you'll need to ping me to get the full details.

This is still glossing over a fair bit of what needs to be done - many of the classes are gonna need a lot more logic in them as we go. But it's a good enough high-level overview, and we can open more specific issues in the dog queue as needed.

Commands

Commands - as in the user-facing things people will actually run. When josh_k and I initially worked on this back in March, he basically wrote our 'spec' in by writing up the commands we needed into dog_drush_command(). That list has gotten a little old, and isn't necessarily 100% of what we need, but it's pretty close. But some command are bigger than others, so I'm gonna try to just put these in roughly descending order of priority. To figure out what's involved for these,

I would LOVE punnier names for rollout, rollup, catchup.

These are just the commands I've anticipated - if you've got some ideas for others, feel free to suggest and we can discuss.