matplotlib-devel Mailing List for matplotlib

On Fri, Jun 3, 2011 at 3:37 PM, Benjamin Root <ben...@ou...> wrote:
> By the way, whoever is the one to push the docs up to sourceforge, you can
> now do so from the v1.0.x-maint branch. I have built it on my computer and
> all of my own changes appear correct. I couldn't test *everything* (my
> LaTeX setup isn't quite right), but everything I intended to change appears
> to be there.
>
> I just pushed the doc build from the maint branch up to sf. Take it for a
test drive. Thanks for pushing through on the doc fix patch.
JDH

On Fri, Jun 3, 2011 at 1:52 PM, Eric Firing <ef...@ha...> wrote:
> On 06/03/2011 07:21 AM, Benjamin Root wrote:
>
> > P.S. : As an interesting aside to what caused me to find this mistake...
> > My docs were still not building correctly, although now that the v1.0.x
> > branch is fixed, it didn't have the multiprocessing trick that is in
> > master. Therefore, when the error occurred, a message was able to be
> > printed to my screen, which allows me to trace it down.
> >
> > What happens is that eventually, the python debugger is fired off by
> > sphinx. If possible, it would probably be wise to disable this behavior
>
> Ben,
>
> So this part of the problem sounds like a bad design in sphinx, correct?
> Do you know whether it is present in the current version of sphinx?
> If so, you might send the sphinx people a bug report. My suspicion is
> that the triggering of pdb was intended to be temporary (or at least
> optional), but got left in the sphinx code by mistake--if that is indeed
> where the fault lies.
>
> Eric
>
I will investigate that further. Currently I am using v1.0.1 of sphinx.
After the current round of docs are tested and pushed up, I will take a
deeper look.
By the way, whoever is the one to push the docs up to sourceforge, you can
now do so from the v1.0.x-maint branch. I have built it on my computer and
all of my own changes appear correct. I couldn't test *everything* (my
LaTeX setup isn't quite right), but everything I intended to change appears
to be there.
Ben Root

On 06/03/2011 07:21 AM, Benjamin Root wrote:
> P.S. : As an interesting aside to what caused me to find this mistake...
> My docs were still not building correctly, although now that the v1.0.x
> branch is fixed, it didn't have the multiprocessing trick that is in
> master. Therefore, when the error occurred, a message was able to be
> printed to my screen, which allows me to trace it down.
>
> What happens is that eventually, the python debugger is fired off by
> sphinx. If possible, it would probably be wise to disable this behavior
Ben,
So this part of the problem sounds like a bad design in sphinx, correct? 
 Do you know whether it is present in the current version of sphinx? 
If so, you might send the sphinx people a bug report. My suspicion is 
that the triggering of pdb was intended to be temporary (or at least 
optional), but got left in the sphinx code by mistake--if that is indeed 
where the fault lies.
Eric
> as it makes no sense for doc-building. What triggers the startup of pdb
> is that the copying of simple_axes_divider2.py fails at line 403 of
> plot_directive.py, in _plot_directive(). This failure, however, is
> actually not the first error, as the first one gets swallowed by a
> try...finally statement at line 230, in run_code() of the same file.
>
> Because of the removal of the .py files as noted above, I only had .pyc
> files in that directory, which lead to the build system thinking that
> there was content to build. I see these assumptions as being
> problematic, and should probably be rethought in the future.
>

On Fri, Jun 3, 2011 at 1:21 PM, Benjamin Root <ben...@ou...> wrote:
> On Thu, Jun 2, 2011 at 6:46 PM, Darren Dale <dsd...@gm...> wrote:
>>
>> Folks,
>>
>> We had some minor confusion with a merge a few weeks back, which
>> pulled much of the master branch into the v1.0.x maintenance branch. I
>> created a new v1.0.x-maint branch that rolled back all of the changes
>> from that point on, and cherry-picked all of the changes that were
>> actually intended for the v1.0.x branch.
>>
>> Please use v1.0.x-maint from now on. v1.0.x has been deleted from the
>> repository (though I'll keep a local copy for a few weeks as a backup,
>> just in case).
>>
>> If you have any changes that branched from v1.0.x after May 6 2011,
>> please contact me off list so we can correctly apply those changes on
>> top of v1.0.x-maint.
>>
>> Darren
>>
>
> There might be a missing commit. I just noticed that a bunch of .py source
> files are missing in doc/mpl_toolkits/axes_grid/figures/. This might
> require cherry-picking a50874b711983cba505e which was the commit that
> Michael used to restore some of the mistakes of the commits on May 6th.
>
> I will leave it up to Darren to figure out exactly what would be the correct
> course of action.
Thanks, it should be fixed now.

