[Qgis-developer] Re: Plans for the 1.7 Release

Thu Apr 28 08:39:24 EDT 2011

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 <lists at 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
> > ==============================================

-- 
Pirmin Kalberer
Sourcepole  -  Linux & Open Source Solutions
http://www.sourcepole.com