matplotlib-devel Mailing List for matplotlib

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 guess this can be done after the conversion: split it into its own
repo, fix the hierarchy and then do an external merge from that repo
to draw it into the matplotlib repo under lib/mpl_toolkits.

On 1/24/11 7:11 AM, Darren Dale wrote:
> 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
Darren: I think having them as separate repos under the matplotlib 
organization is fine. If you could do that I would be grateful.
-Jeff

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