On Thu, Jun 2, 2011 at 6:46 PM, Darren Dale <dsd...@gm...> wrote:
> Folks,
>
> We had some minor confusion with a merge a few weeks back, which
> pulled much of the master branch into the v1.0.x maintenance branch. I
> created a new v1.0.x-maint branch that rolled back all of the changes
> from that point on, and cherry-picked all of the changes that were
> actually intended for the v1.0.x branch.
>
> Please use v1.0.x-maint from now on. v1.0.x has been deleted from the
> repository (though I'll keep a local copy for a few weeks as a backup,
> just in case).
>
> If you have any changes that branched from v1.0.x after May 6 2011,
> please contact me off list so we can correctly apply those changes on
> top of v1.0.x-maint.
>
> Darren
>
>
There might be a missing commit. I just noticed that a bunch of .py source
files are missing in doc/mpl_toolkits/axes_grid/figures/. This might
require cherry-picking a50874b711983cba505e which was the commit that
Michael used to restore some of the mistakes of the commits on May 6th.
I will leave it up to Darren to figure out exactly what would be the correct
course of action.
Ben Root
P.S. : As an interesting aside to what caused me to find this mistake...
My docs were still not building correctly, although now that the v1.0.x
branch is fixed, it didn't have the multiprocessing trick that is in
master. Therefore, when the error occurred, a message was able to be
printed to my screen, which allows me to trace it down.
What happens is that eventually, the python debugger is fired off by
sphinx. If possible, it would probably be wise to disable this behavior as
it makes no sense for doc-building. What triggers the startup of pdb is
that the copying of simple_axes_divider2.py fails at line 403 of
plot_directive.py, in _plot_directive(). This failure, however, is actually
not the first error, as the first one gets swallowed by a try...finally
statement at line 230, in run_code() of the same file.
Because of the removal of the .py files as noted above, I only had .pyc
files in that directory, which lead to the build system thinking that there
was content to build. I see these assumptions as being problematic, and
should probably be rethought in the future.

