matplotlib-devel Mailing List for matplotlib (Page 3)

On Mon, Jan 24, 2011 at 9:18 AM, John Hunter <jd...@gm...> wrote:
> On Mon, Jan 24, 2011 at 8:11 AM, Darren Dale <dsd...@gm...> wrote:
>
>> That said, I have the conversion routines set up right now to create a
>> separate "toolkits" repository, which currently includes all the
>> contents of trunk/toolkits. I can tailor this further to split the
>> toolkits up and create a repository for each, if thats how people want
>> to do it. Those repos could either be hosted as separate repositories
>> under the matplotlib github organization, or maybe better as a
>> repository under a separate github project. In case of the latter, I
>> can temporarily publish the repository at my own account, long enough
>> for Jeff to clone it (don't fork it using githubs fork button!) and
>> push it to its final destination.
>
> I think mplsize should just be moved into lib/mpl_toolkits so it can
> be picked up by a default mpl installation. It's small enough that it
> probably doesn't need it's own repo. What do you think Andrew?
>
> I think natgrid could be moved into the same directory because it is
> small too, but because of licensing issues I don't think it should be
> built and installed by default. Could you handle this move Jeff, on
> fairly short notice?
>
> Is there any reason basemap should not be hosted by the mpl
> organization? Seems like the logical place to me.
Each repository can have its own issue tracker, wiki, etc., so thats
fine. But you might consider hosting documentation at github. I don't
recommend using the "gh-pages branch" method of hosting docs, which
uses a separate DAG in the main repository, and would serve them at
http://matplotlib.github.com/matplotlib. Instead, I want to propose
hosting the documentation in a repo at
https:github.com/matplotlib/matplotlib.github.com.git, which will
serve the sphinx-built docs at http://matplotlib.github.com . If the
basemap repo is hosted under mpl, its docs could be hosted like
Fernando has been suggesting, in a separate basemap-docs repo, which
would be served at http://matplotlib.github.com/basemap-docs. If
basemap had its own organization, the docs could be served at
http://basemap.github.com. Just something to keep in mind.
Darren

On Mon, Jan 24, 2011 at 8:18 AM, John Hunter <jd...@gm...> wrote:
> I think natgrid could be moved into the same directory because it is
> small too, but because of licensing issues I don't think it should be
> built and installed by default. Could you handle this move Jeff, on
> fairly short notice?
I'm going to backpedal on this one. I think including GPL code in the
core distribution, even if it is disabled by default, is a bad idea.
Let's go with separate repo.
JDH

On Mon, Jan 24, 2011 at 8:11 AM, Darren Dale <dsd...@gm...> wrote:
> That said, I have the conversion routines set up right now to create a
> separate "toolkits" repository, which currently includes all the
> contents of trunk/toolkits. I can tailor this further to split the
> toolkits up and create a repository for each, if thats how people want
> to do it. Those repos could either be hosted as separate repositories
> under the matplotlib github organization, or maybe better as a
> repository under a separate github project. In case of the latter, I
> can temporarily publish the repository at my own account, long enough
> for Jeff to clone it (don't fork it using githubs fork button!) and
> push it to its final destination.
I think mplsize should just be moved into lib/mpl_toolkits so it can
be picked up by a default mpl installation. It's small enough that it
probably doesn't need it's own repo. What do you think Andrew?
I think natgrid could be moved into the same directory because it is
small too, but because of licensing issues I don't think it should be
built and installed by default. Could you handle this move Jeff, on
fairly short notice?
Is there any reason basemap should not be hosted by the mpl
organization? Seems like the logical place to me.
JDH

On Mon, Jan 24, 2011 at 8:48 AM, John Hunter <jd...@gm...> wrote:
> On Mon, Jan 24, 2011 at 7:18 AM, Jeff Whitaker <js...@fa...> wrote:
>
>> Regarding basemap, what do people recommend? Should I create a separate
>> github project for basemap and it's data?
>
> I think that would be ideal. Unlink svn, in git you can't have full
> featured subdirectory checkouts, and since some of the projects,
> basemap included are too large to include with the core, the best
> solution is to put them in a separate repository. This complicates
> keeping versions in sync, but it seems like the best solution.
That said, I have the conversion routines set up right now to create a
separate "toolkits" repository, which currently includes all the
contents of trunk/toolkits. I can tailor this further to split the
toolkits up and create a repository for each, if thats how people want
to do it. Those repos could either be hosted as separate repositories
under the matplotlib github organization, or maybe better as a
repository under a separate github project. In case of the latter, I
can temporarily publish the repository at my own account, long enough
for Jeff to clone it (don't fork it using githubs fork button!) and
push it to its final destination.
Darren

On Mon, Jan 24, 2011 at 7:18 AM, Jeff Whitaker <js...@fa...> wrote:
> Regarding basemap, what do people recommend? Should I create a separate
> github project for basemap and it's data?
I think that would be ideal. Unlink svn, in git you can't have full
featured subdirectory checkouts, and since some of the projects,
basemap included are too large to include with the core, the best
solution is to put them in a separate repository. This complicates
keeping versions in sync, but it seems like the best solution.
JDH

On 1/24/11 6:10 AM, Darren Dale wrote:
> On Sun, Jan 23, 2011 at 9:18 AM, Darren Dale<dsd...@gm...> wrote:
>> On Sun, Jan 23, 2011 at 6:25 AM, Andrew Straw<str...@as...> wrote:
>>> On 23-Jan-11 04:05, John Hunter wrote:
>>>> Darren
>>>> if you are ready to "flip the switch" and make an official github repo
>>>> under this organization, go for it. Once we get the trunk active,
>>>> we'll worry about the rest, like migrating the release branch. Of
>>>> course, if Andrew as the original force to move to github, has any
>>>> comments or concerns, we're certainly receptive to them. But we have
>>>> a recent release out, the buildbot is broken currently anyhow, and
>>>> this looks like a perfect time to make the move.
>>> +1.
>>>
>>> And for what it's worth, I keep nagging the IT people at my new employer to
>>> set me up the virtual machines for the new buildslaves...
>> I need to improve the authorship mapping, so the authors of svn
>> commits will be identified using their git information in the new
>> repository. For the following svn accounts, I need "Real Name
>> <re...@em...o>" information as it will appear when committing to the
>> new git repository (not your old svn info, unless it will be the
>> same). Look in the [user] section of ~/.gitconfig, if you have one.
>> Please send it to me ASAP.
> I think we are getting close. Here are the remaining commit authors
> that do not have git commit information. Do we know how to reach some
> of these folks directly to ask if they want to provide it?
>
> mdboom
> mdehoon
> jswhit
js...@gi...
Jeff Whitaker <js...@fa...>
Regarding basemap, what do people recommend? Should I create a separate 
github project for basemap and it's data?
-Jeff
> jrevans
> cmoad
> heeres
> mmetz_bn
> sameerd
> pkienzle
> dmkaplan
> nnemec
> stevech
> edin1
> kmcivor
> teoliphant
> barrett
> greglielens
> jvoss2
> jaytmiller
> perrygreenfield
> jodonoghue
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a 49ドル USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Sun, Jan 23, 2011 at 9:18 AM, Darren Dale <dsd...@gm...> wrote:
> On Sun, Jan 23, 2011 at 6:25 AM, Andrew Straw <str...@as...> wrote:
>> On 23-Jan-11 04:05, John Hunter wrote:
>>>
>>> Darren
>>> if you are ready to "flip the switch" and make an official github repo
>>> under this organization, go for it. Once we get the trunk active,
>>> we'll worry about the rest, like migrating the release branch. Of
>>> course, if Andrew as the original force to move to github, has any
>>> comments or concerns, we're certainly receptive to them. But we have
>>> a recent release out, the buildbot is broken currently anyhow, and
>>> this looks like a perfect time to make the move.
>>
>> +1.
>>
>> And for what it's worth, I keep nagging the IT people at my new employer to
>> set me up the virtual machines for the new buildslaves...
>
> I need to improve the authorship mapping, so the authors of svn
> commits will be identified using their git information in the new
> repository. For the following svn accounts, I need "Real Name
> <re...@em...o>" information as it will appear when committing to the
> new git repository (not your old svn info, unless it will be the
> same). Look in the [user] section of ~/.gitconfig, if you have one.
> Please send it to me ASAP.
I think we are getting close. Here are the remaining commit authors
that do not have git commit information. Do we know how to reach some
of these folks directly to ask if they want to provide it?
mdboom
mdehoon
jswhit
jrevans
cmoad
heeres
mmetz_bn
sameerd
pkienzle
dmkaplan
nnemec
stevech
edin1
kmcivor
teoliphant
barrett
greglielens
jvoss2
jaytmiller
perrygreenfield
jodonoghue

On Sun, Jan 23, 2011 at 2:53 PM, Friedrich Romstedt
<fri...@gm...> wrote:
> I feel very much honoured by this, it is a great belated Christmas
> gift, so I like it very much that you speak up for me, but currently I
> don't feel like a "core dev". Maybe, when matplotlib-filters
> (formerly matplotlib-grayscale) is through and committed, maybe then
> I'm confident enough.
I'm curious about this project -- google doesn't reveal much.
As for commit privileges, my usual standard is that the candidate has
become a nuisance to the other developers. That is, they are
contributing patches faster than we can review them :-) That is a bit
tongue in cheek, but I do like to see several patches that reveal a
significant understanding of mpl internals and compliance with our
coding standards. Ben's handling of several 3D bugs certainly put him
in this category in my view, as this is a particularly hairy part of
the code and there were not many developers who were able to review
his patches because he was one of the few experts on this part of the
code, and handling 3D properly means you have a pretty good grasp of
the 2D stack.
Friedrich hasn't become a nuisance yet <wink>. When he does, I'll be
happy to add him....
JDH

2011年1月23日 Benjamin Root <ben...@ou...>:
> Btw, if Friedrich hasn't been made a developer
> yet, he has my vote (if he wants it).
I feel very much honoured by this, it is a great belated Christmas
gift, so I like it very much that you speak up for me, but currently I
don't feel like a "core dev". Maybe, when matplotlib-filters
(formerly matplotlib-grayscale) is through and committed, maybe then
I'm confident enough.
Best,
Friedrich

On Sat, Jan 22, 2011 at 4:23 PM, Darren Dale <dsd...@gm...> wrote:
> That said, I would be more comfortable saying "lets do this" if I heard from
> more of the debate that the drop looks ok.
In case anyone was wondering, that was the result of the android spell
checker, not alzheimers.

On Sun, Jan 23, 2011 at 6:25 AM, Andrew Straw <str...@as...> wrote:
> On 23-Jan-11 04:05, John Hunter wrote:
>>
>> Darren
>> if you are ready to "flip the switch" and make an official github repo
>> under this organization, go for it. Once we get the trunk active,
>> we'll worry about the rest, like migrating the release branch. Of
>> course, if Andrew as the original force to move to github, has any
>> comments or concerns, we're certainly receptive to them. But we have
>> a recent release out, the buildbot is broken currently anyhow, and
>> this looks like a perfect time to make the move.
>
> +1.
>
> And for what it's worth, I keep nagging the IT people at my new employer to
> set me up the virtual machines for the new buildslaves...
I need to improve the authorship mapping, so the authors of svn
commits will be identified using their git information in the new
repository. For the following svn accounts, I need "Real Name
<re...@em...o>" information as it will appear when committing to the
new git repository (not your old svn info, unless it will be the
same). Look in the [user] section of ~/.gitconfig, if you have one.
jdh2358
efiring
mdboom
mdehoon
jswhit
weathergod
leejjoon
jouni
jrevans
ryanmay
ianthomas23
cmoad
pivanov314
Please send it to me ASAP.

On 23-Jan-11 04:05, John Hunter wrote:
>
> Darren
> if you are ready to "flip the switch" and make an official github repo
> under this organization, go for it. Once we get the trunk active,
> we'll worry about the rest, like migrating the release branch. Of
> course, if Andrew as the original force to move to github, has any
> comments or concerns, we're certainly receptive to them. But we have
> a recent release out, the buildbot is broken currently anyhow, and
> this looks like a perfect time to make the move.
+1.
And for what it's worth, I keep nagging the IT people at my new employer 
to set me up the virtual machines for the new buildslaves...
-Andrew

On Saturday, January 22, 2011, John Hunter <jd...@gm...> wrote:
> On Sat, Jan 22, 2011 at 1:27 PM, Eric Firing <ef...@ha...> wrote:
>> I would like to be included in the group with git write access, unless
>> there is a clear decision to restrict this group to a very small core of
>> gatekeepers.
>
> I can add you -- any developer who currently has mpl commit privs,
> send me your github account name and I'll add you to the mpl
> organization. Although a gatekeeper model may have its merits. and
> you'd be a gatekeeper under any scenario, I prefer to keep our current
> developer model of a large number of trusted committers rather than a
> few gatekeepers.
>
> I'd be willing to reconsider this model in the face of persuasive
> argument *and* a few people willing to stand up and serve as patch
> reviewers and gatekeepers, but until then, I think we have to rely on
> good people making good contributions, in the presence of our unit
> tests and host of people serving as crash test dummies by running off
> HEAD....
>
> JDH
>
Somehow, I read that as "running with heads cut off"... It is late.
Anyway, I am willing to give a switchover a shot, and to continue the
current contrib model. Btw, if Friedrich hasn't been made a developer
yet, he has my vote (if he wants it).
Ben Root

On Sat, Jan 22, 2011 at 1:27 PM, Eric Firing <ef...@ha...> wrote:
> I would like to be included in the group with git write access, unless
> there is a clear decision to restrict this group to a very small core of
> gatekeepers.
I can add you -- any developer who currently has mpl commit privs,
send me your github account name and I'll add you to the mpl
organization. Although a gatekeeper model may have its merits. and
you'd be a gatekeeper under any scenario, I prefer to keep our current
developer model of a large number of trusted committers rather than a
few gatekeepers.
I'd be willing to reconsider this model in the face of persuasive
argument *and* a few people willing to stand up and serve as patch
reviewers and gatekeepers, but until then, I think we have to rely on
good people making good contributions, in the presence of our unit
tests and host of people serving as crash test dummies by running off
HEAD....
JDH

On Sat, Jan 22, 2011 at 3:26 PM, Darren Dale <dsd...@gm...> wrote:
> Thanks Eric, that's encouraging. I am reasonably confident, but in the
> spirit of code review/cya, I would feel better if another dev chimed in that
> they were also reasonably confident without having to take my word for it.
I agree with Eric and others in favor of flipping the switch on the
trunk/matplotlib conversion to github. Michael and I made some
comments on an earlier thread that we were happy with the svn repo,
acknowledging that as core developers we were happy using a central
svn repo but understanding that for others without easy commit access,
a distributed repo might be preferable. So the original decision made
many moons ago to switch has never been questioned, it's just that for
many of the developers, it has not been a driving need. But we'll
gladly stand behind anyone willing to do the work.
There are subtleties and difficulties around the mpl svn directories
that depend on trunk/matplotlib: sample_data, basemap, sampledoc, etc.
 I think the solution is the one advocated above: just punt on it.
Let's convert the trunk and rely on good practice to keep the others
in sync. Ie, when basemap does a release, it can just tag the release
notes with "depends on matplotlib release XX or revision YY". Likewise
with sampledata, etc.
The official repo needs to be https://github.com/matplotlib, which is
the matplotlib organization. Darren is already a member, and it
looks like he has more bandwidth at this point than Andrew, so Darren
if you are ready to "flip the switch" and make an official github repo
under this organization, go for it. Once we get the trunk active,
we'll worry about the rest, like migrating the release branch. Of
course, if Andrew as the original force to move to github, has any
comments or concerns, we're certainly receptive to them. But we have
a recent release out, the buildbot is broken currently anyhow, and
this looks like a perfect time to make the move.
JDH

On Jan 22, 2011 9:06 PM, "Darren Dale" <dsd...@gm...> wrote:
>
>
> On Jan 22, 2011 5:28 PM, "Matthew Brett" <mat...@gm...> wrote:
> >
> > Hi,
> >
> > >> >> What have been the proposed solutions to dealing with basemap's
data?
> > >> >
> > >> > Separate repo?
> >
> > I just fished up some previous discussions:
> >
> > http://comments.gmane.org/gmane.comp.python.matplotlib.devel/8275
> > http://comments.gmane.org/gmane.comp.python.matplotlib.devel/8461
> >
> > Do I remember correctly that a plan was needed to keep track of the
> > relationship of matplotlib-proper, the sample data and basemap, when
> > they are not part of the same repository?
>
> I think this could be done with a separate repo, using modules to pull in
the various components and keep the relationship in sync. I'm using modules
in one of my own projects, and have been satisfied with the way it works.
But we should really hear from the basemap devs, I don't know if they are on
board with a switch to git.
Damn spellchecker. That should read submodules, not modules.

On Jan 22, 2011 5:28 PM, "Matthew Brett" <mat...@gm...> wrote:
>
> Hi,
>
> >> >> What have been the proposed solutions to dealing with basemap's
data?
> >> >
> >> > Separate repo?
>
> I just fished up some previous discussions:
>
> http://comments.gmane.org/gmane.comp.python.matplotlib.devel/8275
> http://comments.gmane.org/gmane.comp.python.matplotlib.devel/8461
>
> Do I remember correctly that a plan was needed to keep track of the
> relationship of matplotlib-proper, the sample data and basemap, when
> they are not part of the same repository?
I think this could be done with a separate repo, using modules to pull in
the various components and keep the relationship in sync. I'm using modules
in one of my own projects, and have been satisfied with the way it works.
But we should really hear from the basemap devs, I don't know if they are on
board with a switch to git.

Hi,
>> >> What have been the proposed solutions to dealing with basemap's data?
>> >
>> > Separate repo?
I just fished up some previous discussions:
http://comments.gmane.org/gmane.comp.python.matplotlib.devel/8275
http://comments.gmane.org/gmane.comp.python.matplotlib.devel/8461
Do I remember correctly that a plan was needed to keep track of the
relationship of matplotlib-proper, the sample data and basemap, when
they are not part of the same repository?
See y'all,
Matthew

On Jan 22, 2011 2:28 PM, "Eric Firing" <ef...@ha...> wrote:
>
> On 01/22/2011 07:06 AM, Darren Dale wrote:
> > On Sat, Jan 22, 2011 at 11:55 AM, Benjamin Root<ben...@ou...> wrote:
> >> On Sat, Jan 22, 2011 at 10:26 AM, Darren Dale<dsd...@gm...>
 wrote:
> >>>
> >>> On Sat, Jan 22, 2011 at 9:09 AM, Friedrich Romstedt
> >>> <fri...@gm...> wrote:
> >>>> Hi,
> >>>>
> >>>> I want to set up a git mirror for matplotlib, but I 1) have some
minor
> >>>> problems and 2) want to know what others think about this.
> >>>
> >>> Late last year, I did some work to convert the svn repository to git.
> >>> The code to d the conversion is available at
> >>> https://github.com/darrendale/mpl2git . The resulting git repo is
> >>> available at https://github.com/darrendale/matplotlib . I have not
> >>> pursued the project further because there did not seem to be enough
> >>> interest in migrating from svn/sourceforge to git/github to justify
> >>> investing more of my time in the project.
> >>>
> >>>> I'm a native git user and I don't know how to use svn properly.
> >>>
> >>> I read that as "uninterested in learning how to use svn", and such
> >>> sentiment is probably a fact of life as many (most?) open source
> >>> projects move to DVC. In my opinion, matplotlib is likely to draw more
> >>> contributors if it lowers barriers to entry and uses a DVCS that is
> >>> growing in popularity, like git/github.
> >>>
> >>> Darren
> >>>
> >>
> >> In discussions with Ryan May on the prospect of switching over to git,
it
> >> sounds like we have a "Bike Shed" problem where we (the main
developers)
> >> agree that we agree that a bike shed should be built, but we can't
agree on
> >> the color to paint it...
> >
> > In my view, the issue has nothing to do with bikeshedding.
>
> Agreed. We *did* agree to move to git, and the only problem was that
> most of us lack the expertise and time to be of much help in actually
> getting it done. I think there was a bit of a hangup over the question
> of migrating the bug tracking; but I suspect we could agree that this is
> a secondary question, and that any such migration, if desired, can be
> done at leisure *after* taking the primary step of switching the code
repo.
>
> >
> >> I think the main source of the huge download size is the data that is
coming
> >> from the basemap toolkit. I do not think that it would be a good thing
to
> >> have everyone and their mother needing to do a 'git clone' on their
computer
> >> and find they have to pull down 500+ MB of stuff to get matplotlib. It
is
> >> because of this that a straight-forward migration from svn to
matplotlib
> >> won't be possible.
> >
> > The git repo at https://github.com/darrendale/matplotlib does not
> > include anything from basemap.
>
> The key point being that you are converting matplotlib/trunk/matplotlib,
> not matplotlib/trunk; the latter is what includes py4science, toolkits
> (including basemap), sample_data, etc. I think this is the right
approach.
>
> This doesn't all have to be perfect; it just has to be good enough. I
> suspect your conversion is good enough. If you are reasonably
> confident, then I think that if you go ahead and set up a github repo as
> the new official source tree, along with posting whatever notices are
> needed for anyone accessing the svn tree, the active developers will say
> "thank you!", and it will be done.
Thanks Eric, that's encouraging. I am reasonably confident, but in the
spirit of code review/cya, I would feel better if another dev chimed in that
they were also reasonably confident without having to take my word for it.
> The other person who has been most interested in the nuts and bolts of
> the conversion is Andrew Straw. Although he is evidently very short of
> mpl time these days, you might want to try to contact him directly to
> see if he has thought of anything you might have overlooked.
>
> I would like to be included in the group with git write access, unless
> there is a clear decision to restrict this group to a very small core of
> gatekeepers.
>
> Eric
>
> >
> >> What have been the proposed solutions to dealing with basemap's data?
> >
> > Separate repo?
> >
>
>
------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a 49ドル USD value)!
> Finally, a world-class log management solution at an even better
price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Jan 22, 2011 3:38 PM, "Friedrich Romstedt" <fri...@gm...>
wrote:
>
> 2011年1月22日 Eric Firing <ef...@ha...>:
> > This doesn't all have to be perfect; it just has to be good enough. I
> > suspect your conversion is good enough. If you are reasonably
> > confident, then I think that if you go ahead and set up a github repo as
> > the new official source tree, along with posting whatever notices are
> > needed for anyone accessing the svn tree, the active developers will say
> > "thank you!", and it will be done.
> >
> > The other person who has been most interested in the nuts and bolts of
> > the conversion is Andrew Straw. Although he is evidently very short of
> > mpl time these days, you might want to try to contact him directly to
> > see if he has thought of anything you might have overlooked.
> >
> > I would like to be included in the group with git write access, unless
> > there is a clear decision to restrict this group to a very small core of
> > gatekeepers.
>
> To support Darren's conversion work, here are the links to some numpy
> discussions which might be, I think, of interest here:
>
> [Numpy-discussion] curious about how people would feel about moving to
github:
> http://thread.gmane.org/gmane.comp.python.numeric.general/38133
>
> [Numpy-discussion] Technicalities of the SVN -> GIT transition:
> http://thread.gmane.org/gmane.comp.python.numeric.general/38263
>
> [Numpy-discussion] First shot at svn->git conversion:
> http://thread.gmane.org/gmane.comp.python.numeric.general/39443
>
> [Numpy-discussion] update on the transition to git/github:
> http://thread.gmane.org/gmane.comp.python.numeric.general/39102
>
> [Numpy-discussion] Github migration?:
> http://thread.gmane.org/gmane.comp.python.numeric.general/40020
>
> [Numpy-discussion] Can we freeze the subversion repository and move to
> github this week?:
>
http://mail.scipy.org/pipermail/numpy-discussion/2010-September/thread.html#52744
> (this thread is apparently lost on gmane)
>
> [Numpy-discussion] Numpy SVN frozen; move to Git:
>
http://mail.scipy.org/pipermail/numpy-discussion/2010-September/thread.html#52811
> (lost on Gmane too)
>
> [Numpy-discussion] Commit rights on github:
> http://thread.gmane.org/gmane.comp.python.numeric.general/40812
>
> [Numpy-discussion] Development workflow:
> http://thread.gmane.org/gmane.comp.python.numeric.general/40816
>
> [Numpy-discussion] Another merge at github:
> http://thread.gmane.org/gmane.comp.python.numeric.general/40967
>
> [Numpy-discussion] whitespace in git repo:
> http://thread.gmane.org/gmane.comp.python.numeric.general/41013
>
> Okay, I think that's it.
>
> I remember there were some problems getting the complete svn history
> correctly transferred (it should be in above), but I cannot tell
> specifics; we would have to ask on the numpy list for this.
I used Pauli's work on numpy as a template to convert the mpl tell, and I am
fairly confident that the history was correctly transferred. svn2git seems
to have improved since numpy made the leap, and appears to have handled the
merge of the transforms branch correctly, which may have been a considerable
stress-test for the conversion routines.
That said, I would be more comfortable saying "lets do this" if I heard from
more of the debate that the drop looks ok.
> Also, there was lots of discussion how to design the commit rights
> (somewhere included above); since on github "pull requests" can be
> filed, getting changes in with a committer different from the author
> is simple. Cf. http://github.com/numpy/ (list of members of the
> github organization).
>
> It is possible to register "organization" accounts on GitHub, with
> several members.
>
> Friedrich
>
>
------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a 49ドル USD value)!
> Finally, a world-class log management solution at an even better
price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

