Darren Dale wrote: > > > 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.". > > > Having worked with bzr and launchpad for a few months now, I wonder if > we might consider such an approach in the future. I know there has > been some experimentation with a git repository, is git supported on > windows now? I'm not sold that bzr/hg/git makes things simpler for this development model. Brett Cannon is currently developing a PEP to propose DVCS for CPython development. See here:
http://docs.google.com/View?docid=dg7fctr4_40dvjkdg64 What John is proposing for matplotlib is identical to the "Backport" use case in the PEP. As you can see, hg actually makes things a lot more complicated than svn/svnmerge in this regard. I don't know if bzr (which I have almost no experience with), or git (which I've tried to do this kind of thing but haven't found the magic incantation yet), are any better in this regard. Perhaps they are, but it's difficult to find documentation on "methodologies" rather than just "methods" for these youngish tools. I think it would be fantastic for anyone with enough knowledge able to help Brett flesh out his PEP, because then we'd all have a really clean comparison between the tools for specific use cases. And it's a very scientific and "spin-free" way forward, IMHO. So, I'm not meaning to jump on your suggestion specifically, Darren, but I think I've reached some sort of level of fatigue with people saying (mainly outside matplotlib) "if we just switched to X, all this merging/branching would be so much easier", without a specific description of how to migrate to and use X and how that's superior enough to warrant the effort. I don't mean that rhetorically -- I actually believe anything is probably better than Subversion, but specifically why and how is so often lacking. I happen to like svnmerge, because one developer (a VC specialist, if you will) can set up the branching and merge tracking and all anyone else needs to know is "svnmerge.py merge", if they care about merging at all. It always feels like using the DVCS tools that everyone is forced to know the topology of the project just to do anything with it -- that's a matter of style more than the tool, but DVCS do seem to encourage a more spaghetti-branched approach from what I've seen. Mike ------------------------------------------------------------------------------ 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 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
