[Qgis-developer] Re: Plans for the 1.7 Release
Hi 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. Regards Tim On Thu, Apr 28, 2011 at 9:23 AM, Tim Sutton li...@linfiniti.com 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 == -- 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 == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org
Re: [Qgis-developer] Re: Plans for the 1.7 Release
I think this is a good idea, and git will allow this so I'm thinking why not. Nathan On 28/04/2011, at 9:40 PM, Tim Sutton li...@linfiniti.com wrote: Hi 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. Regards Tim On Thu, Apr 28, 2011 at 9:23 AM, Tim Sutton li...@linfiniti.com 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 == -- 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 ==
Re: [Qgis-developer] Re: Plans for the 1.7 Release
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 li...@linfiniti.com 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