On Fri, Jun 3, 2011 at 9:04 AM, Benjamin Root <ben...@ou...> wrote:
>
>
> Plus, with regards to timing. Do we want to release before or after the
> upcoming SciPy conference in July? Depending on who will be there
> (unfortunately, I won't be), we might want to wait for after that conference
> to take advantage of any activity then.
>
>
I don't feel the need to wait -- things move slowly enought that we might
get one release out in the next couple of weeks and one bugfix release 2-4
weeks after that and that will dovetail with scipy conference. Also, my
June is a lot better than my July as I will be traveling in July for the
first couple of weeks.
> Also, I know I have repeatedly stated that I won't be a release manager,
> but I am going to put together a wish-list of mine for what I would like to
> see for the next release. Maybe with that as a base, we can come up with a
> final set of goals for v1.1.0 and determine how much time it would take to
> get there?
>
This might be a better idea for a 1.2 release, since this sounds like it
will take a while. There has been a lot of progress in the trunk since
1.0.1 and with the release-early-release-often philosophy I'd rather get
something out there and then if we want to do something more formalized for
the next iteration we will have plenty of time for it. I would shoot for
people to get their changes in for a 1.1 release by early next week, branch
and cut a release candidate, test for a week and put in bug fixes, cut a
second release candidate a week later. If people would like more time for a
formal process and bug closing extravaganza, I'm fine with that too.
JDH

On Fri, Jun 3, 2011 at 10:04 AM, Benjamin Root <ben...@ou...> wrote:
> On Fri, Jun 3, 2011 at 3:39 AM, John Hunter <jd...@gm...> wrote:
>>
>> On Thu, Jun 2, 2011 at 9:06 PM, Darren Dale <dsd...@gm...> wrote:
>>>
>>> Before we made the git transition, I read about various workflows.
>>> What we are doing now is somewhat similar to what used to be done with
>>> svnmerge. I just googled "git workflow", and found
>>> http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html .
>>> See the section on "Merging Upwards":
>>>
>>
>> Responding to a few of the points mentioned above -- definitely +1 on
>> more releases. I have been the bottleneck here and can do more. With that
>> in mind, let's plan on getting a trunk release out with a 2 week timeline or
>> so.
>>
>> I think there is a solid case for a release branch, so we can
>> test/refine/fix while allowing development in the trunk. Once it is
>> released, one suggestion is to can keep it around as maintenance but only
>> for release critical bugs so that if we discover a show stopper three weeks
>> after the release, we can cut a bugfix release w/ a shorted round of
>> testing. Perhaps if we limit it to release critical bugs, this will lower
>> the development burden on maintaining it and merging it.
>
> Why not just call it a release candidate and follow a similar process for it
> as numpy just did a short while ago?
>
> Plus, with regards to timing. Do we want to release before or after the
> upcoming SciPy conference in July? Depending on who will be there
> (unfortunately, I won't be), we might want to wait for after that conference
> to take advantage of any activity then.
If we have the resources, it might be better to release before, and
encourage activity at scipy to focus on py3 support (assuming it has
been merged into master by then).

On Fri, Jun 3, 2011 at 3:39 AM, John Hunter <jd...@gm...> wrote:
> On Thu, Jun 2, 2011 at 9:06 PM, Darren Dale <dsd...@gm...> wrote:
>
>> Before we made the git transition, I read about various workflows.
>> What we are doing now is somewhat similar to what used to be done with
>> svnmerge. I just googled "git workflow", and found
>> http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html .
>> See the section on "Merging Upwards":
>>
>>
> Responding to a few of the points mentioned above -- definitely +1 on more
> releases. I have been the bottleneck here and can do more. With that in
> mind, let's plan on getting a trunk release out with a 2 week timeline or
> so.
>
> I think there is a solid case for a release branch, so we can
> test/refine/fix while allowing development in the trunk. Once it is
> released, one suggestion is to can keep it around as maintenance but only
> for release critical bugs so that if we discover a show stopper three weeks
> after the release, we can cut a bugfix release w/ a shorted round of
> testing. Perhaps if we limit it to release critical bugs, this will lower
> the development burden on maintaining it and merging it.
>
Why not just call it a release candidate and follow a similar process for it
as numpy just did a short while ago?
Plus, with regards to timing. Do we want to release before or after the
upcoming SciPy conference in July? Depending on who will be there
(unfortunately, I won't be), we might want to wait for after that conference
to take advantage of any activity then.
Also, I know I have repeatedly stated that I won't be a release manager, but
I am going to put together a wish-list of mine for what I would like to see
for the next release. Maybe with that as a base, we can come up with a
final set of goals for v1.1.0 and determine how much time it would take to
get there?
Ben Root

On Fri, Jun 3, 2011 at 8:50 AM, Ryan May <rm...@gm...> wrote:
> On Fri, Jun 3, 2011 at 3:39 AM, John Hunter <jd...@gm...> wrote:
> > On the animations issue, I have noticed one strange behavior when I tried
> to
> > remove the gtk extension code and replace it with pure python and found
> the
> > new animations API behaved strangely (but not the old) under the new
> code.
> > I never committed my changes because I could not resolve whether it was
> my
> > code or Ryan's that was causing the problem, and he wasn't sure either.
> But
> > incompletely baked features (and I wouldn't even call the animations code
> > incompletely baked) are OK for releases. It's better to get them out
> there
> > and in use so our users can find and fix the bugs :-)
>
> Well if you need to rip it out/"temporarily" break it to improve the
> gtk backend, by all means do so. I'll be bogged down for a few more
> months, after which I'll be able to work more on it. (FINALLY.) The
> only reason I even checked it in originally was so that others could
> play, but I was (and still am) not ready to commit completely to the
> API.
>
> Ryan
>
>
The problem is that there aren't a lot of people playing with this code, and
people are still using the documentation's examples for animations. Maybe
we ought to consider a mechanism to release it with the next release with a
huge "experimental" sticker on it, somehow?
Ben Root

Well if you need to rip it out/"temporarily" break it to improve the
> gtk backend, by all means do so. I'll be bogged down for a few more
> months, after which I'll be able to work more on it. (FINALLY.) The
> only reason I even checked it in originally was so that others could
> play, but I was (and still am) not ready to commit completely to the
> API.
>
Not at all, I think it is at least as likely that there is a problem with my
gtk code rather than a problem in the animations API. I only brought this
up as an example of how I would rather release mostly functioning code with
a few possible warts than incubate it in the trunk for months. What you
have done is so much better than what we have that it needs to get out there
even if we have to fix or change the API later.
JDH

On Fri, Jun 3, 2011 at 3:39 AM, John Hunter <jd...@gm...> wrote:
> On the animations issue, I have noticed one strange behavior when I tried to
> remove the gtk extension code and replace it with pure python and found the
> new animations API behaved strangely (but not the old) under the new code.
> I never committed my changes because I could not resolve whether it was my
> code or Ryan's that was causing the problem, and he wasn't sure either. But
> incompletely baked features (and I wouldn't even call the animations code
> incompletely baked) are OK for releases. It's better to get them out there
> and in use so our users can find and fix the bugs :-)
Well if you need to rip it out/"temporarily" break it to improve the
gtk backend, by all means do so. I'll be bogged down for a few more
months, after which I'll be able to work more on it. (FINALLY.) The
only reason I even checked it in originally was so that others could
play, but I was (and still am) not ready to commit completely to the
API.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Fri, Jun 3, 2011 at 4:39 AM, John Hunter <jd...@gm...> wrote:
> On Thu, Jun 2, 2011 at 9:06 PM, Darren Dale <dsd...@gm...> wrote:
>>
>> Before we made the git transition, I read about various workflows.
>> What we are doing now is somewhat similar to what used to be done with
>> svnmerge. I just googled "git workflow", and found
>> http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html .
>> See the section on "Merging Upwards":
>>
>
> Responding to a few of the points mentioned above -- definitely +1 on more
> releases. I have been the bottleneck here and can do more. With that in
> mind, let's plan on getting a trunk release out with a 2 week timeline or
> so.
That would be great. I am eager to merge the py3 stuff back into the
main repository and start thinking about a 1.2 release.
> I think there is a solid case for a release branch, so we can
> test/refine/fix while allowing development in the trunk. Once it is
> released, one suggestion is to can keep it around as maintenance but only
> for release critical bugs so that if we discover a show stopper three weeks
> after the release, we can cut a bugfix release w/ a shorted round of
> testing. Perhaps if we limit it to release critical bugs, this will lower
> the development burden on maintaining it and merging it.
Sounds like a good idea.

On Wed, Jun 1, 2011 at 2:58 PM, Eric Firing <ef...@ha...> wrote:
> Do the packagers use the tip of the maintenance branch, or do they use
> the most recent release? If the former, then that bumps up the priority
> of keeping such a branch. If the latter, it bumps up the priority of
> having frequent high-quality releases, regardless of what they are called.
>
>
debian has been pretty clear that they want to build their packages from
tarballs which we have uploaded and announced.
JDH

On Thu, Jun 2, 2011 at 9:06 PM, Darren Dale <dsd...@gm...> wrote:
> Before we made the git transition, I read about various workflows.
> What we are doing now is somewhat similar to what used to be done with
> svnmerge. I just googled "git workflow", and found
> http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html .
> See the section on "Merging Upwards":
>
>
Responding to a few of the points mentioned above -- definitely +1 on more
releases. I have been the bottleneck here and can do more. With that in
mind, let's plan on getting a trunk release out with a 2 week timeline or
so.
I think there is a solid case for a release branch, so we can
test/refine/fix while allowing development in the trunk. Once it is
released, one suggestion is to can keep it around as maintenance but only
for release critical bugs so that if we discover a show stopper three weeks
after the release, we can cut a bugfix release w/ a shorted round of
testing. Perhaps if we limit it to release critical bugs, this will lower
the development burden on maintaining it and merging it.
On the animations issue, I have noticed one strange behavior when I tried to
remove the gtk extension code and replace it with pure python and found the
new animations API behaved strangely (but not the old) under the new code.
I never committed my changes because I could not resolve whether it was my
code or Ryan's that was causing the problem, and he wasn't sure either. But
incompletely baked features (and I wouldn't even call the animations code
incompletely baked) are OK for releases. It's better to get them out there
and in use so our users can find and fix the bugs :-)
JDH

