Posted by jacine on June 23, 2011 at 12:16am
Start:
2011-06-28 16:00 - 17:00 America/New_York Organizers:
Event type:
Online meeting (eg. IRC meeting)
Please join us for our 3rd bi-weekly meeting to discuss issues and progress related to the Drupal 8 HTML5 initiative.
The meeting will be held in #drupal-html5 in IRC.
http://www.worldtimebuddy.com/meeting?lid=5128581,2618425,2147714,539195...
Comments
Notes + Transcript
Meeting transcript is available here: https://gist.github.com/1055084
Just a note about sandboxes...
The choice of whether to use sandboxes or core issues is entirely up to you and the team. If it's easier for you to manage everything in the core queue, then great. Unlike some other initiatives, which are trying to radically refactor some of Drupal's underpinnings, thus possibly leaving things in a totally bizarre, disconnected state for long periods of time, this initiative should be a lot more manageable in several individual, self-contained issues.
The main thing that should NOT happen though is bloating the list of critical/major bugs/tasks in the core queue on things that aren't committed yet, because that blocks other features from happening (including HTML 5). That's why sandboxes are nice for managing large refactoring projects, because they can segment issues off somewhere else while they get worked out.
sandboxes
My main concern is the sandbox code getting stale. It falls to the individuals on the team to keep their local repos up to date with the 8.x HEAD. I don't see how one can trust the integrity of the sandbox codebase unless it's getting updated automatically with any updates to the 8.x HEAD. The sandbox is really then just a place to push code and not really one to pull from.
Personally, I'd rather not
Personally, I'd rather not use the sandbox for issues. I strongly believe these issues should be discussed in the face of wider audience instead of being segregated into a sandbox. I'm not particularly worried about bloating the core queue. This is work for core after all, and I think we can manage it responsibly, hopefully without getting in your way.
I'm still confused about how all this will work though, and am worried about keeping the code up to date. I can't possibly chase every single patch that is made to Drupal 8, and promise that the code will always be up to date, because well, I do need to sleep. :P
If the sandbox is only going to be a place to push code, then that wont that negatively affect ongoing patches in a bad way? There will likely be a decent lag from sandbox to core itself, so we need to work something out here (and I need to fully understand it) and get everyone on board with the process. Halp! :D
Workflow discussion
Git workflow discussion is happening at http://groups.drupal.org/node/148184, so that's a good place to chime in on questions.
Steps 1 - 9 at http://groups.drupal.org/node/148184#comment-516654 was written to be an understandable workflow (plus some other stuff where we're talking about how best to credit patch contributors).
This may be helpful.
Part 1- Reviewing patches on Drupal projects (Panels)
Part 2- Creating a documentation patch for Drupal Panels