moving to the transforms branch

Now that the 0.91.2 release is out, I am inclined to merge Michael's
transforms branch into the trunk. Since many people rely on svn, we
probably need to advertise this move broadly, with a news item on the
web page and announcements on the mailing lists, with instructions on
how to checkout the 0.91 maintenance branch (which does not exist but
would be created as the maintenance branch). There was some
suggestion earlier that we leave Michael's work on a branch, but I
think we need to get it on the trunk so developers and svn users will
get it by default which will help us move more rapidly in shaking out
the remaining bugs and problems.

Michael, since you know more about this than anyone, you should
probably spearhead the svn reorganization and let people know when the
changes become effective with some advance notice. I will update the
website with pointers to the relevant docs (your API_CHANGES and
Changelog and the relevant svn commands and anything else you think we
will need).

If this seems like a reasonable plan, perhaps we should shoot for
doing this in a day or two. If any of you think this is the wrong
approach, let us know.

JDH

John et al.,

(At the moment I can't compile the branch--I just sent Mike a message about that off the list, with voluminous output.)

It seems like what is needed is not exactly a merge operation but simply a renaming of the trunk and the branch. Maybe some doc files need to be merged, but that is about it. Correct?

In any case, I will be happy to see the move take place, and I think we already agreed that this is a good time to do it.

All this brings to mind the discussion taking place over the last week on the numpy list regarding switching from svn to bzr or hg.
http://thread.gmane.org/gmane.comp.python.numeric.general/18130
  (I have been using hg locally for a couple years, and I like it.) The motivation is the greater ease of branching and merging with distributed VCS systems in comparison to SVN. In the numpy list discussion, it sounds like all participants except Travis favor making the switch.

For us to make such a change would require switching the repo host from sourceforge to something else--I suspect Enthought would be happy to host us.

Apart from the initial effort and spinup required--and I don't mean to dismiss that as trivial--I think that using a suitable DVCS would facilitate progress with mpl. If so, is it crazy to do it as part of a major branch/trunk switch, or does that perhaps make it easier?

Comments?

Eric

John Hunter wrote:

···

Now that the 0.91.2 release is out, I am inclined to merge Michael's
transforms branch into the trunk. Since many people rely on svn, we
probably need to advertise this move broadly, with a news item on the
web page and announcements on the mailing lists, with instructions on
how to checkout the 0.91 maintenance branch (which does not exist but
would be created as the maintenance branch). There was some
suggestion earlier that we leave Michael's work on a branch, but I
think we need to get it on the trunk so developers and svn users will
get it by default which will help us move more rapidly in shaking out
the remaining bugs and problems.

Michael, since you know more about this than anyone, you should
probably spearhead the svn reorganization and let people know when the
changes become effective with some advance notice. I will update the
website with pointers to the relevant docs (your API_CHANGES and
Changelog and the relevant svn commands and anything else you think we
will need).

If this seems like a reasonable plan, perhaps we should shoot for
doing this in a day or two. If any of you think this is the wrong
approach, let us know.

JDH

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

(At the moment I can't compile the branch--I just sent Mike a message
about that off the list, with voluminous output.)

It seems like what is needed is not exactly a merge operation but simply
a renaming of the trunk and the branch. Maybe some doc files need to be
merged, but that is about it. Correct?

Sorry if I used sloppy terminology, all I mean is that Michael's stuff
will become the HEAD of the svn trunk, and the current HEAD of the
trunk will become a branch. No merge will be necessary since Michael
has been merging all changes in the HEAD into his branch on a ongoing
basis. I don't actually know how one does this move in svn, but I
have faith that Michael does.

All this brings to mind the discussion taking place over the last week
on the numpy list regarding switching from svn to bzr or hg.
http://thread.gmane.org/gmane.comp.python.numeric.general/18130
  (I have been using hg locally for a couple years, and I like it.) The
motivation is the greater ease of branching and merging with distributed
VCS systems in comparison to SVN. In the numpy list discussion, it
sounds like all participants except Travis favor making the switch.

I'm personally -1 on this. I prefer to keep things as simple as
possible and do not see the need for a lot of branching, though there
is clearly a need for some. svn is the standard version control
system and has the best install base (now on OS X and all linux
systems), making it easiest for users to get checkouts. If numpy,
ipython and scipy all decide to move, I would probably be inclined to
go along with it for consistency between these packages, but I
wouldn't be leading the charge. I have never felt the need for a
distributed version control system, personally, though some swear by
it. It is probably because mpl has always just had a trunk with no
branches, and I'd like to stick to that as much as possible,

Michael, how onerous was it for you to do the merges using svn -- this
seems to be the most significant problem with svn in my reading of
David's summary.

JDH

···

On Jan 7, 2008 2:37 PM, Eric Firing <efiring@...229...> wrote:

John Hunter wrote:
[...]

All this brings to mind the discussion taking place over the last week
on the numpy list regarding switching from svn to bzr or hg.
http://thread.gmane.org/gmane.comp.python.numeric.general/18130
  (I have been using hg locally for a couple years, and I like it.) The
motivation is the greater ease of branching and merging with distributed
VCS systems in comparison to SVN. In the numpy list discussion, it
sounds like all participants except Travis favor making the switch.

I'm personally -1 on this. I prefer to keep things as simple as
possible and do not see the need for a lot of branching, though there
is clearly a need for some. svn is the standard version control
system and has the best install base (now on OS X and all linux
systems), making it easiest for users to get checkouts. If numpy,
ipython and scipy all decide to move, I would probably be inclined to
go along with it for consistency between these packages, but I
wouldn't be leading the charge. I have never felt the need for a
distributed version control system, personally, though some swear by
it. It is probably because mpl has always just had a trunk with no
branches, and I'd like to stick to that as much as possible,

John,

I understand your points, and this is not something I am going to push, but I suspect that over the next year or two there will be a migration of numpy, ipython, and scipy. Certainly there is no need for us to lead, and it might be downright foolish for us to try to do so. My sense, however, is that a good DVCS is something like python itself--the majority of people who seriously try one get hooked.

The point of the DVCS is not to facilitate long-term branches; it is still normal to have a single official version. Instead, what a DVCS does is to make version control easy to use locally, regardless of whether one is connected to the net or not; and to use VC while experimenting with changes. A full working repository (and a very fast one at that) is always available. It is extremely fast and cheap to make a clone for experimentation; if things work out, the changes can be propagated back to the main repo, either as they were made initially or by first generating a single clean patch; and then the experimental repo is deleted.

I have never used hg as a central repo in a project with more than two developers (my helper and me), so I don't know exactly how it would be set up, how authentication would be handled, etc. for projects like numpy and mpl. What I do know is that using hg--and consequently having repos for our software on all the ships we work with, and on our laptops when we travel--has been a big help. I suspect that if you tried it, you would find yourself liking hg for entirely private use on work for your employer.

Eric

···

On Jan 7, 2008 2:37 PM, Eric Firing <efiring@...229...> wrote:

Michael, how onerous was it for you to do the merges using svn -- this
seems to be the most significant problem with svn in my reading of
David's summary.

JDH

Something I haven't seen addressed on the numpy list (or here) is using hg or bzr to mirror an svn repository. What would be the added advantage to the project of using a DVCS if all the DVCS-ophiles would simply sync the svn tree?

Eric Firing wrote:

···

John Hunter wrote:

On Jan 7, 2008 2:37 PM, Eric Firing <efiring@...229...> wrote:

[...]

All this brings to mind the discussion taking place over the last week
on the numpy list regarding switching from svn to bzr or hg.
http://thread.gmane.org/gmane.comp.python.numeric.general/18130
  (I have been using hg locally for a couple years, and I like it.) The
motivation is the greater ease of branching and merging with distributed
VCS systems in comparison to SVN. In the numpy list discussion, it
sounds like all participants except Travis favor making the switch.

I'm personally -1 on this. I prefer to keep things as simple as
possible and do not see the need for a lot of branching, though there
is clearly a need for some. svn is the standard version control
system and has the best install base (now on OS X and all linux
systems), making it easiest for users to get checkouts. If numpy,
ipython and scipy all decide to move, I would probably be inclined to
go along with it for consistency between these packages, but I
wouldn't be leading the charge. I have never felt the need for a
distributed version control system, personally, though some swear by
it. It is probably because mpl has always just had a trunk with no
branches, and I'd like to stick to that as much as possible,

John,

I understand your points, and this is not something I am going to push, but I suspect that over the next year or two there will be a migration of numpy, ipython, and scipy. Certainly there is no need for us to lead, and it might be downright foolish for us to try to do so. My sense, however, is that a good DVCS is something like python itself--the majority of people who seriously try one get hooked.

The point of the DVCS is not to facilitate long-term branches; it is still normal to have a single official version. Instead, what a DVCS does is to make version control easy to use locally, regardless of whether one is connected to the net or not; and to use VC while experimenting with changes. A full working repository (and a very fast one at that) is always available. It is extremely fast and cheap to make a clone for experimentation; if things work out, the changes can be propagated back to the main repo, either as they were made initially or by first generating a single clean patch; and then the experimental repo is deleted.

I have never used hg as a central repo in a project with more than two developers (my helper and me), so I don't know exactly how it would be set up, how authentication would be handled, etc. for projects like numpy and mpl. What I do know is that using hg--and consequently having repos for our software on all the ships we work with, and on our laptops when we travel--has been a big help. I suspect that if you tried it, you would find yourself liking hg for entirely private use on work for your employer.

Eric

Michael, how onerous was it for you to do the merges using svn -- this
seems to be the most significant problem with svn in my reading of
David's summary.

JDH

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Andrew Straw wrote:

Something I haven't seen addressed on the numpy list (or here) is using hg or bzr to mirror an svn repository. What would be the added advantage to the project of using a DVCS if all the DVCS-ophiles would simply sync the svn tree?

There has been numpy discussion of starting with a read-only mirror. My sense is that doing two-way synchronization may be possible using tailor, but it doesn't sound very practical. Without two-way synchronization, getting changes from the user's DVCS committed back to svn would be a clumsy process.

It also seems that even one-way synchronization from a remote svn repository can be difficult. A little googling suggests that even making a read-only *svn* mirror of an svn repository is not necessarily as easy as one might expect.

Eric

John Hunter wrote:
[...]

Michael, how onerous was it for you to do the merges using svn -- this
seems to be the most significant problem with svn in my reading of
David's summary.

Here is a new thread related to merging, and the difference between svn and a DVCS:

http://www.mail-archive.com/numpy-discussion@...336.../msg05938.html

Eric

John Hunter wrote:

(At the moment I can't compile the branch--I just sent Mike a message
about that off the list, with voluminous output.)

It seems like what is needed is not exactly a merge operation but simply
a renaming of the trunk and the branch. Maybe some doc files need to be
merged, but that is about it. Correct?

Sorry if I used sloppy terminology, all I mean is that Michael's stuff
will become the HEAD of the svn trunk, and the current HEAD of the
trunk will become a branch. No merge will be necessary since Michael
has been merging all changes in the HEAD into his branch on a ongoing
basis. I don't actually know how one does this move in svn, but I
have faith that Michael does.

I've been using svnmerge.py

http://www.orcaware.com/svn/wiki/Svnmerge.py#Quick_Usage_Overview

Essentially, it eliminates the need to remember the last points at which one branch was merged into another (which IMHO is the awful thing about svn's built-in merge). I understand this functionality will be brought into SVN proper in 1.5.

It also has a facility to merge the branch back into the trunk once we're ready. (Whether it's technically a merge or a copy, I don't really know -- that's where the line gets blurry. The point is, it should be straightforward.)

All this brings to mind the discussion taking place over the last week
on the numpy list regarding switching from svn to bzr or hg.
http://thread.gmane.org/gmane.comp.python.numeric.general/18130
  (I have been using hg locally for a couple years, and I like it.) The
motivation is the greater ease of branching and merging with distributed
VCS systems in comparison to SVN. In the numpy list discussion, it
sounds like all participants except Travis favor making the switch.

I'm personally -1 on this. I prefer to keep things as simple as
possible and do not see the need for a lot of branching, though there
is clearly a need for some. svn is the standard version control
system and has the best install base (now on OS X and all linux
systems), making it easiest for users to get checkouts. If numpy,
ipython and scipy all decide to move, I would probably be inclined to
go along with it for consistency between these packages, but I
wouldn't be leading the charge. I have never felt the need for a
distributed version control system, personally, though some swear by
it. It is probably because mpl has always just had a trunk with no
branches, and I'd like to stick to that as much as possible,

Michael, how onerous was it for you to do the merges using svn -- this
seems to be the most significant problem with svn in my reading of
David's summary.

David Cournapeau seems to have had some non-specific bad experiences with svnmerge.py. I agree, it does force you to be explicit (i.e. set up the branch correctly from the start), unlike a DVCS where it is built-in. But I've had absolutely no problems with it (maybe I'm just lucky).