2011年6月02日 17:48:55 -0400, Darren Dale wrote:
[clip]
> * "git reset --hard 0e6dad5230"
> * redo pull request 103
> * cherry-pick the following commits off of the v1.0.x branch:
> - 069c21d
> - 53f8139e
> - de18d9ab2
> - 91e7d980
> - 0cc213b4fa
> - e7f1e83ace
> - 5c968a0ecdd
> 
> That should bring the v1.0.x-cleanup branch back to where we thought it
> would be. I'll post the result in my fork as soon as it is ready, and
> request comment. At that point, we should decide if we want to rename it
> v1.0.x and force push, or rename it v1.0.x-maint (or whatever) and
> delete the current v1.0.x branch.
> 
> Pauli, Jouni, any comments?
Seems OK to me.
	Pauli

Hi,
On Thu, Jun 2, 2011 at 7:06 PM, Darren Dale <dsd...@gm...> wrote:
> Matthew,
>
> On Thu, Jun 2, 2011 at 8:17 PM, Matthew Brett <mat...@gm...> wrote:
>> Hi,
>>
>> On Thu, Jun 2, 2011 at 5:07 PM, Darren Dale <dsd...@gm...> wrote:
>>> On Thu, Jun 2, 2011 at 7:46 PM, Eric Firing <ef...@ha...> wrote:
>> ...
>>>> Even without the foulup, I think you would see that the merges from
>>>> maintenance branches into subsequent branches and into master make it
>>>> very hard to figure out what has actually been done on any given branch.
>>>
>>> I strongly disagree. The only reason you get cleaner history graphs
>>> with cherry picking is because it doesn't graph the cherry picks! If
>>> you want to know what has been merged, you have to inspect the commit
>>> message in one branch and match it up with the commit message in
>>> another branch. How does that make it easier to figure out what has
>>> been done on any given branch?
>>
>> I think Eric's point is that it kind of feels (and looks) wrong to
>> merge maintenance into master, rather than backporting fixes from
>> master with cherry-picks. Maybe 'feels wrong' might be translatable
>> as 'harder to think about' and therefore 'more error prone'?
>
> Maybe "feels wrong" translates to "unfamiliar", and has nothing to do
> with difficulty or potential for error.
Ah no - I mean that the way I think most of think of bugfix workflow
is that we fix in trunk and backport the fix to the maintenance
branch. Here though you are fixing in the maintenance branch and
_merging_ to trunk. The counter-argument is 'well think of it the
other way round and it will be fine'. It's a little difficult to know
if that's true I suppose.
It's a funny kind of thing too, because it puts an extra constraint on
the bugfix. For example, imagine a bugfix in maintenance, in some
code that has crazy-changed in trunk. Now you have to decide if you
try and merge it anyway, and basically do a rewrite as you fix the
merge conflict. Or you could merge-ours on that commit and write a
completely different fix on trunk. But that's getting a bit dark and
magic. And so it imposes some slight what-will-happen brain overhead
on the person writing the fix.
> Git is a powerful tool. If we
> used a cherry-picking workflow (which I would not advocate), there
> would still be chances for error by inappropriately specifying hash
> ranges, for example. I think there is much more potential for error
> using cherry-picking. There are other advantages as well, see
> http://stackoverflow.com/questions/1241720/git-cherry-pick-vs-merge-workflow
> (note the warnings about rebasing, which are not relevant to this
> discussion)
>
>> I can
>> see the argument for doing it though. It is a common workflow?
>
> Yes, I believe it is a very common workflow.
Ah - OK, I guess I had not seen it before.
> Before we made the git transition, I read about various workflows.
> What we are doing now is somewhat similar to what used to be done with
> svnmerge. I just googled "git workflow", and found
> http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html .
> See the section on "Merging Upwards":
Yes, I think I see why it would be attractive.
> With cherry picking, imagine we get ready to cut a v1.0.2 release, and
> we want to know if all of the bug fixes that should be applied to the
> maintenance branch have been applied. How do we verify? Much easier is
> to apply them like the docs at kernel.org suggest, to the oldest
> supported branch that require them and then merge upwards. Then the
> history graph can tell you that the bug fixes in older versions have
> been applied to newer branches.
I believe that the git log --cherry etc machinery is designed to deal
with this case, but I haven't used it myself. I have to emphasize,
the projects I've been involved with have fewer developers and smaller
code-bases,
Cheers,
Matthew

