Re: [matplotlib-devel] requesting permission to remove traits and configobj

On Wed, Dec 10, 2008 at 9:20 PM, Darren Dale <dsd...@gm...> wrote:

> There has been a report at the bugtracker complaining that matplotlib is
> overwriting an existing installation of configobj. I had a look at the code
> and thought the bug report must be a mistake or windows specific, but I just
> saw similar behavior on my linux system.


Ignoring for a minute the question of whether we can/should flush
configobj/traits, it sounds like the real problem is that setup.cfg is not
working like we expect it to.  And that is something that should be fixed if
is broken.  If mpl is installing configobj or traits even if we are telling
it not to via setup.cfg, then we have a problem.   This is worth knowing,
since the last mpl release was broken vis-a-vis the default backend on
win32, which *could* be explained by a broken setup.cfg.


I would like to simply remove configobj and traits from our repository. They
> are only used by the long-neglected experimental traited config package,
> which is only of interest to developers who can easily install them as
> external dependencies. Is it ok to remove them? If so, should it be done on
> all the branches?
>
> How long are we going to continue to maintain the different branches? It
> was so much easier back when we only had to worry about the trunk...
>

You can remove them from the trunk.  They should remain on the 0.91 branch
as is (with any known bugs fixed and merged) since that is the point of the
branch (stability for those who cannot upgrade -- in principle someone might
be depending on the traited config, in practice unlikely).  As for the 0.98
branch, it is slated for destruction so no worries.  I share your visceral
reaction against branches, but my head is starting to override this bodily
reaction, as I see the need for them in practice.  If we carefully document
the best practices and motivations in the developerr's guide, we can use
them advantageously.

We have a lot of people contributing to mpl, and approaching or just after
release time we need some mechanism for stabilizing the tested feature set
of the release candidate while allowing other development to proceed, and
branches are the natural mechanism for that.  That we are starting to use
them is a reflection of the fact that we have many more active developers
than we ever had before (12 developers contributed between 98.3 and 98.4, it
used to be just 3 or 4 at a time).   I wouldn't be advocating branches
otherwise, because I am an advocate of doing things as simply as
possible: "Make
everything as simple as possible, but not simpler.".

In general, I am in favor of the wildest, wooliest, development process we
can afford.  I would like to have  everyone on the trunk, making releases as
often as possible (nightly if we can), with an attitude of "if you break it,
just fix it an rerelease it".  This model worked fine for us for years, and
I think it would continue to work if we have a hyper-active developer or an
automated build bot.  In the old days, I would release any time I added a
new feaure, and if I broke something I would have a new release out in
hours.  I no longer have the time for that, and  we are lucky to have
Charlie buildng OS X and win32 binaties and eggs for multiple python
versions.  When we release broken code, Charlie has to go through the entire
test/upload/release cycle again, building for multiple OSs and python
versions while taking care of his wife and two babies, so we want to
minimize that.  At the same time, we have lots of developers pushing code
into the mainline.  We need some mechanism of balancing the desire of
developers to get new code in and the need for the packagers and release
manangers to get stable code out.

I think the right balance for mpl before a release is to test the HEAD, sign
off on it, branch it, let development proceed on the HEAD, and put any
release critical bugs and fixes into the branch.  When the next release
comes up, delete the old branch, and wash-rinse-repeat.  We will have in
perpetuity one active release branch at a time, which gets important bug
fixes and nothing else, and in addition (for a while) a legacy branch (0.91)
which is updated once a month or so.  I am happy to get input on this.

JDH