2011年1月22日 Benjamin Root <ben...@ou...>:
> Finally got around to committing this. I committed it to the maintenance
> branch in r8933 and merged into the development branch in r8934.
Okay, I agree on this, but I will work on it again once the git
transition is complete, or similar.
Thanks,
Friedrich

2011年1月22日 Eric Firing <ef...@ha...>:
> This doesn't all have to be perfect; it just has to be good enough. I
> suspect your conversion is good enough. If you are reasonably
> confident, then I think that if you go ahead and set up a github repo as
> the new official source tree, along with posting whatever notices are
> needed for anyone accessing the svn tree, the active developers will say
> "thank you!", and it will be done.
>
> The other person who has been most interested in the nuts and bolts of
> the conversion is Andrew Straw. Although he is evidently very short of
> mpl time these days, you might want to try to contact him directly to
> see if he has thought of anything you might have overlooked.
>
> I would like to be included in the group with git write access, unless
> there is a clear decision to restrict this group to a very small core of
> gatekeepers.
To support Darren's conversion work, here are the links to some numpy
discussions which might be, I think, of interest here:
[Numpy-discussion] curious about how people would feel about moving to github:
http://thread.gmane.org/gmane.comp.python.numeric.general/38133
[Numpy-discussion] Technicalities of the SVN -> GIT transition:
http://thread.gmane.org/gmane.comp.python.numeric.general/38263
[Numpy-discussion] First shot at svn->git conversion:
http://thread.gmane.org/gmane.comp.python.numeric.general/39443
[Numpy-discussion] update on the transition to git/github:
http://thread.gmane.org/gmane.comp.python.numeric.general/39102
[Numpy-discussion] Github migration?:
http://thread.gmane.org/gmane.comp.python.numeric.general/40020
[Numpy-discussion] Can we freeze the subversion repository and move to
github this week?:
http://mail.scipy.org/pipermail/numpy-discussion/2010-September/thread.html#52744
(this thread is apparently lost on gmane)
[Numpy-discussion] Numpy SVN frozen; move to Git:
http://mail.scipy.org/pipermail/numpy-discussion/2010-September/thread.html#52811
(lost on Gmane too)
[Numpy-discussion] Commit rights on github:
http://thread.gmane.org/gmane.comp.python.numeric.general/40812
[Numpy-discussion] Development workflow:
http://thread.gmane.org/gmane.comp.python.numeric.general/40816
[Numpy-discussion] Another merge at github:
http://thread.gmane.org/gmane.comp.python.numeric.general/40967
[Numpy-discussion] whitespace in git repo:
http://thread.gmane.org/gmane.comp.python.numeric.general/41013
Okay, I think that's it.
I remember there were some problems getting the complete svn history
correctly transferred (it should be in above), but I cannot tell
specifics; we would have to ask on the numpy list for this.
Also, there was lots of discussion how to design the commit rights
(somewhere included above); since on github "pull requests" can be
filed, getting changes in with a committer different from the author
is simple. Cf. http://github.com/numpy/ (list of members of the
github organization).
It is possible to register "organization" accounts on GitHub, with
several members.
Friedrich

