[python-control-discuss] moving python-control to github

[Richard M. <mu...@cd...>]

Based on the feedback that I have received so far, I'd like to proceed with the transfer of the python-control source repository and issues tracking from SourceForge to Github.  There is a project already set up to handle this at

  https://github.com/python-control

I propose the following timeline to implement this:

* 4-6 Aug 2014 (Mon-Wed): add everyone with a github account who is a current developer for python-control to the developer list for the python-control project on Github.  The goal would be to complete this by Wed, so that we can use this information to preserve some of the commit logs by mapping contributions from SourceForge IDs to Github IDs.  

⇒ Requested action: if you are current python-control developer, please send me your github ID (creating one if needed).

* 6 Aug 2014 (Wed), ~8 am PDT: move sourceforge/python-control to read-only access, so that the repository is stable.  Any commits by current developers should be done before this date.

⇒ Requested action: if you have any code that you are developing that is not currently committed to the repository, please commit to either trunk or branches by 6 Aug 2014 (Wed) at 8 am PDT.  Everything that is in the subversion repository on SourceForge should be preserved as long as it is committed by that date and time.

* 6-8 Aug 2014 (Wed-Fri): move repository + issues over to Github, using the procedure outlined below (from Scott Livingston).  During this time, python-control will still be available for read-only checkout from SourceForge, but developers should wait until the weekend before checking out a git version for modifications.

* 9 Aug 2014 (Sat): python-control becomes available via Github for read access (anyone) and write access (developers). Mailing lists and release snapshots remain on SourceForge.  

* 9 Aug 2014 (Sat): create a new mailing list called python-control-developers for the list of people who are active developers and open up access to python-control-discuss so that anyone can post.  The developers list will get e-mail on commits and be used for other detailed discussions (like this one); the discussion list will be used for discussions of features, problems, etc with users of python control, as needed.  (Several people have requested being added to the discuss list for this purpose.)

* Later: remove repository and issues from SourceForge, leaving only the mailing lists and version snapshots.

Please let me know if you have any issues/conflicts with the proposed timeline.  We can always back up at just about any point if needed, but once people start developing on Github then we obviously can't go back to SourceForge or subversion without losing some work.

-richard

On 3 Aug 2014, at 11:02 , Scott C. Livingston <sli...@cd...> wrote:

> Below are instructions including links to further reading.
> 
> 1. backup everything
> 
> You should obtain a complete copy of the subversion repository (server
> side) using
> 
>   $ rsync -av svn.code.sf.net::p/python-control/code .
> 
> and all of the project site content by clicking the "Export" button from
> the Admin panel at
> 
>   https://sourceforge.net/p/python-control/admin/export
> 
> The latter is delivered as JSON (http://json.org) files and includes all
> bug reports, feature requests, etc.  You can test your copy of the
> repository by checking it out locally, e.g., from the directory where
> you ran rsync, try
> 
>   $ svn co file://`pwd`/code try-co
> 
> 
> 2. repository (abbreviated as "repo" below)
> 
> http://git-scm.com/book/en/Git-and-Other-Systems-Migrating-to-Git
> 
> The primary difficulties are:
> a. mapping usernames associated with svn commits to committers and
> authors in the git repo;
> b. converting branches in svn to branches in the git repo;
> c. converting tags in svn to tags in the git repo;
> d. moving properties to the git configuration files; e.g., svn:ignore
> properties should be changed into .gitignore files.
> 
> #b and #c are automated, though sometimes you must make manual
> corrections.  A method for achieving #a is described in the URL given
> above to S. Chacon's book "Pro Git".
> 
> As for the repo on SourceForge.net, I recommend that you freeze it for a
> while before deleting it.  By "freeze it" I mean change to read-only
> access, so that `svn checkout` would succeed but `svn commit` would fail.
> 
> 
> 3. issue trackers
> 
> There are scripts to automate transfer of bug reports, feature requests,
> and other "tickets" on SourceForge.net, but I prefer to do it manually
> because I can
> 
> a. replace SourceForge.net handles with GitHub.com handles (when the
> person has an account on both); and
> b. review all open issues.
> 
> All of the tickets on SourceForge can have file attachments, but issues
> on GitHub cannot have attachments.  However, I just skimmed several of
> the tickets for python-control and did not notice attachments.  If any
> are found, one solution is to open an issue and paste the file into the
> text of the issue.
> 
> 4. wiki
> 
> Both GitHub and SourceForge use Markdown syntax with extensions, so
> moving the wiki should be as easy as copy-and-paste and then modify
> special items, e.g., change [[download_button]] to
> [download](https://sourceforge.net/projects/python-control/files/latest/download).
...
> 5. Commit e-mails
> 
> If you still want repository commits to be echoed to the mailing list,
> then a "service" [1] will need to be added.  Based on my guess of the
> future name of the repository, try the direct link
> 
> https://github.com/python-control/python-control/settings/hooks/new?service=email
> 
> If that link fails, go to the repository page on GitHub, click the
> "Settings" button the right side, and then click "Webhooks & Services"
> on the left.  Click the "Add service" button and select "Email".