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 9:18 AM, Darren Dale <dsdale24@...149...> wrote:
On Sun, Jan 23, 2011 at 6:25 AM, Andrew Straw <strawman@...36...> 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
<real@...918...>" 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.
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
<real@...918...>" 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
jswhit@...679...
Jeff Whitaker <jswhit@...196...>
Regarding basemap, what do people recommend? Should I create a separate github project for basemap and it's data?
-Jeff
···
On 1/24/11 6:10 AM, Darren Dale wrote:
On Sun, Jan 23, 2011 at 9:18 AM, Darren Dale<dsdale24@...149...> wrote:
On Sun, Jan 23, 2011 at 6:25 AM, Andrew Straw<strawman@...36...> wrote:
On 23-Jan-11 04:05, John Hunter wrote:
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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
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 Mon, Jan 24, 2011 at 7:18 AM, Jeff Whitaker <jswhit@...196...> wrote:
Regarding basemap, what do people recommend? Should I create a separate
github project for basemap and it's data?
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 8:48 AM, John Hunter <jdh2358@...149...> wrote:
On Mon, Jan 24, 2011 at 7:18 AM, Jeff Whitaker <jswhit@...196...> 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.
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:11 AM, Darren Dale <dsdale24@...149...> 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'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:18 AM, John Hunter <jdh2358@...149...> 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?
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 9:18 AM, John Hunter <jdh2358@...149...> wrote:
On Mon, Jan 24, 2011 at 8:11 AM, Darren Dale <dsdale24@...149...> 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.
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 1/24/11 7:11 AM, Darren Dale wrote:
On Mon, Jan 24, 2011 at 8:48 AM, John Hunter<jdh2358@...149...> wrote:
On Mon, Jan 24, 2011 at 7:18 AM, Jeff Whitaker<jswhit@...196...> 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
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 Mon, Jan 24, 2011 at 9:18 AM, John Hunter <jdh2358@...149...> wrote:
On Mon, Jan 24, 2011 at 8:11 AM, Darren Dale <dsdale24@...149...> 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?
There is a potential problem converting the entire basemap history to
git. In svn commit 4418, trunk/toolkits had basemap and
basemap-testing directories. In commit 4419, basemap was renamed
basemap-0.9.6.1, so there was only basemap-0.9.6.1 and
basemap-testing. In commit 4420, basemap-testing is renamed basemap.
The git history only goes back as far as svn4420, it looks like the
conversion routines get confused by the temporary absence of the
basemap directory.
I'm trying to find a workaround, but if I can't... ?