Matthew,
On Thu, Jun 2, 2011 at 8:17 PM, Matthew Brett <mat...@gm...> wrote:
> Hi,
>
> On Thu, Jun 2, 2011 at 5:07 PM, Darren Dale <dsd...@gm...> wrote:
>> On Thu, Jun 2, 2011 at 7:46 PM, Eric Firing <ef...@ha...> wrote:
> ...
>>> Even without the foulup, I think you would see that the merges from
>>> maintenance branches into subsequent branches and into master make it
>>> very hard to figure out what has actually been done on any given branch.
>>
>> I strongly disagree. The only reason you get cleaner history graphs
>> with cherry picking is because it doesn't graph the cherry picks! If
>> you want to know what has been merged, you have to inspect the commit
>> message in one branch and match it up with the commit message in
>> another branch. How does that make it easier to figure out what has
>> been done on any given branch?
>
> I think Eric's point is that it kind of feels (and looks) wrong to
> merge maintenance into master, rather than backporting fixes from
> master with cherry-picks. Maybe 'feels wrong' might be translatable
> as 'harder to think about' and therefore 'more error prone'?
Maybe "feels wrong" translates to "unfamiliar", and has nothing to do
with difficulty or potential for error. Git is a powerful tool. If we
used a cherry-picking workflow (which I would not advocate), there
would still be chances for error by inappropriately specifying hash
ranges, for example. I think there is much more potential for error
using cherry-picking. There are other advantages as well, see
http://stackoverflow.com/questions/1241720/git-cherry-pick-vs-merge-workflow
(note the warnings about rebasing, which are not relevant to this
discussion)
> I can
> see the argument for doing it though. It is a common workflow?
Yes, I believe it is a very common workflow.
Before we made the git transition, I read about various workflows.
What we are doing now is somewhat similar to what used to be done with
svnmerge. I just googled "git workflow", and found
http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html .
See the section on "Merging Upwards":
---
The "downwards graduation" discussed above cannot be done by actually
merging downwards, however, since that would merge all changes on the
unstable branch into the stable one. Hence the following:
Rule: Merge upwards
Always commit your fixes to the oldest supported branch that require
them. Then (periodically) merge the integration branches upwards into
each other.
This gives a very controlled flow of fixes. If you notice that you
have applied a fix to e.g. master that is also required in maint, you
will need to cherry-pick it (using git-cherry-pick(1)) downwards. This
will happen a few times and is nothing to worry about unless you do it
very frequently.
---
With cherry picking, imagine we get ready to cut a v1.0.2 release, and
we want to know if all of the bug fixes that should be applied to the
maintenance branch have been applied. How do we verify? Much easier is
to apply them like the docs at kernel.org suggest, to the oldest
supported branch that require them and then merge upwards. Then the
history graph can tell you that the bug fixes in older versions have
been applied to newer branches.
Merging is going to happen anyway, whenever someone files a pull
request. We have a good workflow, we just had a small mistake and have
now overcome it.
Darren

