Hi all, Am Donnerstag, 28. April 2011, um 13.40:46 schrieb Tim Sutton: > > I just wanted to add following an offlist conversation with Juergen > that self hosting the git repository on qgis.org is also an option and > then cloning it over to github. Feel free to discuss if you have a > preferred way of doing things.
Self-hosting has some advantages but needs quite some work done. I think, http (and https?) transport would be a must. I recently looked at http read-only support with Apache, but this would require a dist-upgrade of the machine. The current git infrastructure on qgis.org is not made for large-scale use (it was a side-project of the Redmine installation). Maybe the KDE infrastructure (http://community.kde.org/Sysadmin/GitKdeOrgManual) would be more appropriate. If somebody is willing to improve and maintain the git infrastructure, than it is certainly an option. I prefer github as the main repository for QGIS. The "fork me" functionality gives a great new way for contributions of people outside of the core team. Everybody can start a public topic branch and send pull requests. Currently, I would neither use the issue tracker nor the Wiki of github - but the repository viewer is great. Regards Pirmin > > On Thu, Apr 28, 2011 at 9:23 AM, Tim Sutton <[email protected]> wrote: > > Hi All > > > > I just wanted to recap a little for those who were not present at the > > hackfest our plans for the roll out of 1.7. This release will be a > > little more involved since we are going to simultaneously migrate to > > GIT and Redmine. Here is a little synopsis of what is going to be > > happening: > > > > Branching 1.7 > > > > - Translation period will come to an end on friday evening (29 April) > > after which we will create the release branch for 1.7 (actual > > branching will happen sometime on the 30th). > > - 1.7 will be the last public release of the 1.x series. > > - If developer effort supports it we will make 1.7.x bug fix releases > > in the interim until the 2.0 release > > - 1.9.x releases will be made but not widely announced and will break > > api compatibility and deprecate various features > > - 1.9.x and possible maintenance of 1.7.x releases will be done from GIT > > > > Svn -> Git Migration > > > > - Migration will take place immediately after branching for 1.7 > > release but before call for packaging and release announcements > > - We will revoke svn write access for all committers > > - We will git svn clone qgis into a git repository > > - We will prune out the various sub projects so that the QGIS git > > repository represents only the QGIS code base itself and not code > > examples and other things found under trunk. > > - We will create additional repositories for each of the other > > subdirectories in trunk. > > - We will push the clones into github.org/qgis which will then become > > the official repo > > - We will reinstate commit access for svn committers but to the git > > repo now instead. > > > > Trac -> Redmine Migration > > > > - Migration will take place immediately after branching for 1.7 > > release but before call for packaging and release announcements > > - We will ask OSGEO for a backup of our current trac instance, > > including uploaded resources etc. > > - We will redeploy that backup on qgis.org > > - We will install the trac git plugin > > - We will migrate the svn commit references to git commit hash references > > - We will run the trac -> redmine migration scripts to migrate the > > tickets - We will ask osgeo to make the old trac instance read only and > > put a redirector in place pointing to our redmine instance. > > > > Release > > > > - We will include in the release announcements a notice about the > > GIT/Redmine migration, with pointers to required urls, documentation > > etc. > > - We will issue a call for packaging against the release branch in git > > so that packaging related changes can be committed there directly > > > > Rollback Option > > > > Naturally making such a large change to our infrastructure involves > > some risk. For this reason, existing svn and trac infrastructure will > > not be removed for some time and will be simply made readonly at the > > time of switch over. If we encounter any major issues during the > > changeover process we will remove the readonly status of svn & trac, > > evaluate the issues and come up with solutions, and then repeat the > > process at a later date. Obviously this will be disruptive too and we > > will make our best effort to avoid such actions being required. > > > > Help & Discussion > > > > The decision to do the migration has already been take at the > > hackfest, but if anyone has implementation specific ideas or concerns > > lets hear them. Also if you are a GIT ninja or a Redmine black belt, > > and would like to make the migration happen smoothly, please let me > > know as I will appreciate any helping hands. > > > > > > Regards > > > > Tim > > > > > > -- > > Tim Sutton - QGIS Project Steering Committee Member (Release Manager) > > ============================================== > > Please do not email me off-list with technical > > support questions. Using the lists will gain > > more exposure for your issues and the knowledge > > surrounding your issue will be shared with all. > > > > Visit http://linfiniti.com to find out about: > > * QGIS programming and support services > > * Mapserver and PostGIS based hosting plans > > * FOSS Consulting Services > > Skype: timlinux > > Irc: timlinux on #qgis at freenode.net > > ============================================== -- Pirmin Kalberer Sourcepole - Linux & Open Source Solutions http://www.sourcepole.com _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