I had hesitated to add to the discussion, since so much has been said already over on numpy. However, besides the merge-tracking (that svnmerge adequately meets for me) I see one other important advantage to DVCS: It's easier to create local and non-official branches (meaning created by developers without write access to the "official" repository), and track changes that aren't really ready to be shared. I worked at a place (that shall remain nameless), that used a centralized VCS, but the culture (as mandated by management) was to commit to the trunk only very rarely, usually right before an alpha or beta cycle. This meant that it was a) hard to keep track of what others were doing, b) there was a high likelihood of conflicts with others (not just at the source code level, but the logical level), c) all the ad-hoc testing that developers do as they write code had to be completely redone after this "merge" and long after the developers had forgotten about what they had written. I'm a strong believer in "continuous integration" of code. It seems to me that at its worst, a DVCS lightly discourages continuous integration because it makes it so easy to go off on tangents, and tangents aren't necessarily always a good thing if the end result is intended to be truly "one product". Tangents are necessary, yes, but their number needs to be somehow limited. This is all a matter of process, of course, and neither approach to version control really prevents any particular process -- I'd just like to make the argument that the "lots of little branches" process that DVCS make so easy, is not necessarily always appropriate.

Lastly, it seems to me that there are upteen ways to emulate a DVCS on top of a core repository that is still running on SVN. For instance, I used SVK (a DVCS specifically designed to be used in conjunction with SVN) in the above situation to maintain my sanity and keep my own local revision history. It also helps with laptop situations. Nothing is stopping anyone from doing that today, and we don't even need to know about it. I'll admit it's not really the same thing (there's would be no single way for someone else to get at my local changes), but it meets a lot of the needs with no organizational impact on others.

