Menu
▾
▴
python-control-discuss
|
From: Richard M. <mu...@cd...> - 2012-09-05 04:51:11
|
You should have all gotten the message below about a new URL for the python-control source repository. The move occured because I upgraded to SourceForge 2.0, the new version of the software (based on the Allura platform). If you have a checkout of the old subversion repository, you should recheckout using the URL below. A couple of other updates: * SourceForge is going to be discontinued their hosted apps, which include the MediaWiki application that we are currently using. I'll be shifting the developer information off of that wiki onto the default SourceForge wiki. The one thing that won't transfer is the detailed VTOL example, since equations are not supported on the SF wiki. I've copied that information to my own wiki for now. * I'll be using python-control for our undergrad controls course at Caltech this fall, and will try to use that as a driver for updating various functions and adding in any missing capabilities. If you have requests for features you would like to see added, please send e-mail to this list or create a new feature request on the SourceForge page. -richard Begin forwarded message: > From: SourceForge.net <nor...@in...> > Subject: SourceForge Repo Clone Complete > Date: 2 September 2012 22:25:47 PDT > To: no...@in... > Reply-To: no...@in... > > Your cloned repository code in project python-control is now ready for use. > > Old repository url: http://python-control.svn.sourceforge.net/svnroot/python-control > > New repository checkout command: svn checkout --username=murrayrm svn+ssh://mur...@sv.../p/python-control/code/trunk python-control-code > > You and any other developers should do a fresh checkout using the new repository location. > |
|
From: Dale L. P. <haz...@gm...> - 2012-09-05 16:56:47
|
> As far as how to switch to github, I guess the easiest way, if SF offers a > "convert this repository to git" button, is to press that button and then > clone the SF repository to your local computer, create a github repository > and then push your local repository onto github. (Then maybe delete the SF > one or at least block writing to it.) Andrew has summed it up much better than I could is right on the money in his description. Is there such a shiny button in SF? A bit of googling seemed to indicate that the svn->git process might involve several steps, and the final structure of the generated repo depends on those steps. If SF has taken care of this, it would be really nice. Once a git repo is generated, Andrew's description of how to put it on github is definitely the easiest way. Luke |
|
From: Richard M. <mu...@cd...> - 2012-09-05 18:14:44
|
As far as I can tell, sourceforge doesn't have anything in particular to automate the conversion, it just allows you to have both a subversion and git repository at the same time. -richard On 5 Sep 2012, at 9:56 , Dale Lukas Peterson <haz...@gm...> wrote: >> As far as how to switch to github, I guess the easiest way, if SF offers a >> "convert this repository to git" button, is to press that button and then >> clone the SF repository to your local computer, create a github repository >> and then push your local repository onto github. (Then maybe delete the SF >> one or at least block writing to it.) > > Andrew has summed it up much better than I could is right on the money > in his description. > > Is there such a shiny button in SF? A bit of googling seemed to > indicate that the svn->git process might involve several steps, and > the final structure of the generated repo depends on those steps. If > SF has taken care of this, it would be really nice. Once a git repo > is generated, Andrew's description of how to put it on github is > definitely the easiest way. > > Luke > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > python-control-discuss mailing list > pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-control-discuss |
|
From: Richard M. <mu...@cd...> - 2014-07-27 18:33:54
|
Spurred by Clancy's discussion about SciPy, I wanted to bring up again the idea of switching python-control over to git and/or github. I'm attaching below part of a discussion on this list that had a summary that Andrew Straw sent out. Here is one possible approach that we are using with pretty good success on another project: * We move the control-python code over to github. I already have set up a project on github for this (a long time ago) and James Goppert has a clone on github => we could basically clone James's version into the project directory and then set everyone up as developers. * We use github feature/bug lists for developers. I find the functionality that github provides to be quite good, including the ability to reference commit's in posts. * We leave the tarballs for python-control releases and copies of user manuals on sourceforge. This is constant with the matplotlib approach that Andrew describes below. As far as I know, github does not provide this functionality. * We leave the mailing lists for the project on SourceForge. Near as I can tell, github doesn't have good functionality here. I would also suggest that we reorganize the lists just a bit: - python-control-announce: use for announcements of new releases, features - python-control-discuss: use for user discussions about python-control (i.e., re-purpose this mailing list) - python-control-developers: use for developer discussions about python-control (new list) The reason for re-purposing the discuss list is that a couple of people have contacted me about wanting to discuss features, but aren't really interested in developer traffic (e.g., e-mails on commits). * We eventually use the python-control project on github as the master copy for PyPI and also for code coverage testing. James Goppert has this running on his version, so hopefully he would be willing to just switch things over for us and also keep maintaining that functionality. It would be great to get some comments on this from anyone who has an opinion! -richard On 5 Sep 2012, at 1:31 , Andrew Straw <str...@as...> wrote: > On 09/05/2012 08:10 AM, Richard Murray wrote: >> There hasn't been much conversation about this, but converting to git is probably the way to go in the long run (better functionality for distributed development). Sourceforge supports git and we can easily transfer projects from subversion to git: >> >> >> https://sourceforge.net/apps/trac/sourceforge/ticket/24534 >> >> >> I don't have much experience with github versus sourceforge in terms of the various features, and so don't have a strong preference beyond doing whatever works best for the people who are actively developing code for the library. >> > > As an example, when matplotlib switched from the code repository using svn + sourceforce to git + github, there was a dramatic increase in contributions. MPL continues to use sourceforge for the email lists. The issue tracking was later switched to github, despite some missing functionality, in order to have integration with the version control system (having "closed issue" messages linked to the commit that closed them). All that said, these data are from some time ago (2 years, approximately) -- since that time, sourceforge seems to have made some dramatic changes (adding git, revising their issue tracking system) and I cannot fairly compare sourceforge's current offerings. See https://github.com/matplotlib/matplotlib for the MPL github respository. So, my evidence is that your criterion of "whatever works best for the people who are actively developing code for the library" will be best served by moving to github because you'll gain new contributors. This was more-or-less the discussion we had in the matplotlib email list and, although I haven't quantified it, the evidence of new contributors is very clear. > > You'll also gain resonance with similar minds using similar tools and also possibly interested in python-control, thus increasing the likely number of high-quality contributions. Here are some projects that all use github as their primary repository as far as I know: > > * numpy https://github.com/numpy/numpy > * IPython https://github.com/ipython/ipython > * sympy https://github.com/sympy/sympy > * scipy https://github.com/scipy/scipy > * ROS https://github.com/ros > > As far as how to switch to github, I guess the easiest way, if SF offers a "convert this repository to git" button, is to press that button and then clone the SF repository to your local computer, create a github repository and then push your local repository onto github. (Then maybe delete the SF one or at least block writing to it.) > > -Andrew > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ > python-control-discuss mailing list > pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-control-discuss |
|
From: Scott C. L. <sli...@cd...> - 2014-07-27 20:13:30
|
On 27/07/14 11:33, Richard Murray wrote: > * We leave the tarballs for python-control releases and copies of user manuals on sourceforge. This is constant with the matplotlib approach that Andrew describes below. As far as I know, github does not provide this functionality. GitHub provides capabilities for releases and project websites: 1. https://help.github.com/articles/about-releases 2. https://help.github.com/articles/what-are-github-pages A significant alternative to hosting manuals on GitHub Pages or SourceForge.net is "Read the Docs" (https://readthedocs.org/), which easily hosts documentation for multiple releases and provides export mechanisms (e.g., to PDF). For an example, try https://virtualenv.readthedocs.org/ I discourage using GitHub for distributing releases because GitHub previously has gone through a cycle of offering it, then removing it [1], and then allowing releases again [2]. [1] https://github.com/blog/1302-goodbye-uploads [2] https://github.com/blog/1547-release-your-software |
|
From: Clancy R. <cwr...@pr...> - 2014-07-28 14:12:46
|
This all sounds very sensible to me. I am strongly in favor of moving to GitHub, and I think the combination of GitHub for hosting the repository and SourceForge for hosting the releases and mailing lists is a good one. It seems to be used by a number of other projects besides matplotlib too: for instance, scikit-learn is a popular package for machine learning tools, and it looks like that is what they do: https://scikits.appspot.com/scikit-learn -clancy On Jul 27, 2014, at 2:33 PM, Richard Murray <mu...@cd...> wrote: > Spurred by Clancy's discussion about SciPy, I wanted to bring up again the idea of switching python-control over to git and/or github. I'm attaching below part of a discussion on this list that had a summary that Andrew Straw sent out. > > Here is one possible approach that we are using with pretty good success on another project: > > * We move the control-python code over to github. I already have set up a project on github for this (a long time ago) and James Goppert has a clone on github => we could basically clone James's version into the project directory and then set everyone up as developers. > > * We use github feature/bug lists for developers. I find the functionality that github provides to be quite good, including the ability to reference commit's in posts. > > * We leave the tarballs for python-control releases and copies of user manuals on sourceforge. This is constant with the matplotlib approach that Andrew describes below. As far as I know, github does not provide this functionality. > > * We leave the mailing lists for the project on SourceForge. Near as I can tell, github doesn't have good functionality here. I would also suggest that we reorganize the lists just a bit: > > - python-control-announce: use for announcements of new releases, features > - python-control-discuss: use for user discussions about python-control (i.e., re-purpose this mailing list) > - python-control-developers: use for developer discussions about python-control (new list) > > The reason for re-purposing the discuss list is that a couple of people have contacted me about wanting to discuss features, but aren't really interested in developer traffic (e.g., e-mails on commits). > > * We eventually use the python-control project on github as the master copy for PyPI and also for code coverage testing. James Goppert has this running on his version, so hopefully he would be willing to just switch things over for us and also keep maintaining that functionality. > > It would be great to get some comments on this from anyone who has an opinion! > > -richard > > On 5 Sep 2012, at 1:31 , Andrew Straw <str...@as...> wrote: > >> On 09/05/2012 08:10 AM, Richard Murray wrote: >>> There hasn't been much conversation about this, but converting to git is probably the way to go in the long run (better functionality for distributed development). Sourceforge supports git and we can easily transfer projects from subversion to git: >>> >>> >>> https://sourceforge.net/apps/trac/sourceforge/ticket/24534 >>> >>> >>> I don't have much experience with github versus sourceforge in terms of the various features, and so don't have a strong preference beyond doing whatever works best for the people who are actively developing code for the library. >>> >> >> As an example, when matplotlib switched from the code repository using svn + sourceforce to git + github, there was a dramatic increase in contributions. MPL continues to use sourceforge for the email lists. The issue tracking was later switched to github, despite some missing functionality, in order to have integration with the version control system (having "closed issue" messages linked to the commit that closed them). All that said, these data are from some time ago (2 years, approximately) -- since that time, sourceforge seems to have made some dramatic changes (adding git, revising their issue tracking system) and I cannot fairly compare sourceforge's current offerings. See https://github.com/matplotlib/matplotlib for the MPL github respository. So, my evidence is that your criterion of "whatever works best for the people who are actively developing code for the library" will be best served by moving to github because you'll gain new contributors. This was more-or-le! > ss the discussion we had in the matplotlib email list and, although I haven't quantified it, the evidence of new contributors is very clear. >> >> You'll also gain resonance with similar minds using similar tools and also possibly interested in python-control, thus increasing the likely number of high-quality contributions. Here are some projects that all use github as their primary repository as far as I know: >> >> * numpy https://github.com/numpy/numpy >> * IPython https://github.com/ipython/ipython >> * sympy https://github.com/sympy/sympy >> * scipy https://github.com/scipy/scipy >> * ROS https://github.com/ros >> >> As far as how to switch to github, I guess the easiest way, if SF offers a "convert this repository to git" button, is to press that button and then clone the SF repository to your local computer, create a github repository and then push your local repository onto github. (Then maybe delete the SF one or at least block writing to it.) >> >> -Andrew >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ >> python-control-discuss mailing list >> pyt...@li... >> https://lists.sourceforge.net/lists/listinfo/python-control-discuss > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > python-control-discuss mailing list > pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-control-discuss |
|
From: Jason M. <moo...@gm...> - 2014-07-28 19:51:54
|
+1 to moving to github. I believe that many projects find that their software is used more and that the number of contributors grows when switching to github (or other distributed version control systems with nice interactive web interfaces). Jason moorepants.info +01 530-601-9791 On Mon, Jul 28, 2014 at 7:12 AM, Clancy Rowley <cwr...@pr...> wrote: > This all sounds very sensible to me. I am strongly in favor of moving to > GitHub, and I think the combination of GitHub for hosting the repository > and SourceForge for hosting the releases and mailing lists is a good one. > It seems to be used by a number of other projects besides matplotlib too: > for instance, scikit-learn is a popular package for machine learning tools, > and it looks like that is what they do: > https://scikits.appspot.com/scikit-learn > > -clancy > > On Jul 27, 2014, at 2:33 PM, Richard Murray <mu...@cd...> > wrote: > > > Spurred by Clancy's discussion about SciPy, I wanted to bring up again > the idea of switching python-control over to git and/or github. I'm > attaching below part of a discussion on this list that had a summary that > Andrew Straw sent out. > > > > Here is one possible approach that we are using with pretty good success > on another project: > > > > * We move the control-python code over to github. I already have set up > a project on github for this (a long time ago) and James Goppert has a > clone on github => we could basically clone James's version into the > project directory and then set everyone up as developers. > > > > * We use github feature/bug lists for developers. I find the > functionality that github provides to be quite good, including the ability > to reference commit's in posts. > > > > * We leave the tarballs for python-control releases and copies of user > manuals on sourceforge. This is constant with the matplotlib approach that > Andrew describes below. As far as I know, github does not provide this > functionality. > > > > * We leave the mailing lists for the project on SourceForge. Near as I > can tell, github doesn't have good functionality here. I would also > suggest that we reorganize the lists just a bit: > > > > - python-control-announce: use for announcements of new releases, > features > > - python-control-discuss: use for user discussions about python-control > (i.e., re-purpose this mailing list) > > - python-control-developers: use for developer discussions about > python-control (new list) > > > > The reason for re-purposing the discuss list is that a couple of people > have contacted me about wanting to discuss features, but aren't really > interested in developer traffic (e.g., e-mails on commits). > > > > * We eventually use the python-control project on github as the master > copy for PyPI and also for code coverage testing. James Goppert has this > running on his version, so hopefully he would be willing to just switch > things over for us and also keep maintaining that functionality. > > > > It would be great to get some comments on this from anyone who has an > opinion! > > > > -richard > > > > On 5 Sep 2012, at 1:31 , Andrew Straw <str...@as...> wrote: > > > >> On 09/05/2012 08:10 AM, Richard Murray wrote: > >>> There hasn't been much conversation about this, but converting to git > is probably the way to go in the long run (better functionality for > distributed development). Sourceforge supports git and we can easily > transfer projects from subversion to git: > >>> > >>> > >>> https://sourceforge.net/apps/trac/sourceforge/ticket/24534 > >>> > >>> > >>> I don't have much experience with github versus sourceforge in terms > of the various features, and so don't have a strong preference beyond doing > whatever works best for the people who are actively developing code for the > library. > >>> > >> > >> As an example, when matplotlib switched from the code repository using > svn + sourceforce to git + github, there was a dramatic increase in > contributions. MPL continues to use sourceforge for the email lists. The > issue tracking was later switched to github, despite some missing > functionality, in order to have integration with the version control system > (having "closed issue" messages linked to the commit that closed them). All > that said, these data are from some time ago (2 years, approximately) -- > since that time, sourceforge seems to have made some dramatic changes > (adding git, revising their issue tracking system) and I cannot fairly > compare sourceforge's current offerings. See > https://github.com/matplotlib/matplotlib for the MPL github respository. > So, my evidence is that your criterion of "whatever works best for the > people who are actively developing code for the library" will be best > served by moving to github because you'll gain new contributors. This was > more-or-le! > > ss the discussion we had in the matplotlib email list and, although I > haven't quantified it, the evidence of new contributors is very clear. > >> > >> You'll also gain resonance with similar minds using similar tools and > also possibly interested in python-control, thus increasing the likely > number of high-quality contributions. Here are some projects that all use > github as their primary repository as far as I know: > >> > >> * numpy https://github.com/numpy/numpy > >> * IPython https://github.com/ipython/ipython > >> * sympy https://github.com/sympy/sympy > >> * scipy https://github.com/scipy/scipy > >> * ROS https://github.com/ros > >> > >> As far as how to switch to github, I guess the easiest way, if SF > offers a "convert this repository to git" button, is to press that button > and then clone the SF repository to your local computer, create a github > repository and then push your local repository onto github. (Then maybe > delete the SF one or at least block writing to it.) > >> > >> -Andrew > >> > >> > ------------------------------------------------------------------------------ > >> Live Security Virtual Conference > >> Exclusive live event will cover all the ways today's security and > >> threat landscape has changed and how IT managers can respond. > Discussions > >> will include endpoint security, mobile security and the latest in > malware > >> threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ > >> python-control-discuss mailing list > >> pyt...@li... > >> https://lists.sourceforge.net/lists/listinfo/python-control-discuss > > > > > > > ------------------------------------------------------------------------------ > > Want fast and easy access to all the code in your enterprise? Index and > > search up to 200,000 lines of code with a free copy of Black Duck > > Code Sight - the same software that powers the world's largest code > > search on Ohloh, the Black Duck Open Hub! Try it now. > > http://p.sf.net/sfu/bds > > _______________________________________________ > > python-control-discuss mailing list > > pyt...@li... > > https://lists.sourceforge.net/lists/listinfo/python-control-discuss > > > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > python-control-discuss mailing list > pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-control-discuss > |
|
From: Dale L. P. <haz...@gm...> - 2012-09-05 05:59:01
|
Has there been any discussion of moving from svn to git? git is very nice to work with, makes branching and merging seamless, and also works nicely with sites like github.com, which offers a wiki, pull-requests, lots of very nice online code review tools, and also has a clever way to hosted a project website. I've been involved with github.com for > 3 years and really like it. There are many high quality projects on github and a very good user community. If there is interest, I could help with moving from svn to git. I believe sourceforge offers git as an option now, so you could keep the same project page if you didn't want to switch to github. Here is a little link comparing svn with git: https://git.wiki.kernel.org/index.php/GitSvnComparison Luke On Tue, Sep 4, 2012 at 9:51 PM, Richard Murray <mu...@cd...> wrote: > You should have all gotten the message below about a new URL for the python-control source repository. The move occured because I upgraded to SourceForge 2.0, the new version of the software (based on the Allura platform). If you have a checkout of the old subversion repository, you should recheckout using the URL below. > > A couple of other updates: > > * SourceForge is going to be discontinued their hosted apps, which include the MediaWiki application that we are currently using. I'll be shifting the developer information off of that wiki onto the default SourceForge wiki. The one thing that won't transfer is the detailed VTOL example, since equations are not supported on the SF wiki. I've copied that information to my own wiki for now. > > * I'll be using python-control for our undergrad controls course at Caltech this fall, and will try to use that as a driver for updating various functions and adding in any missing capabilities. If you have requests for features you would like to see added, please send e-mail to this list or create a new feature request on the SourceForge page. > > -richard > > Begin forwarded message: > >> From: SourceForge.net <nor...@in...> >> Subject: SourceForge Repo Clone Complete >> Date: 2 September 2012 22:25:47 PDT >> To: no...@in... >> Reply-To: no...@in... >> >> Your cloned repository code in project python-control is now ready for use. >> >> Old repository url: http://python-control.svn.sourceforge.net/svnroot/python-control >> >> New repository checkout command: svn checkout --username=murrayrm svn+ssh://mur...@sv.../p/python-control/code/trunk python-control-code >> >> You and any other developers should do a fresh checkout using the new repository location. >> > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > python-control-discuss mailing list > pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-control-discuss -- “People call me a perfectionist, but I'm not. I'm a rightist. I do something until it's right, and then I move on to the next thing.” ― James Cameron |
|
From: Richard M. <mu...@cd...> - 2012-09-05 06:10:28
|
There hasn't been much conversation about this, but converting to git is probably the way to go in the long run (better functionality for distributed development). Sourceforge supports git and we can easily transfer projects from subversion to git: https://sourceforge.net/apps/trac/sourceforge/ticket/24534 I don't have much experience with github versus sourceforge in terms of the various features, and so don't have a strong preference beyond doing whatever works best for the people who are actively developing code for the library. -richard On 4 Sep 2012, at 22:58 , Dale Lukas Peterson <haz...@gm...> wrote: > Has there been any discussion of moving from svn to git? git is very > nice to work with, makes branching and merging seamless, and also > works nicely with sites like github.com, which offers a wiki, > pull-requests, lots of very nice online code review tools, and also > has a clever way to hosted a project website. I've been involved with > github.com for > 3 years and really like it. There are many high > quality projects on github and a very good user community. > > If there is interest, I could help with moving from svn to git. I > believe sourceforge offers git as an option now, so you could keep the > same project page if you didn't want to switch to github. > > Here is a little link comparing svn with git: > > https://git.wiki.kernel.org/index.php/GitSvnComparison > > Luke > > On Tue, Sep 4, 2012 at 9:51 PM, Richard Murray <mu...@cd...> wrote: >> You should have all gotten the message below about a new URL for the python-control source repository. The move occured because I upgraded to SourceForge 2.0, the new version of the software (based on the Allura platform). If you have a checkout of the old subversion repository, you should recheckout using the URL below. >> >> A couple of other updates: >> >> * SourceForge is going to be discontinued their hosted apps, which include the MediaWiki application that we are currently using. I'll be shifting the developer information off of that wiki onto the default SourceForge wiki. The one thing that won't transfer is the detailed VTOL example, since equations are not supported on the SF wiki. I've copied that information to my own wiki for now. >> >> * I'll be using python-control for our undergrad controls course at Caltech this fall, and will try to use that as a driver for updating various functions and adding in any missing capabilities. If you have requests for features you would like to see added, please send e-mail to this list or create a new feature request on the SourceForge page. >> >> -richard >> >> Begin forwarded message: >> >>> From: SourceForge.net <nor...@in...> >>> Subject: SourceForge Repo Clone Complete >>> Date: 2 September 2012 22:25:47 PDT >>> To: no...@in... >>> Reply-To: no...@in... >>> >>> Your cloned repository code in project python-control is now ready for use. >>> >>> Old repository url: http://python-control.svn.sourceforge.net/svnroot/python-control >>> >>> New repository checkout command: svn checkout --username=murrayrm svn+ssh://mur...@sv.../p/python-control/code/trunk python-control-code >>> >>> You and any other developers should do a fresh checkout using the new repository location. >>> >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> python-control-discuss mailing list >> pyt...@li... >> https://lists.sourceforge.net/lists/listinfo/python-control-discuss > > > > -- > “People call me a perfectionist, but I'm not. I'm a rightist. I do > something until it's right, and then I move on to the next thing.” > ― James Cameron > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > python-control-discuss mailing list > pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-control-discuss |
|
From: Dale L. P. <haz...@gm...> - 2012-09-05 06:27:58
|
> There hasn't been much conversation about this, but converting to git is probably the way to go in the long run (better functionality for distributed development). Sourceforge supports git and we can easily transfer projects from subversion to git: > > https://sourceforge.net/apps/trac/sourceforge/ticket/24534 I agree, git is definitely the way to go. > I don't have much experience with github versus sourceforge in terms of the various features, and so don't have a strong preference beyond doing whatever works best for the people who are actively developing code for the library. I haven't hosted a project with sourceforge, but I use github for all of my projects that I put online and it works really well and I have been very happy with it. I don't know of anybody who prefers sourceforge over github, though I can see why a well established project wouldn't switch since there are a lot of other things beside the source migration that are probably less trivial (forum, mailing list, etc.). I'll spend a few minutes and see how difficult it would be to convert from svn-sourceforge to git-github and report back. Luke |
|
From: Andrew S. <str...@as...> - 2012-09-05 08:31:29
|
On 09/05/2012 08:10 AM, Richard Murray wrote: > There hasn't been much conversation about this, but converting to git is probably the way to go in the long run (better functionality for distributed development). Sourceforge supports git and we can easily transfer projects from subversion to git: > > https://sourceforge.net/apps/trac/sourceforge/ticket/24534 > > I don't have much experience with github versus sourceforge in terms of the various features, and so don't have a strong preference beyond doing whatever works best for the people who are actively developing code for the library. As an example, when matplotlib switched from the code repository using svn + sourceforce to git + github, there was a dramatic increase in contributions. MPL continues to use sourceforge for the email lists. The issue tracking was later switched to github, despite some missing functionality, in order to have integration with the version control system (having "closed issue" messages linked to the commit that closed them). All that said, these data are from some time ago (2 years, approximately) -- since that time, sourceforge seems to have made some dramatic changes (adding git, revising their issue tracking system) and I cannot fairly compare sourceforge's current offerings. See https://github.com/matplotlib/matplotlib for the MPL github respository. So, my evidence is that your criterion of "whatever works best for the people who are actively developing code for the library" will be best served by moving to github because you'll gain new contributors. This was more-or-less the discussion we had in the matplotlib email list and, although I haven't quantified it, the evidence of new contributors is very clear. You'll also gain resonance with similar minds using similar tools and also possibly interested in python-control, thus increasing the likely number of high-quality contributions. Here are some projects that all use github as their primary repository as far as I know: * numpy https://github.com/numpy/numpy * IPython https://github.com/ipython/ipython * sympy https://github.com/sympy/sympy * scipy https://github.com/scipy/scipy * ROS https://github.com/ros As far as how to switch to github, I guess the easiest way, if SF offers a "convert this repository to git" button, is to press that button and then clone the SF repository to your local computer, create a github repository and then push your local repository onto github. (Then maybe delete the SF one or at least block writing to it.) -Andrew |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X