On 7/20/10 8:06 PM, Fernando Perez wrote:
> On Tue, Jul 20, 2010 at 7:43 PM, John Hunter<jdh2...@gmail.com>  wrote:
>    
>> The major issues I am aware of are:
>>
>> * what do to about all the various subdirs of the mpl trunk
>> (trunk/toolkits/basemap, trunk/sample_data, etc..).  An svn commit to
>> one tags all with a unique revision number.  In git, how do we
>> synchronize between them?  Putting them all in the same tree would be
>> monolithic and require huge checkouts.  Unlike svn, in git it is
>> difficult/impossible to check out just a subdir (eg trunk/matplotlb)
>> and also commit to it.  So we might end up having to informally
>> synchronize parts of the trunk.  Eg, basemap rXXX requires mpl rYYY in
>> the CHANGELOG or release notes.
>>      
> Probably using a common tag across repos would be the easiest.  Any
> time you want a known 'sync point', you tag all the relevant repos
> with the same tag.  It then becomes very simple to write a little
> script that will update checkout a bunch of repos sitting in the same
> parent directory (each as its own dir, of course) at a common tag.
> You can make up a convention for these special tags so that they are
> always named with a given pattern (you could even use rNNNN if you
> wanted).
>    
We could also make a meta repository that uses git submodules (somewhat 
akin to svn externals). Each commit in a repo that links to submodules 
specifies a specific revision of the submodule repo, so this meta 
repository would be a fairly natural way of linking across several 
repositories at specific revisions. That being said, a convention to 
simply use the standard git tags would also work fine, and wouldn't 
require people to learn git submodules. So, it's really a question of 
sticking to a convention (that has a lesser learning curve) or using a 
new set of commands that would more or less do exactly what we want, but 
would have to be learned. I'm agnostic on the issue.


>> * organizational stuff: how do we handle the notion of the central
>> repo?  Now that github support "organizations" this should be
>> relatively easy.  Andrew and I registered a matplotlib user acct at
>> github and created a gmail acct mplgithub as a central administrator
>> (matplot...@gmail.com was taken, the bastards).  Email me offlist if
>> you are interested in obtaining the passwd for the github or gmail
>> admin accts -- but you should probably coordinate with Andrew who is
>> our point person as soon as he re-emerges.
>>      
> No need. Organizations let you designate more than one 'owner', so you
> can mark more than one person with full admin privileges without
> having to give out the password around.  I recently converted the
> extra ipython account to an organization, added Brian Granger as a
> second 'owner', and that's it.  You can then make as many teams and
> repos as you want within an organization.  The github org model is
> fairly simple but very effective (much nicer than how launchpad uses
> teams).
>    
I went ahead and switched our github.com/matplotlib account into an 
organization when github announced organization support a few weeks ago. 
Just now I added the jdh2358 and fperez users into the matplotlib 
owner's team.

(And I'm trying to re-emerge, I promise...)


>> * porting the buildbot to work w/ github commits
>>      
I should be able to handle that fairly easily. I do it for my other 
projects. (Bigger on my buildbot priority list is stopping the annoying 
occasional config directory multi-process conflict.


>> * related: porting the trunkdocs build to work with github commits
>>      
As this is run by the buildbot, it should be taken care of with the above.


For me, the main remaining issue is how do we want to pull the svn repo 
into git? Right now, the unofficial git repo at 
github.com/astraw/matplotlib is too big for my likes because it has a 
lot of stuff besides the matplotlib source code and its history. Before 
moving to an official git repository, I think we should prune down the 
main repository to just the source code files, their history, and no 
binary files. But then that leaves the question of what to do with the 
binary files.

-Andrew

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Reply via email to