April 2014 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] workflow diagram
by Jed Brown 30 Apr '14

30 Apr '14

Barry Smith <bsmith(a)mcs.anl.gov> 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. I tried something to give that impression. I think we're converging on a local optimum here.

1 0

Re: [petsc-dev] workflow diagram
by Jed Brown 30 Apr '14

30 Apr '14

Peter Brune <prbrune(a)gmail.com> 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.

1 0

Re: [petsc-dev] workflow diagram
by Peter Brune 30 Apr '14

30 Apr '14

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 <bsmith(a)mcs.anl.gov> 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 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:53 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > > Barry Smith <bsmith(a)mcs.anl.gov> 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 text > >> saying something like “successful test leads to merge of branch > >> into master”. > > > > I hoped that "merged with evidence of stability" communicated that part. > > > >> Also you use funky unnecessary language that muddles things up. > >> > >> red circle — merge to integration branch “integration”? Just say > >> next/test branch in fact next should really be called test branch > >> but I guess we are stuck with next > > > > Changed. > > > >> You waste too much of the page with all the explanation at the > >> bottom. > > > > Hmm, I don't think I can expand the graph without making it more > > confusing. The legend at the bottom lets my comment more, but I'm sure > > it can be tightened up more. > > > >> Make the maint and master branch lines blue, the feature lines > >> yellow, the bug fix branch line green, the next branch line red > > > > Done > > > >> The wording (usually start from master) is wrong. It is the branch > >> that is usually started from master not the commit. > > > > fixed > > > >> Remove all the business of “discard when next is rewound words” > >> instead just show the next release being made on the right side of > >> the picture and hence the new next being made again like you do at > >> the left side > > > > I've tried that. > > > >> With these changes you can get rid of the last three things at the > >> bottom in () > > > > Hmm, I might wait on deleting that. I'm not sure it's communicated by > > the other part of the figure. > >

1 0

Re: [petsc-dev] workflow diagram
by Barry Smith 30 Apr '14

30 Apr '14

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:53 PM, Jed Brown <jed(a)jedbrown.org> wrote: > Barry Smith <bsmith(a)mcs.anl.gov> 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 text >> saying something like “successful test leads to merge of branch >> into master”. > > I hoped that "merged with evidence of stability" communicated that part. > >> Also you use funky unnecessary language that muddles things up. >> >> red circle — merge to integration branch “integration”? Just say >> next/test branch in fact next should really be called test branch >> but I guess we are stuck with next > > Changed. > >> You waste too much of the page with all the explanation at the >> bottom. > > Hmm, I don't think I can expand the graph without making it more > confusing. The legend at the bottom lets my comment more, but I'm sure > it can be tightened up more. > >> Make the maint and master branch lines blue, the feature lines >> yellow, the bug fix branch line green, the next branch line red > > Done > >> The wording (usually start from master) is wrong. It is the branch >> that is usually started from master not the commit. > > fixed > >> Remove all the business of “discard when next is rewound words” >> instead just show the next release being made on the right side of >> the picture and hence the new next being made again like you do at >> the left side > > I've tried that. > >> With these changes you can get rid of the last three things at the >> bottom in () > > Hmm, I might wait on deleting that. I'm not sure it's communicated by > the other part of the figure.

1 0

Re: [petsc-dev] workflow diagram
by Jed Brown 30 Apr '14

30 Apr '14

Barry Smith <bsmith(a)mcs.anl.gov> 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 text > saying something like “successful test leads to merge of branch > into master”. I hoped that "merged with evidence of stability" communicated that part. > Also you use funky unnecessary language that muddles things up. > > red circle — merge to integration branch “integration”? Just say > next/test branch in fact next should really be called test branch > but I guess we are stuck with next Changed. > You waste too much of the page with all the explanation at the > bottom. Hmm, I don't think I can expand the graph without making it more confusing. The legend at the bottom lets my comment more, but I'm sure it can be tightened up more. > Make the maint and master branch lines blue, the feature lines > yellow, the bug fix branch line green, the next branch line red Done > The wording (usually start from master) is wrong. It is the branch > that is usually started from master not the commit. fixed > Remove all the business of “discard when next is rewound words” > instead just show the next release being made on the right side of > the picture and hence the new next being made again like you do at > the left side I've tried that. > With these changes you can get rid of the last three things at the > bottom in () Hmm, I might wait on deleting that. I'm not sure it's communicated by the other part of the figure.

1 0

Re: [petsc-dev] workflow diagram
by Jed Brown 30 Apr '14

30 Apr '14

Satish Balay <balay(a)mcs.anl.gov> writes: > On Wed, 30 Apr 2014, Jed Brown wrote: > >> Satish Balay <balay(a)mcs.anl.gov> 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 This is a perfect reflection of the data structure, but I think a lot of people intuitively think of the flow rather than dependency relationships. Also, having the arrowhead at the new merge commits connotes the ordering of events (or that's my perception). Does anyone else think it would be better with arrows pointed the other way? > The confusion with forward facing arrows occurs when its interpreted > as 'data flow' or something that has 'time-factor' associated with it.

1 0

Re: [petsc-dev] workflow diagram
by Jed Brown 30 Apr '14

30 Apr '14

Satish Balay <balay(a)mcs.anl.gov> 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 dashed line to further reinforce this. > And then somehow show that the 'next branch is discared and > reconstruced (from master) at the next release..

1 0

Re: [petsc-dev] workflow diagram
by Satish Balay 30 Apr '14

30 Apr '14

On Wed, 30 Apr 2014, Jed Brown wrote: > Satish Balay <balay(a)mcs.anl.gov> 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 forward facing arrows occurs when its interpreted as 'data flow' or something that has 'time-factor' associated with it. [so you had to do the squigly lines - which - I think are not conveying the relationship properly] Satish > > [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 social issues around collaborative development. The > commits will be somewhere in almost any workflow, but the benefit of > this one is in the arrows. At least that's how I think about it, and > I'm not a category theorist ("there are only arrows"). >

1 0

Re: [petsc-dev] workflow diagram
by Karl Rupp 30 Apr '14

30 Apr '14

>> 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 supposed to. ;-) > > I don't know how to add this without creating too much clutter. Yes, I agree that this would be too much clutter - hence the emphasis on a 'discussion' rather than altering the figure. :-) Best regards, Karli

1 0

Re: [petsc-dev] workflow diagram
by Jed Brown 30 Apr '14

30 Apr '14

Satish Balay <balay(a)mcs.anl.gov> 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 social issues around collaborative development. The commits will be somewhere in almost any workflow, but the benefit of this one is in the arrows. At least that's how I think about it, and I'm not a category theorist ("there are only arrows").

1 0