All this is to say, I'm sort of -0 on this -- I see as many plusses and negatives, I guess.

Cheers,
Mike

···

On Jan 7, 2008 2:37 PM, Eric Firing <efiring@...229...> wrote:

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:

Michael, since you know more about this than anyone, you should
probably spearhead the svn reorganization and let people know when the
changes become effective with some advance notice. I will update the
website with pointers to the relevant docs (your API_CHANGES and
Changelog and the relevant svn commands and anything else you think we
will need).

Here's a summary of my plan:

1) Create a tag in tags/v0_91_2 of the exact revision Charlie released as 0.91.2. This is useful to diff against.

2) Create a branch in branches/v0_91_maint that will be used exclusively for bugfixes to 0.91.x, and be the source of any future 0.91.x releases.

3) Merge branches/transforms into trunk/matplotlib

Putting the most recent API_CHANGES and CHANGELOG from the transforms branch on the web is a good idea -- however, it should be clear that it applies only to SVN versions, and not the 0.91.2 release. (It's reasonably self-evident to me, but maybe not to everyone).

As for svn instructions (applicable after the above changes):

···

====

To check out the trunk with the latest transforms refactoring:

   svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib matplotlib

If you already have a working copy of the trunk, your next "svn up" will include the latest transforms refactoring.

To check out the maintenance branch, in order to commit bugfixes to 0.91.x:

   svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_91_maint matplotlib_0_91_maint

Any applicable bugfixes on the 0.91.x should be merged into the trunk so they are fixed there as well. I will provide further instructions about this (using svnmerge.py) once I have everything in place.

====

Cheers,
Mike

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Also -- we probably want a news item to say something like this:

···

====

The experimental transforms refactoring changes have been merged into SVN trunk. While this version is passing all examples and unit tests, there may be changes that subtly break things that used to work, raise nasty exceptions or kill innocent puppies. To help move matplotlib forward, we encourage all users who are comfortable with the bleeding edge to use the trunk with their own plots and report any bugs to the mailing list. If the trunk is not working for you and you just need something that works, download the 0.91.2 release, or check out the 0.91.x maintenance branch from svn:

    svn co
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_91_maint

matplotlib_0_91_maint

====

Mike

John Hunter wrote:

Now that the 0.91.2 release is out, I am inclined to merge Michael's
transforms branch into the trunk. Since many people rely on svn, we
probably need to advertise this move broadly, with a news item on the
web page and announcements on the mailing lists, with instructions on
how to checkout the 0.91 maintenance branch (which does not exist but
would be created as the maintenance branch). There was some
suggestion earlier that we leave Michael's work on a branch, but I
think we need to get it on the trunk so developers and svn users will
get it by default which will help us move more rapidly in shaking out
the remaining bugs and problems.

Michael, since you know more about this than anyone, you should
probably spearhead the svn reorganization and let people know when the
changes become effective with some advance notice. I will update the
website with pointers to the relevant docs (your API_CHANGES and
Changelog and the relevant svn commands and anything else you think we
will need).

If this seems like a reasonable plan, perhaps we should shoot for
doing this in a day or two. If any of you think this is the wrong
approach, let us know.

JDH

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I just added MIGRATION.txt to the trunk -- after you do the merge, we
can post this document to provide the migration instructions. I've
tried to add all your text with minor reorganization and added a
general introduction. Feel free to edit and add to this document as
you see fit, and after you do the merge and new branches, I'll post it
and update a news flash on the web site.

JDH

Migrating to the new matplotlib codebase

···

On Jan 8, 2008 8:11 AM, Michael Droettboom <mdroe@...31...> wrote:

Also -- we probably want a news item to say something like this:

========================================

Michael Droettboom has spent the last several month working on the
"transforms branch" of matplotlib, in which he rewrote from the ground
up the transformation infrastructure in matplotlib, whih many found
unintuitive and hard to extend. In addition to a cleaner code base,
the refactoring allows you to define your own trasformations and
projections (eg map projections) within matplotlib. He has merged his
work into the HEAD of the svn trunk, and this will be the basis for
future matplotlib releases.

If you are a svn user, we encourage you to continue using the trunk as
before, but with the understanding that you are now truly on the
bleeding edge. Michael has made sure all the examples still pass with
the new code base, so for the vast majority of you, I except to see
few problems. But we need to get as many people as possible using the
new code base so we can find and fix the remaining problems. We have
take the svn cde used in the last stable release in the 0.91 series,
and made it a maintenance branch so we can still fix bugs and support
people who are not ready to migrate to the new transformation
infrastructure but nonetheless need acccess to svn bug fixes.

The experimental transforms refactoring changes have been merged into
SVN trunk. While this version is passing all examples and unit tests,
there may be changes that subtly break things that used to work, raise
nasty exceptions or kill innocent puppies. To help move matplotlib
forward, we encourage all users who are comfortable with the bleeding
edge to use the trunk with their own plots and report any bugs to the
mailing list.

Using the new code

To check out the trunk with the latest transforms refactoring:

    > svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib

If you already have a working copy of the trunk, your next "svn up" will
include the latest transforms refactoring.

Using the old svn code

To check out the maintenance branch, in order to commit bugfixes to 0.91.x:

    > svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_91_maint
matplotlib_0_91_maint

Any applicable bugfixes on the 0.91.x should be merged into the trunk so
they are fixed there as well.

API CHANGES in the new transformation infrastructure

While Michael worked hard to keep the API mostly unchanged while
performing what has been called "open heart surgery on matplotlib",
there have been some changes, as discussed below.

The primary goal of this refactoring was to make it easier to
extend matplotlib to support new kinds of projections. This is
primarily an internal improvement, and the possible user-visible
changes it allows are yet to come.

These changes are detailed in the API_CHANGES document

I'm all for the DVCS concept. I have recently started using git for my
own work, including reading the matplotlib repository. git includes
built-in tools to talk to svn and cvs repositories. In fact, the reason
I chose git over the alternatives (hg, bzr, etc.) is the way it allows
me to use DVCS for my own work (and, occasionally, the work of my close
collaborators) without requiring a change to an entire project's
infrastructure. Using git in this way does not allow one to take
advantage of all of the potential DVCS promises, but it goes a long way
in the right direction.

It's something to consider.

Disclaimers:
(a) I am not an active matplotlib developer.
(b) I really don't want to start a git vs. hg vs. bzr
discussion/flamewar.

--Jim Amundson

···

On Mon, 07 Jan 2008 19:54:38 -1000 Eric Firing <efiring@...229...> wrote:

Andrew Straw wrote:
> Something I haven't seen addressed on the numpy list (or here) is
> using hg or bzr to mirror an svn repository. What would be the
> added advantage to the project of using a DVCS if all the
> DVCS-ophiles would simply sync the svn tree?

There has been numpy discussion of starting with a read-only mirror.
My sense is that doing two-way synchronization may be possible using
tailor, but it doesn't sound very practical. Without two-way
synchronization, getting changes from the user's DVCS committed back
to svn would be a clumsy process.

UR DOIN IT WRONG

http://en.wikipedia.org/wiki/Refactoring

···

On Tue, 2008-01-08 at 10:48 -0800, John Hunter wrote:

To check out the trunk with the latest transforms refactoring:

The word refactoring applies to cases of code cleanup and so on.
Refactoring implies functional equivalence.

Dr. Tom
--
There is in the world much filth: so much is true! But the world itself
is not therefore a filthy monster! Thus spoke Zarathustra.

Thank you for enlightening us. This overloaded and contentious word will be replaced.

I don't think "UR DOIN IT WRONG" is an entirely correct assessment, however. Much of this change can be considered refactoring wrt to the high-level public API. For instance, I believe basemap only had to change a handful of lines of code to work with the transforms changes. It's "Refactoring with some exceptional edge cases", perhaps? At the lower levels, where matplotlib developers are concerned, however, there may be some necessary changes, and that's what the API_CHANGES and other warnings are for. And in fact, the Wikipedia entry you point to makes references to lower-level interfaces being changed as the result of refactoring.

Anyway,
Mike

Tom Holroyd wrote:

···

UR DOIN IT WRONG

http://en.wikipedia.org/wiki/Refactoring

On Tue, 2008-01-08 at 10:48 -0800, John Hunter wrote:

To check out the trunk with the latest transforms refactoring:

The word refactoring applies to cases of code cleanup and so on.
Refactoring implies functional equivalence.

Dr. Tom
--
There is in the world much filth: so much is true! But the world itself
is not therefore a filthy monster! Thus spoke Zarathustra.

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

BTW Michael, ready to go when you are

JDH

···

On Jan 8, 2008 1:49 PM, Michael Droettboom <mdroe@...31...> wrote:

Thank you for enlightening us. This overloaded and contentious word
will be replaced.

Refactoring is often defined (in test driven development) as reworking
the codebase given a complete set of tests that pass at the beginning,
and should pass at the end.

My 2 cents,

Ga�l

···

On Tue, Jan 08, 2008 at 04:49:00PM -0500, Michael Droettboom wrote:

I don't think "UR DOIN IT WRONG" is an entirely correct assessment,
however. Much of this change can be considered refactoring wrt to the
high-level public API.

Sorry, I just don't like that word. And the "UR ..." was a lame
reference to LOL Cats. :slight_smile: Sorry, sorry, I'll go away now.
P.S. I love matplotlib.

···

On Tue, 2008-01-08 at 22:53 +0100, Gael Varoquaux wrote:

On Tue, Jan 08, 2008 at 04:49:00PM -0500, Michael Droettboom wrote:
> I don't think "UR DOIN IT WRONG" is an entirely correct assessment,
> however. Much of this change can be considered refactoring wrt to the
> high-level public API.

Refactoring is often defined (in test driven development) as reworking
the codebase given a complete set of tests that pass at the beginning,
and should pass at the end.

My 2 cents,

Ga�l

Dr. Tom
--
This precept, however, give I to you, in parting, you fool: Where one
can no longer love, there should one pass by! Thus spoke Zarathustra.

Sorry -- I was too thick to get the reference. Maybe if you had included a cute picture of a kitten eating a cheeseburger or riding and invisible bicycle or something... This list needs more of those :wink:

Cheers,
Mike

Tom Holroyd wrote:

···

Sorry, I just don't like that word. And the "UR ..." was a lame
reference to LOL Cats. :slight_smile: Sorry, sorry, I'll go away now.
P.S. I love matplotlib.

On Tue, 2008-01-08 at 22:53 +0100, Gael Varoquaux wrote:

On Tue, Jan 08, 2008 at 04:49:00PM -0500, Michael Droettboom wrote:

I don't think "UR DOIN IT WRONG" is an entirely correct assessment, however. Much of this change can be considered refactoring wrt to the high-level public API.

Refactoring is often defined (in test driven development) as reworking
the codebase given a complete set of tests that pass at the beginning,
and should pass at the end.

My 2 cents,

Ga�l

Dr. Tom
--
This precept, however, give I to you, in parting, you fool: Where one
can no longer love, there should one pass by! Thus spoke Zarathustra.

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA