Create a Publicly Available BlueCheese Repo

Here's my technical proposal for how we go about separating the open Bluecheese from the blue Bluecheese :P

1. Fully implement Sass variables for every colour/image url we want to change.
2. Change enough of the Sass variables so the design does not resemble d.o
3. Init and commit a new git repo and push that up to d.o
4. Create an additional variables file that will load after the original one, replacing all the relevant variables with the correct colours and image urls. Commit that file to the forked repo of Bluecheese that will not be public.

Having an additional variables file instead of modifying the original file reduces our chances of merge conflicts.

I'll begin implementing the Sass variables in #2168069: Fully implement Sass variables through out the theme. Feedback on everything else is welcome.

Looks good to me. I'll deal with the repos and commits. The public one will be in this project.

A quick update, I am almost done with the public/private repos. This is how the public theme will look like initially:
http://issue-drupal.redesign.devdrupal.org/

Compared to the first prototype I just added random blue and green for the links and buttons. We can add more/different colours later. Repos will be finished and incorporated into our build process in the next day or two. Until then we are basically maintaining two copies of the theme, so it's best to postpone any theme changes.

Great ok, I made #2178123: Change Sass variables and unbrand the theme but it might be unnecessary. Looks like you're basically done.

The build system is working, but I haven't figured out a plan for compiling styles.css in the public repo yet. We could:

1. Remove it and require developers to compile.
2. Committers commit whatever they want, ideally compiled on devwww for consistency.
3. We make a Drupal.org account for Bender and the robot does the compile, and commits the result.

I also need to save the finished scripts to the infrastructure repository. They will need a little work as soon and any public commits happen on styles.css; that will be a merge conflict. If we go with (1), they only need to be fixed once, (2) or (3) will need some special handling.

The theme w/ the blue links + green buttons looks great, thanks.

What are the steps required for developers to do #1? Are they standard steps they'd need to follow for any other SASS set-up, or some kind of special one-off for d.o?

http://compass-style.org/install/ is what to do. VMs we provide will have it all set up by Puppet, so it will actually be only compass compile. I can't recommend setting it up locally because of potential Ruby dependency hell, and what you get would probably be a different version number and compile slightly different CSS.

Hm. At a glance that looks like a lot of hassle, esp when we're generally talking about people who specialize in HTML and CSS and not server-side languages of any kind (command-line: eek!). But I don't really understand the ramifications of that vs. #2 and #3, and who'd get stuck with the added complexity, and what sort of timeline implications each option has.

In general, though, I would love to see us optimizing for "seamless Drupal.org contributor experience" wherever possible, vs. "ease of maintenance" or "reducing infrastructure complexity" or whatever other factors are involved. But not if "delightful Drupal.org contributor experience" means "sometime in 2015," due to trade-offs in those other factors, if that makes sense. ;)

Why can't we do what we sort of do now - require and commit only patches which include both scss and css?
When commit from the public repo is pushed into private one, there will be compass compile at the end and style.css will be overridden anyway?

2 and 3 aren't a huge problem. The build script Git merges public to private, and will have to revert styles.css to remain as the private version. The private version will always have a styles.css compiled by the build script.

I actually haven't liked reviewing patches that have both css and scss lately. #2161601: Create styling that matches issue edit form mockup had a bit of noise in the css that was only from either a different version of compass/dependencies or different configuration. And I end up reviewing the changes twice.

Needing to compile is something themers decided on and it is required for any changes to css. Our VMs can and should pre-compile for everyone else if we go with #1. It is something that trips up new contributors, #1393006: Helvetica issue on Mac. Not having css to patch may be a way to guide people to making scss patches.

The build script is relatively stable now, pending resolving comment #6 here, so I committed the script: http://drupalcode.org/project/infrastructure.git/blob/refs/heads/master:...

I also made http://drupalcode.org/project/infrastructure.git/blob/refs/heads/master:..., which mirrors Git to BZR. It will be removed when all Drupal.org sites repos are on Git. This leaves the existing BZR toolchain untouched.

With http://drupalcode.org/project/bluecheese.git/commit/63185b4, I think we can call this done.

Existing dev site infrastructure still uses the same BZR, so the branded & compiled version is there. When we figure out #2099755: Migrate self-hosted BZR to Bitbucket Git, we can make sure the public version is compiled somewhere in the build process. This is actually a big help for that issue since we remove the need for a special BZR repo and figured out a good way for the robot to commit to Git repositories.

YEAH! Great work, everyone! :D

I can't recommend setting it up locally because of potential Ruby dependency hell, and what you get would probably be a different version number and compile slightly different CSS.

The best way to handle this now is to use Bundler to manage dependancies. We should open an issue to include a Gemfile that states all the Ruby dependencies. This is how it's handled in Omega 4.x