On Thu, 1 May 2014, Satish Balay wrote:
> https://docs.google.com/drawings/d/1kMHa7O6FB5iiJG5QPTWqlMne1xv17A6jOXXyQ_74kaE/edit?usp=sharing
I think I'm done with the edits.
Perhaps there are lurking bugs. I've enabled write access - so anyone
shold be able to fix things.
Jed, Is this ok for your
https://docs.google.com/drawings/d/1kMHa7O6FB5iiJG5QPTWqlMne1xv17A6jOXXyQ_74kaE/edit?usp=sharing
One more change: I've attempted to make the text colors match the
corresponding branch colors.
There are 3 workflows in the 'feature branch' color scheme - so
I've used different text (plain,bold,ital
I've made some more changes - introduced a couple of notations - and
attempted to be consistant with symbols and colors.
And eliminated inconsistancies with some vertical lines (timed
actions) and some inclined lines(relation between commits). Now I use
all vertical lines (i.e timed actions)
And
Ok - deleted..
The operation was refering to the feature/bug-fix branches on the left
of it - and the timeline of the release. It overlaped with a
'master->next' dataflow arrow - so I agree it was confusing.
[The feature bug fix branches are not represented well anyway - and
some arrows are 'pare
What does the “delete all graduated branches” box serve? I find it unneeded
and confusing. You are just creating a new next based on the current master.
Don’t need that confusing language.
Barry
On Apr 30, 2014, at 8:25 PM, Satish Balay wrote:
> On Wed, 30 Apr 2014, Satish Balay wrote:
On Wed, 30 Apr 2014, Satish Balay wrote:
> On Wed, 30 Apr 2014, Jed Brown wrote:
>
> > Satish Balay writes:
> > >> Hmm, feature releases are in first-parent history of both 'maint' and
> > >> 'master'. We tag a release on 'master', then do a fast-forward merge of
> > >> the release tag into 'ma
On Wed, 30 Apr 2014, Jed Brown wrote:
> Satish Balay writes:
> >> Hmm, feature releases are in first-parent history of both 'maint' and
> >> 'master'. We tag a release on 'master', then do a fast-forward merge of
> >> the release tag into 'maint'.
> >
> > Ok - updated.
>
> Aesthetically, I like
Satish Balay writes:
>> Hmm, feature releases are in first-parent history of both 'maint' and
>> 'master'. We tag a release on 'master', then do a fast-forward merge of
>> the release tag into 'maint'.
>
> Ok - updated.
Aesthetically, I like the branches being straight lines, but I think
this st
On Wed, 30 Apr 2014, Jed Brown wrote:
> Satish Balay writes:
>
> > On Wed, 30 Apr 2014, Jed Brown wrote:
> >
> >> Satish Balay writes:
> >> > BTW: instead of associating 'discard when next is rewound' to the
> >> > dotted arrows - I'll suggest using the same 'merge' arrow notation here.
> >>
>
Satish Balay writes:
> On Wed, 30 Apr 2014, Jed Brown wrote:
>
>> Satish Balay writes:
>> > BTW: instead of associating 'discard when next is rewound' to the
>> > dotted arrows - I'll suggest using the same 'merge' arrow notation here.
>>
>> I wanted to indicate which parts of the graph remain
On Wed, 30 Apr 2014, Jed Brown wrote:
> Satish Balay writes:
> > BTW: instead of associating 'discard when next is rewound' to the
> > dotted arrows - I'll suggest using the same 'merge' arrow notation here.
>
> I wanted to indicate which parts of the graph remain in permanent
> history and whic
Barry Smith writes:
> Good. Now with the new next introduced it could be confusing that
> there are two next since the original next has an arrow head How
> about removing that final error head and somehow marking the end of
> line (of the first next line) with a little box or something.
Peter Brune writes:
> Shouldn't there also be another "maint" coming out of the future release?
'maint' is never rewound, you just merge the release tag after tagging
the release. Again, not sure how to show this without clutter, but I
tried something on the left.
pgpq7cxJYsPCf.pgp
Descriptio
Shouldn't there also be another "maint" coming out of the future release?
- Peter
On Wed, Apr 30, 2014 at 5:03 PM, Barry Smith wrote:
>
> Good. Now with the new next introduced it could be confusing that there
> are two next since the original next has an arrow head How about removing
> that
Good. Now with the new next introduced it could be confusing that there are
two next since the original next has an arrow head How about removing that
final error head and somehow marking the end of line (of the first next line)
with a little box or something.
Barry
On Apr 30, 2014, at 4:
Barry Smith writes:
>It is pretty good. One thing that I don’t think is clear is that
>the successful testing in next TRIGGERs the branch being merged up
>to master. I have drawn in an ugly curve which is an example of
>that. Sadly I couldn’t see how to put an arrow on it nor put
Satish Balay writes:
> On Wed, 30 Apr 2014, Jed Brown wrote:
>
>> Satish Balay writes:
>> > Perhaps if there arrows were flipped the confusion could be reduced?
>>
>> What do you mean by "flipped"?
>
> instead of (a) ---> (b)
>
> use:(a) <--- (b)
>
> The arrow represend 'parent' relati
Satish Balay writes:
> BTW: instead of associating 'discard when next is rewound' to the
> dotted arrows - I'll suggest using the same 'merge' arrow notation here.
I wanted to indicate which parts of the graph remain in permanent
history and which parts are only temporary. I changed 'next' to a
On Wed, 30 Apr 2014, Jed Brown wrote:
> Satish Balay writes:
> > Perhaps if there arrows were flipped the confusion could be reduced?
>
> What do you mean by "flipped"?
instead of (a) ---> (b)
use:(a) <--- (b)
The arrow represend 'parent' relationship anyway
The confusion with forwa
One more thing: The graph does not contain the case where a feature
branch has been merged to master, but is soon after found to be buggy. A
discussion of how this gets resolved (new fix-branch vs. fixing the
feature branch) is needed as this shows up occasionally in practice.
It's not suppose
Satish Balay writes:
> Perhaps if there arrows were flipped the confusion could be reduced?
What do you mean by "flipped"?
> [Somehow the commits should be accentuated to the timescale - and not the
> arrows]
Hmm, I think the arrows are equally important because they describe the
reasoning and
It is pretty good. One thing that I don’t think is clear is that the
successful testing in next TRIGGERs the branch being merged up to master. I
have drawn in an ugly curve which is an example of that. Sadly I couldn’t see
how to put an arrow on it nor put text saying something like “success
Karl Rupp writes:
> One more thing: The graph does not contain the case where a feature
> branch has been merged to master, but is soon after found to be buggy. A
> discussion of how this gets resolved (new fix-branch vs. fixing the
> feature branch) is needed as this shows up occasionally in p
On Wed, 30 Apr 2014, Satish Balay wrote:
> On Wed, 30 Apr 2014, Jed Brown wrote:
>
> > Peter Brune writes:
> >
> > > In fact, this may be part of Barry's point too... you could emphasize the
> > > testing time for each of the feature/bugfix branches by putting the
> > > testing
> > > arrow aft
On Wed, 30 Apr 2014, Jed Brown wrote:
> Peter Brune writes:
>
> > In fact, this may be part of Barry's point too... you could emphasize the
> > testing time for each of the feature/bugfix branches by putting the testing
> > arrow after the branch. and showing that it ends when merged.
>
> Done,
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
Tim Tautges writes:
> FWIW, here's my version I drew when trying to grok the petsc workflow.
> Differences that jump out at me:
>
> - Jed marks features graduating from the branch, I mark them graduating
> from next
This kills parallelism because you can't get ANYTHING from 'next' with
getting
Karl Rupp writes:
> 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 nee
Peter Brune writes:
> In fact, this may be part of Barry's point too... you could emphasize the
> testing time for each of the feature/bugfix branches by putting the testing
> arrow after the branch. and showing that it ends when merged.
Done, though it's a bit more cluttered now.
pgpSyyD_98kv
On Apr 30, 2014, at 2:03 PM, Jed Brown wrote:
> Barry Smith writes:
>
>> Should the “Testing/Users” arrow go all the way down next to the
>> next line? Now it looks like maybe it means the testing/users is on
>> the typical feature branch.
>
> Changed.
>
>> The other thing that “bothers” m
On Wed, Apr 30, 2014 at 2:29 PM, Jed Brown wrote:
> Peter Brune writes:
> > I might beat 'em over the head with it. Right now the color scheme is
> > explained in the legend, but color differentiation is still very much
> > branch-by-branch. Having a big "M" in the middle of merge nodes to
> >
Peter Brune writes:
> I might beat 'em over the head with it. Right now the color scheme is
> explained in the legend, but color differentiation is still very much
> branch-by-branch. Having a big "M" in the middle of merge nodes to
> differentiate them further is what I might do. This might be
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 qu
In fact, this may be part of Barry's point too... you could emphasize the
testing time for each of the feature/bugfix branches by putting the testing
arrow after the branch. and showing that it ends when merged.
- Peter
On Wed, Apr 30, 2014 at 2:16 PM, Peter Brune wrote:
> ... or at least the
... or at least the two that happen at once (master and maint).
- Peter
On Wed, Apr 30, 2014 at 2:16 PM, Peter Brune wrote:
>
>
>
> On Wed, Apr 30, 2014 at 1:16 PM, Jed Brown wrote:
>
>> Peter Brune writes:
>>
>> > Looks good. Directionality on the interbranch features via arrowheads
>> > m
On Wed, Apr 30, 2014 at 1:16 PM, Jed Brown wrote:
> Peter Brune writes:
>
> > Looks good. Directionality on the interbranch features via arrowheads
> > might give it a bit more of a flow-like feel.
>
> Done. (I think this is what you had in mind.)
>
Yep!
>
> > Lining up commits that are sup
Barry Smith writes:
> Should the “Testing/Users” arrow go all the way down next to the
> next line? Now it looks like maybe it means the testing/users is on
> the typical feature branch.
Changed.
> The other thing that “bothers” me is the two arrows coming from the
> last circle of a bran
Should the “Testing/Users” arrow go all the way down next to the next line?
Now it looks like maybe it means the testing/users is on the typical
feature branch.
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
Peter Brune writes:
> Looks good. Directionality on the interbranch features via arrowheads
> might give it a bit more of a flow-like feel.
Done. (I think this is what you had in mind.)
> Lining up commits that are supposed to correspond and/or marking
> merges in a particular way special m
Looks good. Directionality on the interbranch features via arrowheads
might give it a bit more of a flow-like feel. Lining up commits that are
supposed to correspond and/or marking merges in a particular way special
might also make it prettier and more intuitive.
- Peter
On Wed, Apr 30, 2014 a
This is my first attempt at a diagram to explain our workflow. Let me
know what you think about it. I will probably write a blog post later
to explain the properties and rationale behind this workflow relative to
others.
https://docs.google.com/drawings/d/1hvwyCIw4Wq3NoRrPpWfPTriJn5MM2_QkaacAaql
41 matches
Mail list logo