On 1/22/11 10:26 AM, Darren Dale wrote:
> On Sat, Jan 22, 2011 at 9:09 AM, Friedrich Romstedt
> <fri...@gm...> wrote:
>> Hi,
>>
>> I want to set up a git mirror for matplotlib, but I 1) have some minor
>> problems and 2) want to know what others think about this.
>
> Late last year, I did some work to convert the svn repository to git.
> The code to d the conversion is available at
> https://github.com/darrendale/mpl2git . The resulting git repo is
> available at https://github.com/darrendale/matplotlib . I have not
> pursued the project further because there did not seem to be enough
> interest in migrating from svn/sourceforge to git/github to justify
> investing more of my time in the project.
>
>> I'm a native git user and I don't know how to use svn properly.
>
> I read that as "uninterested in learning how to use svn", and such
> sentiment is probably a fact of life as many (most?) open source
> projects move to DVC. In my opinion, matplotlib is likely to draw more
> contributors if it lowers barriers to entry and uses a DVCS that is
> growing in popularity, like git/github.
+1. There have been several times I've wanted to fix something in the 
documentation, and would have via github if it had been available. As 
it was, I sent an email to the list and someone else did it for me. In 
my case, the fixes got in, but it took more time and effort for me and 
presumably also for the people making the fix (compared to just 
responding to a pull request, for example). I do remember debating 
whether it was worth the trouble to report the typo when I realized I 
had to send an email describing exactly where the typo was.
Thanks,
Jason

