On Mar 1, 2009, at 11:06 AM, Andy Lester wrote:
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 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.
...
[Note that I already started developer instructions at:
http://wiki.github.com/rakudo/rakudo/steps-to-create-a-patch]
Your steps sound right to me (but I haven't actually tested this
workflow myself).
For larger features which are too complex to be squashed into a single
patch, non-core developers should perhaps use one more level of branch
indirection and squash subfeatures, but leave each logical change as a
separate commit on the intermediate branch.
To pick a concrete example, say I'm porting PCT::HLLCompiler from PIR
to Perl 6. I'll do most of my work on chrisdolan/rakudo/hllcompiler-
perl6-dev. As I complete major steps (say 3 parts: a straight port,
then idiomizing, then enhancing), I'll squash them to my intermediate
branch, chrisdolan/rakudo/hllcompiler-perl6. So, when I send a pull
request for that intermediate branch, @patrick can review as three
commits and perhaps take the first two and reject the third one.
Another (likely better) approach is for developers to just build one
part at a time and get feedback at earlier stages rather than risk
getting the whole body of work rejected because of an early design
flaw (like, it's silly to write PCT::HLLCompiler in Perl 6 because
other languages wouldn't want to use it that way and Rakudo couldn't
bootstrap with it anyway).
Chris
