So how about this for the workflow, Patrick:
1) Developer creates a branch to work on a feature or cleanup or
whatever
2) Developer commits to dev/rakudo work branch however much she wants.
3) Developer merges back to dev/rakudo master branch with a "squash"
option.
4) Developer posts merge request to pmichaud (or whoever)
5) Patrick does a cherry-pick with the --no-commit flag on rakudo/
rakudo.
6) Patrick tests out the patch, and commits when happy.
This way, Patrick is still getting one big patch, but without the mess
of creating a patch, and we still get to take advantage of git's
tracking.
This means two big rules:
1) All development work of any size has to be done on a branch in dev/
rakudo, because...
2) Any given commit on a developer's master has to be able to stand on
its own, and not require siblings.
I think if we just get past the way we've done things where we shove
things on to our master branches willy-nilly, the fork queue will be
MUCH smaller, and Patrick will have a much easier time of things.
Sound reasonable? I'll go throw it on a "how to be a rakudo
developer" page.
xoxo,
Andy
--
Andy Lester => a...@petdance.com => www.petdance.com => AIM:petdance