On 01/22/2011 07:06 AM, Darren Dale wrote:
> On Sat, Jan 22, 2011 at 11:55 AM, Benjamin Root<ben...@ou...> wrote:
>> On Sat, Jan 22, 2011 at 10:26 AM, Darren Dale<dsd...@gm...> wrote:
>>>
>>> On Sat, Jan 22, 2011 at 9:09 AM, Friedrich Romstedt
>>> <fri...@gm...> wrote:
>>>> Hi,
>>>>
>>>> I want to set up a git mirror for matplotlib, but I 1) have some minor
>>>> problems and 2) want to know what others think about this.
>>>
>>> Late last year, I did some work to convert the svn repository to git.
>>> The code to d the conversion is available at
>>> https://github.com/darrendale/mpl2git . The resulting git repo is
>>> available at https://github.com/darrendale/matplotlib . I have not
>>> pursued the project further because there did not seem to be enough
>>> interest in migrating from svn/sourceforge to git/github to justify
>>> investing more of my time in the project.
>>>
>>>> I'm a native git user and I don't know how to use svn properly.
>>>
>>> I read that as "uninterested in learning how to use svn", and such
>>> sentiment is probably a fact of life as many (most?) open source
>>> projects move to DVC. In my opinion, matplotlib is likely to draw more
>>> contributors if it lowers barriers to entry and uses a DVCS that is
>>> growing in popularity, like git/github.
>>>
>>> Darren
>>>
>>
>> In discussions with Ryan May on the prospect of switching over to git, it
>> sounds like we have a "Bike Shed" problem where we (the main developers)
>> agree that we agree that a bike shed should be built, but we can't agree on
>> the color to paint it...
>
> In my view, the issue has nothing to do with bikeshedding.
Agreed. We *did* agree to move to git, and the only problem was that 
most of us lack the expertise and time to be of much help in actually 
getting it done. I think there was a bit of a hangup over the question 
of migrating the bug tracking; but I suspect we could agree that this is 
a secondary question, and that any such migration, if desired, can be 
done at leisure *after* taking the primary step of switching the code repo.
>
>> I think the main source of the huge download size is the data that is coming
>> from the basemap toolkit. I do not think that it would be a good thing to
>> have everyone and their mother needing to do a 'git clone' on their computer
>> and find they have to pull down 500+ MB of stuff to get matplotlib. It is
>> because of this that a straight-forward migration from svn to matplotlib
>> won't be possible.
>
> The git repo at https://github.com/darrendale/matplotlib does not
> include anything from basemap.
The key point being that you are converting matplotlib/trunk/matplotlib,
not matplotlib/trunk; the latter is what includes py4science, toolkits 
(including basemap), sample_data, etc. I think this is the right approach.
This doesn't all have to be perfect; it just has to be good enough. I 
suspect your conversion is good enough. If you are reasonably 
confident, then I think that if you go ahead and set up a github repo as 
the new official source tree, along with posting whatever notices are 
needed for anyone accessing the svn tree, the active developers will say 
"thank you!", and it will be done.
The other person who has been most interested in the nuts and bolts of 
the conversion is Andrew Straw. Although he is evidently very short of 
mpl time these days, you might want to try to contact him directly to 
see if he has thought of anything you might have overlooked.
I would like to be included in the group with git write access, unless 
there is a clear decision to restrict this group to a very small core of 
gatekeepers.
Eric
>
>> What have been the proposed solutions to dealing with basemap's data?
>
> Separate repo?
>

