98.4 maintenance branch

Development matplotlib-devel
1

Since we already have a bug in the 98.4 release, we can anticipate needing to do a bugfix release accumulating all the bugs we fix in the next week (presuming we don’t discover any critical bugs which would require us to push out a fix earlier). To make sure we achieve maximal stability, I have created a 98.4 maintenance branch which should only get bugfixes. All other development can proceed apace on the trunk.

svn co [https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/](https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/)
v0_98_4_maint mpl98.4 --username=youruser --password=yourpass

Mike, can you advise on the procedure for doing merges from the new branch to the trunk. In particular, what I am confused about is how to inform svn-merge that I want to merge from 98.4 branch and not 91.4 branch.

JDH

2

John Hunter wrote:

Since we already have a bug in the 98.4 release, we can anticipate needing to do a bugfix release accumulating all the bugs we fix in the next week (presuming we don't discover any critical bugs which would require us to push out a fix earlier). To make sure we achieve maximal stability, I have created a 98.4 maintenance branch which should only get bugfixes. All other development can proceed apace on the trunk.

   svn co matplotlib download | SourceForge.net <matplotlib download | SourceForge.net;
   v0_98_4_maint mpl98.4 --username=youruser --password=yourpass

Mike, can you advise on the procedure for doing merges from the new branch to the trunk. In particular, what I am confused about is how to inform svn-merge that I want to merge from 98.4 branch and not 91.4 branch.

You can add a new branch for the trunk to "track" using "svnmerge.py init", e.g., from a working copy of the trunk:

  > svnmerge.py init matplotlib download | SourceForge.net

  property 'svnmerge-integrated' set on '.'

After doing a "svn commit" on this, this merge tracking is available to everyone, so there's no need for anyone else to do the "svnmerge init". I'll go ahead and commit this now.

Now, the trunk is tracking two branches for merges, 0.91.x and 0.98.4. This means that when doing a merge, one must manually specify which branch to merge from using the "-S" parameter. You can see which branches are available for merge using "svnmerge.py avail":

> svnmerge.py avail
svnmerge: multiple sources found. Explicit source argument (-S/--source) required.
The merge sources available are:
  /branches/v0_91_maint
  /branches/v0_98_4_maint

So to merge from 0.98.4, one would type:

> svnmerge.py --source v0_98_4_maint merge

(rather than the "svnmerge.py merge" we used to do).

The tracking for 0.91.x can be removed with the "svnmerge.py uninit" command, e.g.:

> svnmerge.py --source v0_91_maint uninit

This will make merging slightly easier, (since the -S parameter is not required), and it is generally good practice in the long run to not keep extra branches lying around. I'm happy to make this change, but thought I'd run it by you first -- it means we're effectively abandoning the 0.91.x series, or at least saying any bugfixes to it will have to be manually brought over to 0.98.x.

Mike

3

Thanks for the notes – I’l incorporate them into the dev guide.

I definitely do not want to abandon the 91 branch. I expect this branch to last a while, perhaps a year. the 98.4 branch is intended to be short lived, order of a week or two, just to fix critical bugs for this release. Or better yet, we keep it alive until the next point release, then kill it and make a new release branch. That way if we ever need to fix a critical bug in the latest release, we can go to the branch w/o having all the testing required on the head. Since the major incompatibility was between 91 and 98, I anticipate that there are some users with a lot of code (eg an axes3d dependency) where moving may never be feasible.

JDH

···

On Wed, Dec 10, 2008 at 11:30 AM, Michael Droettboom <mdroe@…31…> wrote:

This will make merging slightly easier, (since the -S parameter is not required), and it is generally good practice in the long run to not keep extra branches lying around. I’m happy to make this change, but thought I’d run it by you first – it means we’re effectively abandoning the 0.91.x series, or at least saying any bugfixes to it will have to be manually brought over to 0.98.x.

4

It looks like there was a slight "oops" making the branch.

points to one level above the source tree. See:

Was this intentional?

In any case, the svnmerge setup I did this morning is incorrect. Would you like me to fix that, or would you rather remove and recreate the branch? If we don't fix the branch, I would suggest changing the instructions for checking out the branch to:

svn co matplotlib download | SourceForge.net mpl98.4

Cheers,
Mike

John Hunter wrote:

···

On Wed, Dec 10, 2008 at 11:30 AM, Michael Droettboom <mdroe@...31... > <mailto:mdroe@…31…>> wrote:

    This will make merging slightly easier, (since the -S parameter is
    not required), and it is generally good practice in the long run
    to not keep extra branches lying around. I'm happy to make this
    change, but thought I'd run it by you first -- it means we're
    effectively abandoning the 0.91.x series, or at least saying any
    bugfixes to it will have to be manually brought over to 0.98.x.

Thanks for the notes -- I'l incorporate them into the dev guide.

I definitely do not want to abandon the 91 branch. I expect this branch to last a while, perhaps a year. the 98.4 branch is intended to be short lived, order of a week or two, just to fix critical bugs for this release. Or better yet, we keep it alive until the next point release, then kill it and make a new release branch. That way if we ever need to fix a critical bug in the latest release, we can go to the branch w/o having all the testing required on the head. Since the major incompatibility was between 91 and 98, I anticipate that there are some users with a lot of code (eg an axes3d dependency) where moving may never be feasible.

JDH

5

Hmm... Seems Thunderbird butchered my long URLs.

Anyway, the problem is worse than I thought. Since the branch was created from trunk/ to branches/v0_98_4_maint/, svnmerge.py will only merge from one of those to the other. What we really want to be able to do is merge from branches/v0_98_4_maint/matplotlib to trunk/matplotlib (i.e. source tree to source tree, not from the whole matplotlib universe to another), so the branch must be created in the same way. svnmerge does its magic by going back to find how the branch was created, and if the merging doesn't match the branch operation, it basically can't do anything. Hope that description makes sense.

This means, presently, in order to do a merge, one has to check out the whole kit-and-caboodle with htdocs, py4science etc., and not just the matplotlib source tree.

I would suggest fixing this creating a new branch just from the source tree, and setting up merging from that to the trunk source tree, and then retiring or deleting the current v0_98_4_maint branch (if that's possible).

In the meantime, I've removed merge tracking on branches/v0_98_4_maint to trunk/matplotlib, since it's broken.

Cheers,
Mike

Michael Droettboom wrote:

···

It looks like there was a slight "oops" making the branch.

matplotlib download | SourceForge.net

points to one level above the source tree. See:

matplotlib download | SourceForge.net

Was this intentional?

In any case, the svnmerge setup I did this morning is incorrect. Would you like me to fix that, or would you rather remove and recreate the branch? If we don't fix the branch, I would suggest changing the instructions for checking out the branch to:

svn co matplotlib download | SourceForge.net mpl98.4

Cheers,
Mike

John Hunter wrote:
  

On Wed, Dec 10, 2008 at 11:30 AM, Michael Droettboom <mdroe@...31... >> <mailto:mdroe@…31…>> wrote:

    This will make merging slightly easier, (since the -S parameter is
    not required), and it is generally good practice in the long run
    to not keep extra branches lying around. I'm happy to make this
    change, but thought I'd run it by you first -- it means we're
    effectively abandoning the 0.91.x series, or at least saying any
    bugfixes to it will have to be manually brought over to 0.98.x.

Thanks for the notes -- I'l incorporate them into the dev guide.

I definitely do not want to abandon the 91 branch. I expect this branch to last a while, perhaps a year. the 98.4 branch is intended to be short lived, order of a week or two, just to fix critical bugs for this release. Or better yet, we keep it alive until the next point release, then kill it and make a new release branch. That way if we ever need to fix a critical bug in the latest release, we can go to the branch w/o having all the testing required on the head. Since the major incompatibility was between 91 and 98, I anticipate that there are some users with a lot of code (eg an axes3d dependency) where moving may never be feasible.

JDH
    
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

6

Yes, this was just a screwup on my part when I made the branch; be gentle, it was my first time. I agree with your suggestion of just deleting the branch and starting over.

Unfortunately, there is a critical bug reported on the users list where is GTKAgg is installed as the default backend on the windows installer (I confirmed this for the win 2.5 win32 egg and assume the problem is in the other win binaries too). Charlie, did you perhaps forget to set the tkagg backend in the setup.cfg config for the windows installer (and make sure the configobj and traits are turned off as Darren mentioned in another thread)? I have deleted the win32 files from the sf release page.

Given that the win32 binaries have to be fixed ASAP and that the branch is fubar, it may be in everyone’s best interest to simply start over.
I’ve added Michael’s font_manager and Jae-Joon’s figure/subplot fixes to the trunk at r6559 and bumped the version number to 0.98.5rc. I did another round of testing with these changes (including a nose test for Jae-Joon’s problem!) so Charlie if you have time to do another set of binaries we can kill all these birds with one stone an just release 0.98.5 (if you go this route, just remove the rc from the version num and bump to 0.98.5)

Or Charlie, if you do not have time for this in the next 24 hours, but do have time to upload new win32 binaries from your existing build dirs with the backend fixed, that is fine too and we can push out a bug fix release with these other non-critical changes next week. If you decide to go this route, you should know that I may have accidentally deleted the python 2.4 os x egg when deleting the win32 binaries, because if there was one there isn’t one there now :frowning:

And if your new baby is requiring some attention and you don’t have time for either of these, let me know and I will simply hide the 98.4 release until we sort this out.

And I’ll try and get the maintenance branch right next time :slight_smile:

···

On Wed, Dec 10, 2008 at 5:43 PM, Michael Droettboom <mdroe@…31…> wrote:

Hmm… Seems Thunderbird butchered my long URLs.

Anyway, the problem is worse than I thought. Since the branch was created from trunk/ to branches/v0_98_4_maint/, svnmerge.py will only merge from one of those to the other. What we really want to be able to do is merge from branches/v0_98_4_maint/matplotlib to trunk/matplotlib (i.e. source tree to source tree, not from the whole matplotlib universe to another), so the branch must be created in the same way. svnmerge does its magic by going back to find how the branch was created, and if the merging doesn’t match the branch operation, it basically can’t do anything. Hope that description makes sense.

This means, presently, in order to do a merge, one has to check out the whole kit-and-caboodle with htdocs, py4science etc., and not just the matplotlib source tree.

I would suggest fixing this creating a new branch just from the source tree, and setting up merging from that to the trunk source tree, and then retiring or deleting the current v0_98_4_maint branch (if that’s possible).

7

John Hunter wrote:

    Hmm... Seems Thunderbird butchered my long URLs.

    Anyway, the problem is worse than I thought. Since the branch was
    created from trunk/ to branches/v0_98_4_maint/, svnmerge.py will
    only merge from one of those to the other. What we really want to
    be able to do is merge from branches/v0_98_4_maint/matplotlib to
    trunk/matplotlib (i.e. source tree to source tree, not from the
    whole matplotlib universe to another), so the branch must be
    created in the same way. svnmerge does its magic by going back to
    find how the branch was created, and if the merging doesn't match
    the branch operation, it basically can't do anything. Hope that
    description makes sense.

    This means, presently, in order to do a merge, one has to check
    out the whole kit-and-caboodle with htdocs, py4science etc., and
    not just the matplotlib source tree.

    I would suggest fixing this creating a new branch just from the
    source tree, and setting up merging from that to the trunk source
    tree, and then retiring or deleting the current v0_98_4_maint
    branch (if that's possible).

Yes, this was just a screwup on my part when I made the branch; be gentle, it was my first time. I agree with your suggestion of just deleting the branch and starting over.

No worries. These things can be hopelessly fiddly.

Unfortunately, there is a critical bug reported on the users list where is GTKAgg is installed as the default backend on the windows installer (I confirmed this for the win 2.5 win32 egg and assume the problem is in the other win binaries too). Charlie, did you perhaps forget to set the tkagg backend in the setup.cfg config for the windows installer (and make sure the configobj and traits are turned off as Darren mentioned in another thread)? I have deleted the win32 files from the sf release page.

Given that the win32 binaries have to be fixed ASAP and that the branch is fubar, it may be in everyone's best interest to simply start over.
I've added Michael's font_manager and Jae-Joon's figure/subplot fixes to the trunk at r6559 and bumped the version number to 0.98.5rc. I did another round of testing with these changes (including a nose test for Jae-Joon's problem!) so Charlie if you have time to do another set of binaries we can kill all these birds with one stone an just release 0.98.5 (if you go this route, just remove the rc from the version num and bump to 0.98.5)

Or Charlie, if you do not have time for this in the next 24 hours, but do have time to upload new win32 binaries from your existing build dirs with the backend fixed, that is fine too and we can push out a bug fix release with these other non-critical changes next week. If you decide to go this route, you should know that I may have accidentally deleted the python 2.4 os x egg when deleting the win32 binaries, because if there was one there isn't one there now :frowning:

And if your new baby is requiring some attention and you don't have time for either of these, let me know and I will simply hide the 98.4 release until we sort this out.

And I'll try and get the maintenance branch right next time :slight_smile:

All of the above sounds good to me.

Mike

···

On Wed, Dec 10, 2008 at 5:43 PM, Michael Droettboom <mdroe@...31... > <mailto:mdroe@…31…>> wrote:

8

I will be traveling to my conference starting at noon, so will be in
sporadic, light email contact for the next few days. Charlie will
look at fixing the builds tonight -- everyone else, please do what you
can if something comes up because I would love to have a good set of
binaries on line by the time my talk starts at noon tomorrow:

  http://mloss.org/workshop/nips08/

JDH

···

On Thu, Dec 11, 2008 at 8:25 AM, Michael Droettboom <mdroe@...31...> wrote:

And I'll try and get the maintenance branch right next time :slight_smile:

All of the above sounds good to me.

9

0.98.5 source and bins are posted. Please try them out. John can
announce at his convenience.

- Charlie

···

On Thu, Dec 11, 2008 at 12:15 PM, John Hunter <jdh2358@...149...> wrote:

On Thu, Dec 11, 2008 at 8:25 AM, Michael Droettboom <mdroe@...31...> wrote:

And I'll try and get the maintenance branch right next time :slight_smile:

All of the above sounds good to me.

I will be traveling to my conference starting at noon, so will be in
sporadic, light email contact for the next few days. Charlie will
look at fixing the builds tonight -- everyone else, please do what you
can if something comes up because I would love to have a good set of
binaries on line by the time my talk starts at noon tomorrow:

http://mloss.org/workshop/nips08/

JDH

10

Michael,

Will you create the branch and set up the svn merge properties?

Thanks Charlie,
JDH

···

Sent from my iPhone

On Dec 11, 2008, at 7:35 PM, "Charlie Moad" <cwmoad@...149...> wrote:

0.98.5 source and bins are posted. Please try them out. John can
announce at his convenience.

- Charlie

On Thu, Dec 11, 2008 at 12:15 PM, John Hunter <jdh2358@...149...> > wrote:

On Thu, Dec 11, 2008 at 8:25 AM, Michael Droettboom >> <mdroe@...31...> wrote:

And I'll try and get the maintenance branch right next time :slight_smile:

All of the above sounds good to me.

I will be traveling to my conference starting at noon, so will be in
sporadic, light email contact for the next few days. Charlie will
look at fixing the builds tonight -- everyone else, please do what you
can if something comes up because I would love to have a good set of
binaries on line by the time my talk starts at noon tomorrow:

http://mloss.org/workshop/nips08/

JDH

11

Done.

I also cleaned up the svnmerge docs in doc/devel/coding_guide.rst

What we don't currently have is a way to merge fixes from 0.91.x to 0.98.5. It's been a long time since 0.91.x has seen any love, so I'm not too concerned. Just be aware of it -- bug fixes on 0.91.x may need to be manually brought in to 0.98.5 if applicable.

Mike

John Hunter wrote:

···

Michael,

Will you create the branch and set up the svn merge properties?

Thanks Charlie,
JDH

Sent from my iPhone

On Dec 11, 2008, at 7:35 PM, "Charlie Moad" <cwmoad@...149...> wrote:

0.98.5 source and bins are posted. Please try them out. John can
announce at his convenience.

- Charlie

On Thu, Dec 11, 2008 at 12:15 PM, John Hunter <jdh2358@...149...> wrote:

On Thu, Dec 11, 2008 at 8:25 AM, Michael Droettboom >>> <mdroe@...31...> wrote:

And I'll try and get the maintenance branch right next time :slight_smile:

All of the above sounds good to me.

I will be traveling to my conference starting at noon, so will be in
sporadic, light email contact for the next few days. Charlie will
look at fixing the builds tonight -- everyone else, please do what you
can if something comes up because I would love to have a good set of
binaries on line by the time my talk starts at noon tomorrow:

http://mloss.org/workshop/nips08/

JDH