From: Hans U. N. <gp...@n-...> - 2013-09-13 22:49:11
|
Hi, the two services which triggered the need to move away from SF.net right now are related to the source code: * SVN source code repository To be replaced by git repos on http://github.com/gphoto/ This requires all current committers to get themselves a github account and then one of us admins to enter those github accounts into the list of people allowed to commit to the repo. Stupid me forgot to ask the current committers for the names of their github accounts in the last mail, so I guess that will be an extra round of Q&A by mail. I'm working on the SVN->git conversion right now. * Release tarball hosting Reconstructing the partially untagged releases of the past few years will take a bit of work, but should be feasible with `git bisect`. This can easily be done after switching over to using github. However, we are using more services on SF.net, and I have taken a look around on SF.net to find out which services should or could be migrated elsewhere. * Web hosting for http://gphoto.org/ Contains a lot of content. Could probably be moved to github pages, as it does not contain real dynamic elements in PHP. Or does it? Could also be changed to jekyll-bootstrap or something similar for a more 21st century layout, but that is a lot more work than just putting the existing HTML files into a git repo. * "Wiki" Apparently contains only a list of the maintainers, i.e it could be scrapped without any loss. * "Mediawiki" Contains about three pages of content on file formats, but that does not appear to be very much to migrate to any of e.g. the github Wikis. * Ticket trackers: * Feature requests * Patches * Bugs * Support Requests After moving the source code over to github, using github's issue tracker for bugs and feature requests is the obvious choice. For Patches, github's issue tracker and pull requests should do the job in a much improved way. As to Support Requests... to be determined. github issue tracker? * Mailing Lists @lists.sourceforge.net Notification from the ticket trackers: * gphoto-bugs * gphoto-features * gphoto-patches Notifications from the source code repository: * gphoto-cvs Communication among developers and users: * gphoto-devel * gphoto-user Updates for translation files: * gphoto-translation The notification mails for bugs, features and patches probably are obsolete when using the github features instead of SF.net tickets. The commit notification ML could be fed from github, or replaced by the github feature to "watch" the github repos you are interested in. The gphoto-devel and gphoto-user mailing lists should be kept around. As they carry no manipulation critical function like a code repo, we could keep them hosted at SF.net. Alternatively, we could find a service somewhere to host them and change their mail addresses to <*@gphoto.org>. A similar argument is to be made for gphoto-translation. Two issues to solve in case of moving the mailing lists elsewhere: * Can we move the list archives as well? * Are there issues with taking over subscriber lists to the new host? * Can there be (temporary) mail redirections? * Anything I have overlooked: What? My personal preference for keeping stuff and moving stuff for the next few weeks would be: * github git code repos for the source code * Host http://gphoto.org/ on github pages * github issue tracker * github wikis * phase out gphoto-{bugs,features,patches} as we phase out the SF.net ticket system * keep gphoto-devel and gphoto-user MLs on SF.net (using these does not require an SF.net account) * keep gphoto-translation ML on SF.net (using these does not require an SF.net account) This would mean that all developers only need a github account for working on gphoto (no SF.net account). Only project and mailing list admins need access to SF.net. Uli |
From: Marcus M. <ma...@je...> - 2013-10-04 20:19:28
|
On Sat, Sep 14, 2013 at 12:49:01AM +0200, Hans Ulrich Niedermann wrote: > Hi, > > the two services which triggered the need to move away from SF.net right > now are related to the source code: > > * SVN source code repository > > To be replaced by git repos on http://github.com/gphoto/ > > This requires all current committers to get themselves > a github account and then one of us admins to enter those > github accounts into the list of people allowed to commit > to the repo. > > Stupid me forgot to ask the current committers for the names > of their github accounts in the last mail, so I guess that > will be an extra round of Q&A by mail. > > I'm working on the SVN->git conversion right now. > * Release tarball hosting > > Reconstructing the partially untagged releases of the past > few years will take a bit of work, but should be feasible > with `git bisect`. I did not try to understand svn tagging ;) Should not be hard actually ... git log NEWS or git log configure.ac to get the commit ids, I have used these as make dist checkpoints. Can the tarballs be gpg signed too somehow with github? > This can easily be done after switching over to using github. yes. > However, we are using more services on SF.net, and I have taken a look > around on SF.net to find out which services should or could be migrated > elsewhere. > > * Web hosting for http://gphoto.org/ > Contains a lot of content. Could probably be moved to > github pages, as it does not contain real dynamic elements > in PHP. Or does it? > Could also be changed to jekyll-bootstrap or something similar > for a more 21st century layout, but that is a lot more work > than just putting the existing HTML files into a git repo. There is nothing really dynamic I think, while I did not write the pages I think php was used for a bit of templating. Yes, something low maintenance please ;) > * "Wiki" > Apparently contains only a list of the maintainers, i.e it could > be scrapped without any loss. > > * "Mediawiki" > Contains about three pages of content on file formats, > but that does not appear to be very much to migrate to any of > e.g. the github Wikis. Yes, they were transient. With the webpages hosted in git its also easier to make them more easy modifyable without having an actual wiki. > * Ticket trackers: > > * Feature requests > * Patches > * Bugs > * Support Requests > > After moving the source code over to github, using github's > issue tracker for bugs and feature requests is the obvious choice. > > For Patches, github's issue tracker and pull requests should > do the job in a much improved way. > > As to Support Requests... to be determined. github issue tracker? I have not yet looked at githubs trackers ... but lets try to use them. The old ones I would suggest to stay at sourceforge. > * Mailing Lists @lists.sourceforge.net > > Notification from the ticket trackers: > > * gphoto-bugs > * gphoto-features > * gphoto-patches > > Notifications from the source code repository: > > * gphoto-cvs > > Communication among developers and users: > * gphoto-devel > * gphoto-user > > Updates for translation files: > * gphoto-translation > > The notification mails for bugs, features and patches probably > are obsolete when using the github features instead of SF.net > tickets. Yes. > The commit notification ML could be fed from github, or replaced > by the github feature to "watch" the github repos you are > interested in. Yes. > The gphoto-devel and gphoto-user mailing lists should be kept > around. As they carry no manipulation critical function like > a code repo, we could keep them hosted at SF.net. Alternatively, > we could find a service somewhere to host them and change their > mail addresses to <*@gphoto.org>. > > A similar argument is to be made for gphoto-translation. > > Two issues to solve in case of moving the mailing lists > elsewhere: > > * Can we move the list archives as well? > > * Are there issues with taking over subscriber lists > to the new host? > > * Can there be (temporary) mail redirections? > * Anything I have overlooked: What? Can't think of more stuff. > My personal preference for keeping stuff and moving stuff for the next > few weeks would be: > > * github git code repos for the source code > > * Host http://gphoto.org/ on github pages > > * github issue tracker > > * github wikis > > * phase out gphoto-{bugs,features,patches} as we phase out > the SF.net ticket system > > * keep gphoto-devel and gphoto-user MLs on SF.net > (using these does not require an SF.net account) > > * keep gphoto-translation ML on SF.net > (using these does not require an SF.net account) > > This would mean that all developers only need a github account for > working on gphoto (no SF.net account). Only project and mailing list > admins need access to SF.net. Looks good to me. Ciao, Marcus |
From: Hans U. N. <hu...@n-...> - 2013-10-08 07:44:35
|
On 04/10/13 22:19, Marcus Meissner wrote: > On Sat, Sep 14, 2013 at 12:49:01AM +0200, Hans Ulrich Niedermann wrote: >> * Web hosting for http://gphoto.org/ >> Contains a lot of content. Could probably be moved to >> github pages, as it does not contain real dynamic elements >> in PHP. Or does it? >> Could also be changed to jekyll-bootstrap or something similar >> for a more 21st century layout, but that is a lot more work >> than just putting the existing HTML files into a git repo. > > There is nothing really dynamic I think, while I did not write the pages > I think php was used for a bit of templating. I have migrated that PHP templating to Jekyll/Github based templating. You can see the result at http://gphoto.github.io/ which we can make into http://gphoto.org/ when it is ready to take over and when we can change the DNS record. There are just a few things left to do where the PHP code actually does more than just templating, such as when the PHP code fetches the list of releases from SF.net and makes said list into an HTML page. Also I am keeping the migration status current at http://gphoto.github.io/migration-status/ and a build status at http://gphoto.github.io/dev/ > Yes, something low maintenance please ;) Just use http://github.com/gphoto/gphoto.github.io and try whether it works for you. I do like writing things in markdown instead of HTML. I think it is relatively low maintenance: git clone, change file, git commit, git push, and the website contains the update. And for simple things, you can just edit the file on github's web interface. I'll reply about the non-website topics later. Uli |