On Sat, Jan 22, 2011 at 11:55 AM, Benjamin Root <ben...@ou...> wrote:
> On Sat, Jan 22, 2011 at 10:26 AM, Darren Dale <dsd...@gm...> wrote:
>>
>> On Sat, Jan 22, 2011 at 9:09 AM, Friedrich Romstedt
>> <fri...@gm...> wrote:
>> > Hi,
>> >
>> > I want to set up a git mirror for matplotlib, but I 1) have some minor
>> > problems and 2) want to know what others think about this.
>>
>> Late last year, I did some work to convert the svn repository to git.
>> The code to d the conversion is available at
>> https://github.com/darrendale/mpl2git . The resulting git repo is
>> available at https://github.com/darrendale/matplotlib . I have not
>> pursued the project further because there did not seem to be enough
>> interest in migrating from svn/sourceforge to git/github to justify
>> investing more of my time in the project.
>>
>> > I'm a native git user and I don't know how to use svn properly.
>>
>> I read that as "uninterested in learning how to use svn", and such
>> sentiment is probably a fact of life as many (most?) open source
>> projects move to DVC. In my opinion, matplotlib is likely to draw more
>> contributors if it lowers barriers to entry and uses a DVCS that is
>> growing in popularity, like git/github.
>>
>> Darren
>>
>
> In discussions with Ryan May on the prospect of switching over to git, it
> sounds like we have a "Bike Shed" problem where we (the main developers)
> agree that we agree that a bike shed should be built, but we can't agree on
> the color to paint it...
In my view, the issue has nothing to do with bikeshedding.
> I think the main source of the huge download size is the data that is coming
> from the basemap toolkit. I do not think that it would be a good thing to
> have everyone and their mother needing to do a 'git clone' on their computer
> and find they have to pull down 500+ MB of stuff to get matplotlib. It is
> because of this that a straight-forward migration from svn to matplotlib
> won't be possible.
The git repo at https://github.com/darrendale/matplotlib does not
include anything from basemap.
> What have been the proposed solutions to dealing with basemap's data?
Separate repo?