Re: [matplotlib-devel] git migration this weekend
Darren Dale dsdal...@gmail.com writes: On Sat, Feb 26, 2011 at 5:58 PM, Eric Firing efir...@hawaii.edu wrote: On 02/26/2011 10:54 AM, Darren Dale wrote: The submitter info is lost? And when it was originally submitted? No, I can improve it so this information is included. That's clearly in the xml file, except that I don't know if we can map sourceforge userids to email addresses - that sounds like something that spammers would want to do. One thing that I think is missing in the xml file are the attachment contents. There are filenames and some kind of ids that presumably can be used to get the files via the sf bug pages, but this information only occurs in the artifact_history subsection. To get the correct files you'll have to first parse this to figure out that file 396374 was added but then deleted and then file 396688 was added: field name=artifact_history history field name=field_nameFile Added/field field name=old_value396688: set_verts_cleanup_2.patch/field field name=entrydate1293000689/field field name=mod_bynotmuchtotell/field /history history field name=field_nameFile Deleted/field field name=old_value396374: /field field name=entrydate1293000467/field field name=mod_bynotmuchtotell/field /history history field name=field_nameFile Added/field field name=old_value396374: set_verts_cleanup.patch/field field name=entrydate1292605835/field field name=mod_bynotmuchtotell/field /history I agree that the github interface is not great. The github devs seem to know that everybody complains about it. There are some good things about it though. Labels, the ability to link between an issue and the commits that resolve it, the ability for people to provide feedback on what issues are important to them. Does anyone have experience with other trackers? bugs.python.org seems to be using Roundup - any experiences with that? -- Jouni K. Seppänen http://www.iki.fi/jks -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration this weekend
On Sun, Feb 27, 2011 at 9:45 AM, Darren Dale dsdal...@gmail.com wrote: On Sun, Feb 27, 2011 at 8:32 AM, Darren Dale dsdal...@gmail.com wrote: If we are not convinced that github issues provides everything we need, I think we should provide feedback to the github devs and stick with sourceforge for the time being. Here is a copy of a message I just sent to supp...@github.com. If you have other specific concerns, please let me know, and I will pass them along if I hear back from someone at github. Here is the exchange I had with one of github's support staff: GH: Thank you very much for your feedback. We already work on improving issues. DD: Thank you for your reply. Is it ok if I relay this information to the other developers on my project? GH: Yes, but let me just say that we never have an ETA and also I can't confirm that you'll be completely satisfied with our improvements. -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration this weekend
On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing efir...@hawaii.edu wrote: On 02/16/2011 08:38 AM, Darren Dale wrote: On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perezfperez@gmail.com wrote: are you guys planning on transfering the old bugs to github? Probably at some point. As I mentioned, I have code lying around for the upload (and to download from launchpad, but that's irrelevant here). I'm going to be mosly offline til Monday (conference trip), but if someone pings me on my Berkeley email address, which I monitor even while traveling, I'll be happy to help out. Thanks, that would be very helpful. I'll follow up once I figure out how to extract the information from sourceforge. Darren, Just a heads-up on that: In November the tracker was heavily spammed. Recently I marked a few hundred items with the delete disposition, but I don't think that actually gets rid of them. If it doesn't, then maybe they can be filtered out during the transfer. We have some additional spam that needs to be deleted. How did you do it? When I try to delete several at once (mass change), I get an error message: XSRF Attempt Detected! -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration this weekend
On 02/26/2011 09:26 AM, Darren Dale wrote: On Wed, Feb 16, 2011 at 2:19 PM, Eric Firingefir...@hawaii.edu wrote: On 02/16/2011 08:38 AM, Darren Dale wrote: On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perezfperez@gmail.com wrote: are you guys planning on transfering the old bugs to github? Probably at some point. As I mentioned, I have code lying around for the upload (and to download from launchpad, but that's irrelevant here). I'm going to be mosly offline til Monday (conference trip), but if someone pings me on my Berkeley email address, which I monitor even while traveling, I'll be happy to help out. Thanks, that would be very helpful. I'll follow up once I figure out how to extract the information from sourceforge. Darren, Just a heads-up on that: In November the tracker was heavily spammed. Recently I marked a few hundred items with the delete disposition, but I don't think that actually gets rid of them. If it doesn't, then maybe they can be filtered out during the transfer. We have some additional spam that needs to be deleted. How did you do it? When I try to delete several at once (mass change), I get an error message: XSRF Attempt Detected! I made the tracker display the maximum number of entries per page, then clicked check all, then mass update with delete, and it marked them as deleted--but they never get deleted. They are still there, but marked deleted. It sounds like that is the same as what you tried, so I don't know why you are getting that error message. Which tracker category is showing the new spam? Eric -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration this weekend
On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing efir...@hawaii.edu wrote: On 02/26/2011 09:26 AM, Darren Dale wrote: On Wed, Feb 16, 2011 at 2:19 PM, Eric Firingefir...@hawaii.edu wrote: On 02/16/2011 08:38 AM, Darren Dale wrote: On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perezfperez@gmail.com wrote: are you guys planning on transfering the old bugs to github? Probably at some point. As I mentioned, I have code lying around for the upload (and to download from launchpad, but that's irrelevant here). I'm going to be mosly offline til Monday (conference trip), but if someone pings me on my Berkeley email address, which I monitor even while traveling, I'll be happy to help out. Thanks, that would be very helpful. I'll follow up once I figure out how to extract the information from sourceforge. Darren, Just a heads-up on that: In November the tracker was heavily spammed. Recently I marked a few hundred items with the delete disposition, but I don't think that actually gets rid of them. If it doesn't, then maybe they can be filtered out during the transfer. We have some additional spam that needs to be deleted. How did you do it? When I try to delete several at once (mass change), I get an error message: XSRF Attempt Detected! I made the tracker display the maximum number of entries per page, then clicked check all, then mass update with delete, and it marked them as deleted--but they never get deleted. They are still there, but marked deleted. It sounds like that is the same as what you tried, so I don't know why you are getting that error message. Which tracker category is showing the new spam? The Feature Requests. I was not able to mark the spam as deleted, but I filtered it out in the conversion. The tracker export xml file and conversion script are up at https://github.com/darrendale/mpl-issues , and the issues can be previewedeThe tracker export xml file and conversion script are up at https://github.com/darrendale/mpl-issues/issues at The tracker export xml file and conversion script are up at https://github.com/darrendale/mpl-issues/issues . Devs, please have a look. I only imported the open issues, including bugs, patches, feature requests and support requests. If we decide to use the github tracker, we can tell sourceforge we have relocated the project, and the project will remain intact and archived. I don't know if that would mean that we can no longer host the homepage at sourceforge. -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration this weekend
On Sat, Feb 26, 2011 at 3:52 PM, Darren Dale dsdal...@gmail.com wrote: On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing efir...@hawaii.edu wrote: On 02/26/2011 09:26 AM, Darren Dale wrote: On Wed, Feb 16, 2011 at 2:19 PM, Eric Firingefir...@hawaii.edu wrote: On 02/16/2011 08:38 AM, Darren Dale wrote: On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perezfperez@gmail.com wrote: are you guys planning on transfering the old bugs to github? Probably at some point. As I mentioned, I have code lying around for the upload (and to download from launchpad, but that's irrelevant here). I'm going to be mosly offline til Monday (conference trip), but if someone pings me on my Berkeley email address, which I monitor even while traveling, I'll be happy to help out. Thanks, that would be very helpful. I'll follow up once I figure out how to extract the information from sourceforge. Darren, Just a heads-up on that: In November the tracker was heavily spammed. Recently I marked a few hundred items with the delete disposition, but I don't think that actually gets rid of them. If it doesn't, then maybe they can be filtered out during the transfer. We have some additional spam that needs to be deleted. How did you do it? When I try to delete several at once (mass change), I get an error message: XSRF Attempt Detected! I made the tracker display the maximum number of entries per page, then clicked check all, then mass update with delete, and it marked them as deleted--but they never get deleted. They are still there, but marked deleted. It sounds like that is the same as what you tried, so I don't know why you are getting that error message. Which tracker category is showing the new spam? The Feature Requests. I was not able to mark the spam as deleted, but I filtered it out in the conversion. Let me try again: The tracker export xml file and conversion script are up at https://github.com/darrendale/mpl-issues , and the issues can be previewed at https://github.com/darrendale/mpl-issues/issues . Devs, please have a look. I only imported the open issues, including bugs, patches, feature requests and support requests. If we decide to use the github tracker, we can tell sourceforge we have relocated the project, and the project will remain intact and archived. I don't know if that would mean that we can no longer host the homepage at sourceforge. -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration this weekend
On 02/26/2011 10:54 AM, Darren Dale wrote: On Sat, Feb 26, 2011 at 3:52 PM, Darren Daledsdal...@gmail.com wrote: On Sat, Feb 26, 2011 at 2:52 PM, Eric Firingefir...@hawaii.edu wrote: On 02/26/2011 09:26 AM, Darren Dale wrote: On Wed, Feb 16, 2011 at 2:19 PM, Eric Firingefir...@hawaii.eduwrote: On 02/16/2011 08:38 AM, Darren Dale wrote: On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perezfperez@gmail.com wrote: are you guys planning on transfering the old bugs to github? Probably at some point. As I mentioned, I have code lying around for the upload (and to download from launchpad, but that's irrelevant here). I'm going to be mosly offline til Monday (conference trip), but if someone pings me on my Berkeley email address, which I monitor even while traveling, I'll be happy to help out. Thanks, that would be very helpful. I'll follow up once I figure out how to extract the information from sourceforge. Darren, Just a heads-up on that: In November the tracker was heavily spammed. Recently I marked a few hundred items with the delete disposition, but I don't think that actually gets rid of them. If it doesn't, then maybe they can be filtered out during the transfer. We have some additional spam that needs to be deleted. How did you do it? When I try to delete several at once (mass change), I get an error message: XSRF Attempt Detected! I made the tracker display the maximum number of entries per page, then clicked check all, then mass update with delete, and it marked them as deleted--but they never get deleted. They are still there, but marked deleted. It sounds like that is the same as what you tried, so I don't know why you are getting that error message. Which tracker category is showing the new spam? The Feature Requests. I was not able to mark the spam as deleted, but I filtered it out in the conversion. Let me try again: The tracker export xml file and conversion script are up at https://github.com/darrendale/mpl-issues , and the issues can be previewed at https://github.com/darrendale/mpl-issues/issues . Devs, please have a look. I only imported the open issues, including bugs, patches, feature requests and support requests. If we decide to use the github tracker, we can tell sourceforge we have relocated the project, and the project will remain intact and archived. I don't know if that would mean that we can no longer host the homepage at sourceforge. The submitter info is lost? And when it was originally submitted? If yes to either, then I think that we should not transfer these from sourceforge, but deal with them there. Overall, the tracking interface on github looks so bad that I can't see why we would want to move. Sourceforge is slow, but at least the tracker has the right sort of functionality: the ability to scan a lot of info on one screen, the ability to categorize, attach files, assign, etc. Maybe some of this is available but not evident in the github tracker, but what I see is not encouraging. Mpl historically has not done well in using the tracker. I hope that eventually we can transition to a tool that will help us do better, not worse. Eric -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration this weekend
On Sat, Feb 26, 2011 at 3:24 PM, Darren Dale dsdal...@gmail.com wrote: I agree that the github interface is not great. The github devs seem to know that everybody complains about it. Yup. I hold on to the hope that, because it's so egregiously, painfully broken and braindead and it stands out so badly in comparison to the rest of github (which is brilliant), that it won't be too long before this improves. Granted, we can't know what's on their internal todo list, but those guys are obviously good and listen to feedback (from what I've seen elsewhere on the site), and their bug tracker has become something of a laughing stock, so I can only imagine that they're actually working on it. In the meantime, Min recently pointed out this interesting alternative: http://githubissues.heroku.com/#darrendale/mpl-issues You can point it to any repository you want, and it makes interacting with the issue list far, far saner than via github itself. We're using now that interface ourselves for IPython: http://githubissues.heroku.com/#ipython/ipython and I have to say that I like it quite a bit. For those on OSX, this can even be installed to run locally, with the feel of a native app (it's still a webkit app, but it launches like a local app). Something to keep in mind as you make the decision... In the end, in IPython we decided to move to github in order to benefit from the close integration between pull requests, bugs and commits. Pull requests automatically create an issue, one can close bugs automatically from the commit message, etc. I figured these things would be nice to have for an everyday workflow, and that eventually github itself would improve its native bug system. Cheers, f -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration this weekend
On 02/26/2011 01:44 PM, Fernando Perez wrote: On Sat, Feb 26, 2011 at 3:24 PM, Darren Daledsdal...@gmail.com wrote: I agree that the github interface is not great. The github devs seem to know that everybody complains about it. Yup. I hold on to the hope that, because it's so egregiously, painfully broken and braindead and it stands out so badly in comparison to the rest of github (which is brilliant), that it won't be too long before this improves. Granted, we can't know what's on their internal todo list, but those guys are obviously good and listen to feedback (from what I've seen elsewhere on the site), and their bug tracker has become something of a laughing stock, so I can only imagine that they're actually working on it. In the meantime, Min recently pointed out this interesting alternative: http://githubissues.heroku.com/#darrendale/mpl-issues It is impressive, and improves some aspects, but I don't see that it makes the github tracker usable for new tickets. I don't see any facility for attaching a file--is this correct? We really want users with problems and suggestions to attach minimal example files, patches, whatever--as downloadable files, not pasted into the comment box. My inclination would be to keep using the SF tracker exclusively until the github tracker improves substantially, and then switch. Eric You can point it to any repository you want, and it makes interacting with the issue list far, far saner than via github itself. We're using now that interface ourselves for IPython: http://githubissues.heroku.com/#ipython/ipython and I have to say that I like it quite a bit. For those on OSX, this can even be installed to run locally, with the feel of a native app (it's still a webkit app, but it launches like a local app). Something to keep in mind as you make the decision... In the end, in IPython we decided to move to github in order to benefit from the close integration between pull requests, bugs and commits. Pull requests automatically create an issue, one can close bugs automatically from the commit message, etc. I figured these things would be nice to have for an everyday workflow, and that eventually github itself would improve its native bug system. Cheers, f -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration this weekend
On Wed, Feb 16, 2011 at 7:57 PM, Michael Droettboom md...@stsci.edu wrote: On 02/16/2011 03:53 PM, John Hunter wrote: On Wed, Feb 16, 2011 at 2:47 PM, Michael Droettboommd...@stsci.edu wrote: Not sure Sourceforge allows custom hooks in SVN. We have a couple in place already https://sourceforge.net/project/admin/svn.php?group_id=80706 Yes. But those aren't custom -- SF only provides a fixed set of scripts one can apply. Notably, I don't think there's one that prevents further commits. If that is the case, then let's just change the permissions for all the devs to read-only. We can leave the tracker, feature requests, and so forth enabled until we are ready to disable them at some later time. Once the website is online at matplotlib.github.com, we can follow the directions for project relocation at https://sourceforge.net/project/admin/removal.php?group_id=80706 . SourceForge will keep the project intact as an archive. Darren -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration this weekend
On Sun, Jan 30, 2011 at 8:10 AM, Darren Dale dsdal...@gmail.com wrote: On Thu, Jan 27, 2011 at 9:34 PM, Darren Dale dsdal...@gmail.com wrote: Hi Folks, I'm planning on freezing the sourceforge svn repository Friday evening at 8:00 (NY time), and moving the git repository to its new home on Saturday morning. If you have concerns, please speak up. John discovered a problem with some very early project history that was lost several years ago during the CVS to Subversion migration. We have an opportunity to recover it during the git migration. However, do to a recent attack, Sourceforge has taken their CVS service down, and based on the latest information at http://sourceforge.net/blog/ , they do not expect it to be back before late this week. I do not think I will available to work on the migration this upcoming weekend, Feb 4-6. So it will probably be February 7 or 8 before I have a chance to try to recover the old history, convert the repos to git, and post them to github. It looks like the history we were looking for does not exist in the CVS repository either. John, could you freeze the svn repo around noon on Friday? I'll convert the repositories and push them up to github on Saturday. Is it possible to close the sourceforge bugtracker, feature requests, etc to new issues as well? Darren -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration this weekend
Hey, On Wed, Feb 16, 2011 at 5:00 AM, Darren Dale dsdal...@gmail.com wrote: John, could you freeze the svn repo around noon on Friday? I'll convert the repositories and push them up to github on Saturday. Is it possible to close the sourceforge bugtracker, feature requests, etc to new issues as well? are you guys planning on transfering the old bugs to github? As I mentioned, I have code lying around for the upload (and to download from launchpad, but that's irrelevant here). I'm going to be mosly offline til Monday (conference trip), but if someone pings me on my Berkeley email address, which I monitor even while traveling, I'll be happy to help out. Glad to see eveythong moving over to github! (since scipy is also about to do the same, as soon as 0.9 is out, for which things are already at the RC stage). A huge thank you to Darren for putting so much hard work into this, I admire your attention to detail (and I wish I'd been so thorough when I transitioned ipython, where we could have recovered from some old history problems, but I'm too lazy for that :). Cheers, f -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration this weekend
On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez fperez@gmail.com wrote: are you guys planning on transfering the old bugs to github? Probably at some point. As I mentioned, I have code lying around for the upload (and to download from launchpad, but that's irrelevant here). I'm going to be mosly offline til Monday (conference trip), but if someone pings me on my Berkeley email address, which I monitor even while traveling, I'll be happy to help out. Thanks, that would be very helpful. I'll follow up once I figure out how to extract the information from sourceforge. Glad to see eveythong moving over to github! (since scipy is also about to do the same, as soon as 0.9 is out, for which things are already at the RC stage). A huge thank you to Hang on, don't jinx it. Darren -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration this weekend
On Wed, Feb 16, 2011 at 19:57, John Hunter jdh2...@gmail.com wrote: On Wed, Feb 16, 2011 at 7:00 AM, Darren Dale dsdal...@gmail.com wrote: John, could you freeze the svn repo around noon on Friday? I'll convert the repositories and push them up to github on Saturday. Is it possible to close the sourceforge bugtracker, feature requests, etc to new issues as well? I did some poking around and do not see an easy way to freeze the repo. I can disable it, but then I think it won't be available for read access. One thing I could do is remove commit privs for every developer, making the repo read only going forward. This seems like a reasonable approach. a pre-commit hook that just exit 1 ? it prevents commits but not checkouts. Just my 2c, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration this weekend
On Wed, Feb 16, 2011 at 1:30 PM, Sandro Tosi mo...@debian.org wrote: On Wed, Feb 16, 2011 at 19:57, John Hunter jdh2...@gmail.com wrote: On Wed, Feb 16, 2011 at 7:00 AM, Darren Dale dsdal...@gmail.com wrote: John, could you freeze the svn repo around noon on Friday? I'll convert the repositories and push them up to github on Saturday. Is it possible to close the sourceforge bugtracker, feature requests, etc to new issues as well? I did some poking around and do not see an easy way to freeze the repo. I can disable it, but then I think it won't be available for read access. One thing I could do is remove commit privs for every developer, making the repo read only going forward. This seems like a reasonable approach. a pre-commit hook that just exit 1 ? it prevents commits but not checkouts. Just my 2c, Even better, a pre-commit hook that also echos out a message stating where to go. And maybe a pre-update/pre-checkout hook that does something similar? Ben Root -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration this weekend
Not sure Sourceforge allows custom hooks in SVN. Mike On 02/16/2011 02:45 PM, Benjamin Root wrote: On Wed, Feb 16, 2011 at 1:30 PM, Sandro Tosi mo...@debian.org mailto:mo...@debian.org wrote: On Wed, Feb 16, 2011 at 19:57, John Hunter jdh2...@gmail.com mailto:jdh2...@gmail.com wrote: On Wed, Feb 16, 2011 at 7:00 AM, Darren Dale dsdal...@gmail.com mailto:dsdal...@gmail.com wrote: John, could you freeze the svn repo around noon on Friday? I'll convert the repositories and push them up to github on Saturday. Is it possible to close the sourceforge bugtracker, feature requests, etc to new issues as well? I did some poking around and do not see an easy way to freeze the repo. I can disable it, but then I think it won't be available for read access. One thing I could do is remove commit privs for every developer, making the repo read only going forward. This seems like a reasonable approach. a pre-commit hook that just exit 1 ? it prevents commits but not checkouts. Just my 2c, Even better, a pre-commit hook that also echos out a message stating where to go. And maybe a pre-update/pre-checkout hook that does something similar? Ben Root -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration this weekend
On Wed, Feb 16, 2011 at 2:47 PM, Michael Droettboom md...@stsci.edu wrote: Not sure Sourceforge allows custom hooks in SVN. We have a couple in place already https://sourceforge.net/project/admin/svn.php?group_id=80706 -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration this weekend
On 02/16/2011 03:53 PM, John Hunter wrote: On Wed, Feb 16, 2011 at 2:47 PM, Michael Droettboommd...@stsci.edu wrote: Not sure Sourceforge allows custom hooks in SVN. We have a couple in place already https://sourceforge.net/project/admin/svn.php?group_id=80706 Yes. But those aren't custom -- SF only provides a fixed set of scripts one can apply. Notably, I don't think there's one that prevents further commits. Mike -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] git migration
The git migration is still on hold, pending the return of CVS service at sourceforge. According to someone on the sourceforge IRC channel, CVS is estimated to return this week, but it might slip to next week. Darren -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration
On Feb 7, 2011, at 3:17 PM, Andrew Straw straw...@astraw.com wrote: On 07-Feb-11 17:13, Darren Dale wrote: The git migration is still on hold, pending the return of CVS service at sourceforge. According to someone on the sourceforge IRC channel, CVS is estimated to return this week, but it might slip to next week. Thanks for the update. At some point, one could get tarballs of the entire version control history from SF. I wonder if it would (still) be possible to simply download a tarball of the CVS history. I tried looking around a bit, but couldn't find them. Several years ago, I remember they used to be more prominent, but then, as of a year or two ago, they moved to a much less visible location. They were still available, but a bit trickier to find. Anyhow, I think it's worth a few days more wait to try to get the (almost) pre-history of MPL into git. Responding by phone so I have limited ability to tinker, but take a look at this link. Should be able to guess the mpl URL from this info if the haven't reoranized http://www.python.org/dev/peps/pep-0347/#downloading-the-cvs-repository -Andrew -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration
On Mon, Feb 7, 2011 at 5:41 PM, John Hunter jdh2...@gmail.com wrote: On Feb 7, 2011, at 3:17 PM, Andrew Straw straw...@astraw.com wrote: On 07-Feb-11 17:13, Darren Dale wrote: The git migration is still on hold, pending the return of CVS service at sourceforge. According to someone on the sourceforge IRC channel, CVS is estimated to return this week, but it might slip to next week. Thanks for the update. At some point, one could get tarballs of the entire version control history from SF. I wonder if it would (still) be possible to simply download a tarball of the CVS history. I tried looking around a bit, but couldn't find them. Several years ago, I remember they used to be more prominent, but then, as of a year or two ago, they moved to a much less visible location. They were still available, but a bit trickier to find. Anyhow, I think it's worth a few days more wait to try to get the (almost) pre-history of MPL into git. Responding by phone so I have limited ability to tinker, but take a look at this link. Should be able to guess the mpl URL from this info if the haven't reoranized http://www.python.org/dev/peps/pep-0347/#downloading-the-cvs-repository This is a really helpful link, thanks John. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration this weekend
On Thu, Jan 27, 2011 at 9:34 PM, Darren Dale dsdal...@gmail.com wrote: Hi Folks, I'm planning on freezing the sourceforge svn repository Friday evening at 8:00 (NY time), and moving the git repository to its new home on Saturday morning. If you have concerns, please speak up. John discovered a problem with some very early project history that was lost several years ago during the CVS to Subversion migration. We have an opportunity to recover it during the git migration. However, do to a recent attack, Sourceforge has taken their CVS service down, and based on the latest information at http://sourceforge.net/blog/ , they do not expect it to be back before late this week. I do not think I will available to work on the migration this upcoming weekend, Feb 4-6. So it will probably be February 7 or 8 before I have a chance to try to recover the old history, convert the repos to git, and post them to github. Darren -- 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 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] git migration this weekend
Hi Folks, I'm planning on freezing the sourceforge svn repository Friday evening at 8:00 (NY time), and moving the git repository to its new home on Saturday morning. If you have concerns, please speak up. Darren -- 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 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration
On Tue, Mar 2, 2010 at 11:41 PM, Eric Firing efir...@hawaii.edu wrote: Andrew Straw wrote: [...] This is a good point. My preferred option is that we jettison all the stuff that is not going to be shipped with MPL 1.0 from the git repo. (More correctly - we build a git repo without that stuff ever going in.) We can keep the old svn tree around and migrate the other projects to git as desired. I think this is what's present in http://github.com/astraw/matplotlib . Or am I missing something? No, that is what you have, and I agree that this strategy makes sense. I just wanted to make sure everyone understood, and make the plan explicit. It looks like Andrew has trunk/matplotlib. There is other stuff in trunk that definitely should not be migrated, and some stuff that needs consideration. * trunk/py4science, which is a project Fernando and I have been working on for several years but is not specific to mpl (it only uses mpl). We will eventually migrate this into it's own repo, but this is not an mpl project and should not be migrated. * trunk/course - looks like a very old and no longer used py4science dir. Should probably be simply deleted and not frozen *trunk/htdocs - the old mpl site docs. Should live somewhere for archival purposes in case there is a useful code snippet in there, but certainly does not need to be in git or the new repo. It could live frozen in the sf repo. * trunk/sampledata - this is important. The mpl trunk examples use this to pull example data. We will need to migrate this -- we could leave it in sf svn, but it might be preferable to have one version control system. Whatever we do here, we will need to update matplotlib.cbook.get_sample_data to work with the new system. Definitely an argument for getting all this migration sorted out before a trunk release. * trunk/sampledoc_tut - this is the source code for the http://matplotlib.sf.net/sampledoc tutorial which shows how to build mpl like sites using sphinx and associated extensions. Related to mpl in that it uses the plot directive etc, but is by no means integral. I can eventually port this to a new repo if there is any reason to. * trunk/scipy06 should probably be deleted * trunk/toolkits - should probably be migrated (Andrew you have not migrated this right?). One nice thing about having the toolkits in the same svn repo as the main codebase was for revision tagging, so basemap svn commits are synched with a trunk/matplotlib state. How should we proceed with the toolkits repo? Jeff? * trunk/users_guide - the old latex source for the mpl user's guide. Deprecated but should not be deleted. Same treatment as trunk/htdocs above. If we end up migratinga the toolkits to git/github (pending Jeff's comments) we may want to branch the stuff in trunk we want to keep for archival purposes (htdocs, users_guide) and clean as much stuff out of trunk as possible to avoid confusion for people browsing the trunk (and put a README in there explaining what and where stuff is). I think the plan is to keep trunk/matplotlib as a tracking repo, so that commits to the git master are pushed to the svn repo, so casual users who are running from svn HEAD will not be affected by the migration. Is this your understanding, Andrew? Does it makes sense to retain the entire history in the new github repo, or would it be just as well to start from a later point so as to reduce the size? The entire history could still be available in a separate read-only repo, or fossilized in svn on sourceforge, or in my hg mirror. (Andrew's repo, at just under 200MB, is not prohibitively large by any means, but it is a bit hefty.) I can see advantages either way, but I'm in favor keeping it. Tons of MPL is undercommented, and seeing the history is extremely useful when spelunking. I am strongly in favor of keeping the entire commit history of trunk/matplotlib. While the repo is large now, most of the size comes from data and regression test images, and the early history is largely code so will not add much incremental size. I suppose one of the downsides of git is since you have to get the *entire* history on one checkout, you end up with a bunch of stuff you are unlikely to ever need, like data that was once in the repo but has now been removed (eg the stuff we migrated to sampledata). Not sure if there is an easy solution here. JDH -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration
On Wed, Mar 3, 2010 at 8:29 AM, william ratcliff william.ratcl...@gmail.com wrote: I don't want to get into a flame war over this, but if Sourceforge was pressured into this and is having complaints and google has the same problem, how does Github get around it? Are they incorporated in the US or outside? If this is likely to become a problem, is there another service that can be used with git besides github that would not eventually be subject to such constraints? Sorry, I'm just ignorant about such matters. github has it's offices in the US and so they may change their policy on this in the future if they feel the heat from the long arm of the US law. Currently they do not appear to enforce export restrictions. Here is a helpful summary of different open source hosting facilities and their features and policies: http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities On Jan 25th, 2010, SF implemented a ban enforcing US export restrictions. http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/ But on Feb 7th, 2010, they lifted the blanket ban and now project admins can impose the restriction if they are distributing restricted technologies, which seems like a good compromise. http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/ Looks like the wikipedia site I linked above is out of date w/ respect to sourceforge. As far as I know, mpl is not distributing any restricted technologies -- we do make extensive use of message digest functions like md5 for caching, but these do not appear to be covered (eg, see http://www.fourmilab.ch/md5). So it would be preferable to be on a host that does not implement blanket restrictions. github does not currently, and if they change their policy going forward we may elect to move. Given that sourceforge has found a way to distribute compliant code to restricted countries, and github currently does not impose restrictions, I'm cautiously optimistic that a subsequent move will not be necessary. JDH -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration
John Hunter wrote: On Tue, Mar 2, 2010 at 11:41 PM, Eric Firing efir...@hawaii.edu wrote: Andrew Straw wrote: [...] This is a good point. My preferred option is that we jettison all the stuff that is not going to be shipped with MPL 1.0 from the git repo. (More correctly - we build a git repo without that stuff ever going in.) We can keep the old svn tree around and migrate the other projects to git as desired. I think this is what's present in http://github.com/astraw/matplotlib . Or am I missing something? No, that is what you have, and I agree that this strategy makes sense. I just wanted to make sure everyone understood, and make the plan explicit. It looks like Andrew has trunk/matplotlib. There is other stuff in trunk that definitely should not be migrated, and some stuff that needs consideration. * trunk/py4science, which is a project Fernando and I have been working on for several years but is not specific to mpl (it only uses mpl). We will eventually migrate this into it's own repo, but this is not an mpl project and should not be migrated. * trunk/course - looks like a very old and no longer used py4science dir. Should probably be simply deleted and not frozen *trunk/htdocs - the old mpl site docs. Should live somewhere for archival purposes in case there is a useful code snippet in there, but certainly does not need to be in git or the new repo. It could live frozen in the sf repo. * trunk/sampledata - this is important. The mpl trunk examples use this to pull example data. We will need to migrate this -- we could leave it in sf svn, but it might be preferable to have one version control system. Whatever we do here, we will need to update matplotlib.cbook.get_sample_data to work with the new system. Definitely an argument for getting all this migration sorted out before a trunk release. * trunk/sampledoc_tut - this is the source code for the http://matplotlib.sf.net/sampledoc tutorial which shows how to build mpl like sites using sphinx and associated extensions. Related to mpl in that it uses the plot directive etc, but is by no means integral. I can eventually port this to a new repo if there is any reason to. * trunk/scipy06 should probably be deleted * trunk/toolkits - should probably be migrated (Andrew you have not migrated this right?). One nice thing about having the toolkits in the same svn repo as the main codebase was for revision tagging, so basemap svn commits are synched with a trunk/matplotlib state. How should we proceed with the toolkits repo? Jeff? John, Eric, Andrew: I am OK with this. Don't know much about DVCS systems, but I guess this will be my excuse to learn. -Jeff * trunk/users_guide - the old latex source for the mpl user's guide. Deprecated but should not be deleted. Same treatment as trunk/htdocs above. If we end up migratinga the toolkits to git/github (pending Jeff's comments) we may want to branch the stuff in trunk we want to keep for archival purposes (htdocs, users_guide) and clean as much stuff out of trunk as possible to avoid confusion for people browsing the trunk (and put a README in there explaining what and where stuff is). I think the plan is to keep trunk/matplotlib as a tracking repo, so that commits to the git master are pushed to the svn repo, so casual users who are running from svn HEAD will not be affected by the migration. Is this your understanding, Andrew? Does it makes sense to retain the entire history in the new github repo, or would it be just as well to start from a later point so as to reduce the size? The entire history could still be available in a separate read-only repo, or fossilized in svn on sourceforge, or in my hg mirror. (Andrew's repo, at just under 200MB, is not prohibitively large by any means, but it is a bit hefty.) I can see advantages either way, but I'm in favor keeping it. Tons of MPL is undercommented, and seeing the history is extremely useful when spelunking. I am strongly in favor of keeping the entire commit history of trunk/matplotlib. While the repo is large now, most of the size comes from data and regression test images, and the early history is largely code so will not add much incremental size. I suppose one of the downsides of git is since you have to get the *entire* history on one checkout, you end up with a bunch of stuff you are unlikely to ever need, like data that was once in the repo but has now been removed (eg the stuff we migrated to sampledata). Not sure if there is an easy solution here. JDH -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta.
Re: [matplotlib-devel] git migration
I am strongly in favor of keeping the entire commit history of trunk/matplotlib. While the repo is large now, most of the size comes from data and regression test images, and the early history is largely code so will not add much incremental size. I suppose one of the downsides of git is since you have to get the *entire* history on one checkout, you end up with a bunch of stuff you are unlikely to ever need, like data that was once in the repo but has now been removed (eg the stuff we migrated to sampledata). Not sure if there is an easy solution here. I think you should be able to use git clone --depth=x to get a shallow copy of the repository. The limitation is that you cannot push from or pull from your new repository. You can pull to it and create patches though, which is enough for most people I think. Best, Jon. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] git migration
All, I think the git migration deserves its own thread on the devel list, so here is a start. The full svn repo includes much more than just matplotlib: also course, htdocs, py4science, sample_data, sampledoc_tut, scipy06, toolkits, and users_guide. Before moving matplotlib, I think we should have a clear plan as to how these other parts are going to be handled. Will some or all remain as the active parts of the svn repo, with matplotlib somehow marked as invalid? Will some or all get their own github repos? My primary interest here is toolkits/basemap, but I am sure other good stuff is in there. Before the transition, it would be good to have a pointers to the simplest possible docs illustrating typical workflows after the transition; maybe one for present developers with svn access, and another for occasional contributors. Does it makes sense to retain the entire history in the new github repo, or would it be just as well to start from a later point so as to reduce the size? The entire history could still be available in a separate read-only repo, or fossilized in svn on sourceforge, or in my hg mirror. (Andrew's repo, at just under 200MB, is not prohibitively large by any means, but it is a bit hefty.) Eric -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration
Eric Firing wrote: All, I think the git migration deserves its own thread on the devel list, so here is a start. To the uninitiated - a decision is being made that MPL is moving to git and github. We hope that this move will foster greater contributions from the community and a blurring of the line between MPL committers and users. The decision process happened off-list to keep the flames and bike-shedding minimal. Several of the core developers were consulted and we all agreed that a move to a DVCS was desirable and inevitable. We did not unanimously agree that git was best, but it was preferred by most developers over mercurial/bitbucket, the other serious contender, and neither camp voiced strong objections to the other system. The full svn repo includes much more than just matplotlib: also course, htdocs, py4science, sample_data, sampledoc_tut, scipy06, toolkits, and users_guide. Before moving matplotlib, I think we should have a clear plan as to how these other parts are going to be handled. Will some or all remain as the active parts of the svn repo, with matplotlib somehow marked as invalid? Will some or all get their own github repos? My primary interest here is toolkits/basemap, but I am sure other good stuff is in there. This is a good point. My preferred option is that we jettison all the stuff that is not going to be shipped with MPL 1.0 from the git repo. (More correctly - we build a git repo without that stuff ever going in.) We can keep the old svn tree around and migrate the other projects to git as desired. I think this is what's present in http://github.com/astraw/matplotlib . Or am I missing something? Another issue is whether to use github's Issue's system over SourceForge's tracker. Personally, I'm in favor of moving the issue tracking to github, but I think we should take stock of how we use the tracker as see if github's features will support that. Before the transition, it would be good to have a pointers to the simplest possible docs illustrating typical workflows after the transition; maybe one for present developers with svn access, and another for occasional contributors. I agree. I think the best learning material is from github. See http://help.github.com/ and http://learn.github.com/ , for example. To get to the a ha feeling, I highly recommend Git from the bottom up by John Wiegley, available from http://ftp.newartisans.com/pub/git.from.bottom.up.pdf . This latter is what it took for me to come to a real understanding of git. Git was designed from the data structures and plumbing up, and that the rest (porcelain in git parlance) came later and was less the focus of initial development. Hence, the history is that git had a rougher UI from the start and other DVCSs having nicer UIs but less stable and fast repository formats. (Understanding the git model of the universe was key to me becoming really fluent in git, but according to my office mate, it's absolutely not necessary to use git for daily tasks. ) Does it makes sense to retain the entire history in the new github repo, or would it be just as well to start from a later point so as to reduce the size? The entire history could still be available in a separate read-only repo, or fossilized in svn on sourceforge, or in my hg mirror. (Andrew's repo, at just under 200MB, is not prohibitively large by any means, but it is a bit hefty.) I can see advantages either way, but I'm in favor keeping it. Tons of MPL is undercommented, and seeing the history is extremely useful when spelunking. -Andrew -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration
On Tue, Mar 2, 2010 at 9:17 PM, Andrew Straw straw...@astraw.com wrote: Eric Firing wrote: All, I think the git migration deserves its own thread on the devel list, so here is a start. To the uninitiated - a decision is being made that MPL is moving to git and github. We hope that this move will foster greater contributions from the community and a blurring of the line between MPL committers and users. The decision process happened off-list to keep the flames and bike-shedding minimal. Several of the core developers were consulted and we all agreed that a move to a DVCS was desirable and inevitable. We did not unanimously agree that git was best, but it was preferred by most developers over mercurial/bitbucket, the other serious contender, and neither camp voiced strong objections to the other system. Apart from being inflammatory, has anyone considered code.google.com (GC) as a solution? To me amongst all code hosting sites (launchpad, sourceforge, bitbucket, github) GC provides the simplest and the most effective interface. There is also practically very less learning curve on GC comparing to other alternatives. This is a great advantage for the newcomers to the project. For instance SF has all the useful code management functionalities but their interface is really not inviting --at least to my eyes. It takes a while also before the site content are indexed by crawlers. On the negative side, GC doesn't offer git. However the source could be externally linked like in the sympy project. What do you think? Does simplicity really counts on the decision or the functionality beats simplicity? -- Gökhan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration
Hi, Apart from being inflammatory, has anyone considered code.google.com (GC) as a solution? ;) - speaking as someone with no right to offer an opinion - please, no. Google blocks Cuba from google code completely, for no obvious reason, and a) that seems to me quite wrong and outside the spirit of free software and b) I work there fairly often and it's hard for me to persuade the excellent scientists there to use Python if they are being specifically blocked for political reasons. See you, Matthew -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration
On Tue, Mar 2, 2010 at 11:03 PM, Matthew Brett matthew.br...@gmail.comwrote: Hi, Apart from being inflammatory, has anyone considered code.google.com(GC) as a solution? ;) - speaking as someone with no right to offer an opinion - please, no. Google blocks Cuba from google code completely, for no obvious reason, and a) that seems to me quite wrong and outside the spirit of free software and b) I work there fairly often and it's hard for me to persuade the excellent scientists there to use Python if they are being specifically blocked for political reasons. See you, Matthew I didn't really know that Google was embargoing countries on their code hosting site. I was more inspired after watching this talk Google I/O 2008 - Project Hosting on Google Code http://www.youtube.com/watch?v=62x17hG6Wvo It is very interesting for a company that does great things for the OSS also blocking code access on certain countries. Thanks for pointing this out. Indeed an important point consider. This is not the first time today my Google integration idea has been rejected. During our school's tech forum I asked them the possibilities of integrating Google Apps to the university network. The lower cost was a reasonable answer, but it is beyond my logic to understand that possible plans to integrate something that is not even up (live.edu) :) -- Gökhan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration
Andrew Straw wrote: [...] This is a good point. My preferred option is that we jettison all the stuff that is not going to be shipped with MPL 1.0 from the git repo. (More correctly - we build a git repo without that stuff ever going in.) We can keep the old svn tree around and migrate the other projects to git as desired. I think this is what's present in http://github.com/astraw/matplotlib . Or am I missing something? No, that is what you have, and I agree that this strategy makes sense. I just wanted to make sure everyone understood, and make the plan explicit. Eri -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration
Eric Firing wrote: All, I think the git migration deserves its own thread on the devel list, so here is a start. Explanation: the last bit of discussion was actually off-list, but because it was tacked onto a matplotlib-users list thread, and appeared there in my mailer, I failed to notice that matplotlib-users was not in the address list. So I jumped to the conclusion that it was already on a list, but was merely misplaced and should be shifted to matplotlib-devel. I apologize for the error. To minimize the potential unproductive thrashing, I request that everyone restrain their urges to comment on the choice of git and github, to suggest alternatives, to raise objections, etc. Eric -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration
I think there's a legal reason for the embargo--sourceforge apparently also has such a policy: http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/ http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/So, as a US company, they may not have a choice... On Wed, Mar 3, 2010 at 12:39 AM, Gökhan Sever gokhanse...@gmail.com wrote: On Tue, Mar 2, 2010 at 11:03 PM, Matthew Brett matthew.br...@gmail.comwrote: Hi, Apart from being inflammatory, has anyone considered code.google.com(GC) as a solution? ;) - speaking as someone with no right to offer an opinion - please, no. Google blocks Cuba from google code completely, for no obvious reason, and a) that seems to me quite wrong and outside the spirit of free software and b) I work there fairly often and it's hard for me to persuade the excellent scientists there to use Python if they are being specifically blocked for political reasons. See you, Matthew I didn't really know that Google was embargoing countries on their code hosting site. I was more inspired after watching this talk Google I/O 2008 - Project Hosting on Google Code http://www.youtube.com/watch?v=62x17hG6Wvo It is very interesting for a company that does great things for the OSS also blocking code access on certain countries. Thanks for pointing this out. Indeed an important point consider. This is not the first time today my Google integration idea has been rejected. During our school's tech forum I asked them the possibilities of integrating Google Apps to the university network. The lower cost was a reasonable answer, but it is beyond my logic to understand that possible plans to integrate something that is not even up (live.edu) :) -- Gökhan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration
Hi, On Tue, Mar 2, 2010 at 10:17 PM, william ratcliff william.ratcl...@gmail.com wrote: I think there's a legal reason for the embargo--sourceforge apparently also has such a policy: http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/ So, as a US company, they may not have a choice... In my experience Google is the worst in this respect by a considerable margin, and has become more so in the last year. See you, Matthew -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
