[petsc-dev] workflow diagram

[Karl Rupp]

Hey,

 >>    The other thing that “bothers” me is the two arrows coming from the
>>    last circle of a branch; one goes “straight” to next which is fine
>>    but the other one goes “straight” to master. I think it would be
>>    clearer if instead that second curve followed the branch line and
>>    then quickly curved up to master. I have shared a stunningly crude
>>    way of doing this (not I don’t intend to have the “bumb” in the
>>    curve I just suck at drawing it.) This still conveys the fact that
>>    the data for both next and master comes from the same circle but
>>    makes it clearer that the data is not “moved” from the final circle
>>    to master until later then it is moved to next; in fact it is not
>>    moved from the branch until it gets into master. Hopefully you can
>>    do that shape better then I.
>
> Hmm, I like showing that after 'next' is rewound, the graph contains no
> knowledge of 'next' integration (apart from stability).  What I want to
> communicate is that the DECISION to merge to master is based on EVIDENCE
> obtained from the integration in 'next'.

I like the graph pretty much already. Similar to what Barry raised, I 
think there is some more room for improvements on the merge arrows. 
Rather than allowing merge arrows with arbitrary angles, what about 
making them only vertical or horizontal, with corners where needed? For 
example, the merge of a feature branch to next and later master could be 
depicted as follows (ASCII art works at least in gedit):

--x--------x-------x----------x--- master
    \                          |
     \                         |
       x---x---x-----x--x...A..B
           feature          |
                            |
-------x-------x-----x-----x------ next


At point (A) the feature gets merged to next, and at (B) it gets merged 
to master. Note that the dots are part of the arrow, while dashes are 
commit dependencies in the DAG. I think you can keep the coloring and 
styles of merge lines to master and next as-is.

Also make sure you explain in your blog post that the advantage of 
feature branches is a clustering of commits which belong together. With 
a single 'devel'-branch this is all messy, because commits from the 
various features are all mixed up.

Best regards,
Karli

PS: Great timing - today I've set up an appointment with my colleagues 
to explain them the PETSc git workflow next week. :-)