Required feature list

[peterwilsoncc]

• Run from build or src
• npm
• grunt
• phpunit
• composer
• svn
• if not in content directory, set Chassis git to exclude (not gitignore) the core directory
• maybe xdebug_{on|off} function (xdebug optional)

[kadamwhite]

I'd suggest being able to choose whether to use an svn or git checkout, and ideally, to permit switching.

XDebug I'd want to be configurable per-VM; e.g., if I want xdebug I'll list both this extension and the xdebug extension in my chassis config.

Would this replace the tester extension for work on core? or require it?

[peterwilsoncc]

For XDebug I was thinking the same thing, to use it requires the extension but allow for it to be disable when running tests.

My thought is to replace it, the tester extension includes wordpress-develop as a submodule and I want to avoid two checkouts.

I like being able to switch. I'll check how vvv implemented it.

[kadamwhite]

Brainstorming meeting notes:

Chassis VM environment

Pain Points w/ current systems

• BP: VVV: very bloated. Tries to cover all potential use-cases of development, not just Core. If I want to work on a ticket, I want to be able to just pull up a VM, work on my stuff, make my changes, and put them somewhere.

  • I enjoy testing tickets out, or playing around with potential patches, so I want to be able to quickly reset the machine to a clean slate without git stash or vagrant destroy
  • Wants: Lightweight

• ML: VVV is bloated. The idea of a reset, or something quicker to spin up, is appealing.

• BP: Would be cool to have a way to say ticket number 117305, that has a patch, --- KAdam mentions grunt patch wp

• PW: The non-standard structure that Chassis uses, the tests run that the admin dir is /wp/wp-admin. This is great in production but makes the tests fail. Extension needs to take this into account, which is probably setting up a separate host.

• KAW: Would love to have the ability to point to a different checkout. BP: but would love to have it in the extension so you can clone a config and up and have it work.

• KLjr: Haven't done much core dev. PW: Why? KLjr: it's a PITA. :)

• ML: You'd mentioned wp/wp-admin. Do we still do that? The problem comes if you don't correctly hide it. Browser can cache a bad redirect and then you're in a mess.

• build vs src: we want nginx to look at those directories directly without content or looking at the root of the project.

• BP: if we're building this as an extension, is there -- is everything going to work? Or do we have to build a Chassis fork?

  • PW: I was imagining this was going to install its own tester stuff, rather than using the tester extension, to reduce duplication.

[kadamwhite]

I've broken this out into smaller issues in https://github.com/peterwilsoncc/core-dev/projects/1 and am closing this out for now.