Hi,
On Thu, Jun 2, 2011 at 5:07 PM, Darren Dale <dsd...@gm...> wrote:
> On Thu, Jun 2, 2011 at 7:46 PM, Eric Firing <ef...@ha...> wrote:
...
>> Even without the foulup, I think you would see that the merges from
>> maintenance branches into subsequent branches and into master make it
>> very hard to figure out what has actually been done on any given branch.
>
> I strongly disagree. The only reason you get cleaner history graphs
> with cherry picking is because it doesn't graph the cherry picks! If
> you want to know what has been merged, you have to inspect the commit
> message in one branch and match it up with the commit message in
> another branch. How does that make it easier to figure out what has
> been done on any given branch?
I think Eric's point is that it kind of feels (and looks) wrong to
merge maintenance into master, rather than backporting fixes from
master with cherry-picks. Maybe 'feels wrong' might be translatable
as 'harder to think about' and therefore 'more error prone'? I can
see the argument for doing it though. It is a common workflow?
See you,
Matthew

On Thu, Jun 2, 2011 at 7:46 PM, Eric Firing <ef...@ha...> wrote:
> On 06/02/2011 12:35 PM, Darren Dale wrote:
>> On Thu, Jun 2, 2011 at 6:07 PM, Eric Firing<ef...@ha...> wrote:
>>> Going forward, is there any good reason to retain all the old branches
>>> (transforms, 0.91.x etc.)?
>>
>> I don't think we need the transforms branch. I kept it just for the
>> sake of completeness during the svn->git migration.
>>
>>> Don't the release tags provide adequate
>>> access to those branches? My sense is that merging them into master was
>>> not good from the standpoint of being able to read the graph and see
>>> what is really derived from what; but I don't know exactly what can be
>>> done about it. They certainly clutter up the output of "git branch -a"
>>> to no useful effect.
>>
>
>> There was actually a good reason for doing it this way. Each older
>
> I understand the rationale, but...
>
>> maintenance branch was merged into the next newer one, and it was done
>> with --strategy=ours (which basically means that any changes were
>> ignored during the merge). We did this so that if someone applied a
>
> which means that it is a fundamentally misleading merge--a merge in name
> only, not an indicator of what is in a given branch.
No, it meant that all of the actual merges that we intended to do had
already been done using svnmerge. But svn2git wasn't able to capture
all of those relationships, so instead we did what we could at the
time of the conversion.
>> critical set of patches to an earlier maintenance branch, say 0.99.x,
>> and wanted to merge it into v1.0.x, and then into master, it would be
>> easy to do so without unintentionally pulling all of the other changes
>> between 0.99.x and 1.0.x (for example) along with it.
>
> I think the likelihood of anyone ever actually doing this is near zilch;
> we don't maintain old branches.
aside from 1.0.x...
> And for the single current maintenance
> branch at any given time, cherry-picking bug fixes from maintenance to
> master or the reverse seems to me more explicit, less mysterious, and
> less likely to have unintended consequences than merging.
I understand your position.
>>
>>> Following along this line, does it perhaps make sense in the future to
>>> use cherry-picking instead of merging for propagating bug fixes between
>>> a maintenance or release branch and master? My uneducated sense is that
>>> it would leave a less confusing graph, and be less likely to result in
>>> errors.
>>
>> I would prefer to continue merging. I think its just a matter of
>> getting in the habit of inspecting the history graph. But that's just
>> my opinion.
>
> I still don't agree. It looks to me like numpy is using the cherry-pick
> approach, not the merge approach, and the result is that each branch has
> a reasonably linear history that one can actually follow by eye, and
> easily see exactly what has been done. Compare numpy:
>
> http://currents.soest.hawaii.edu/hgstage/numpy_from_git/graph/9264?revcount=240
>
> to mpl:
>
> http://currents.soest.hawaii.edu/hgstage/mpl_from_git/graph/6855?revcount=240
Numpy appears to be applying all of their changes on master, and then
cherry picking changes to apply to the maintenance branch.
> Even without the foulup, I think you would see that the merges from
> maintenance branches into subsequent branches and into master make it
> very hard to figure out what has actually been done on any given branch.
I strongly disagree. The only reason you get cleaner history graphs
with cherry picking is because it doesn't graph the cherry picks! If
you want to know what has been merged, you have to inspect the commit
message in one branch and match it up with the commit message in
another branch. How does that make it easier to figure out what has
been done on any given branch?
> Undoubtedly one *can* figure it out, as apparently you have just done;
> but it is not immediately clear from the graph.
I have another suggestion, relating to somebody's (your?) suggestion
that we make more frequent releases. Development would be more robust
if we were all branching from a commonly acknowledged reference point.
For example, that might be v1.0.1 on the maintenance branch. The
history graph would probably be cleaner as well. Then when a branch X
is merged into maint, maybe we should be merging branch X into master
as well, rather than merging v1.0.x into master. That would make it
clearer what was actually being merged. Then, when v1.0.2 was tagged,
we merge that into master (perhaps with strategy=ours if appropriate),
and that becomes the new commonly acknowledged reference point on the
master branch.
Darren