[Qgis-developer] Branch status for merge and release timeline proposal

Marco Hugentobler marco.hugentobler at sourcepole.ch
Mon Mar 7 15:04:40 EST 2011


Hi Martin

> I thought I will do it the other way round: to create a new branch
> from trunk (e.g. threading_branch2) and merge the commits from
> threading_branch there. Looks easier to port those few dozens of
> commits rather than porting nearly 2000(!) commits from trunk back to
> the branch.

Agreed, this could be easier than the other way round.

> Btw. what functionality from threading branch is required by the globe
> plugin?

osgEarth requests a lot of tiles from the maprenderer and it is very easy to 
conflict with the rendering of the qgis canvas. So afaik the main feature it 
needs from the branch are the feature iterators in the providers.

Regards,
Marco



Am Montag, 7. März 2011, 16.26:19 schrieb Martin Dobias:
> Hi Marco
> 
> On Mon, Mar 7, 2011 at 4:11 PM, Marco Hugentobler
> 
> <marco.hugentobler at sourcepole.ch> wrote:
> > Hi
> > 
> >> An alternative option is that we just freeze our 'stable' releases at
> >> 1.6 (or maybe a last 1.7 release with no threading) and jump right on
> >> to doing 1.9.x releases in the run up to September. However I would
> >> rather put the things we are developing into mainstream releases since
> >> (I know some people hate this idea) our users are also our testers.
> > 
> > We already have a number of new features for 1.7 (hopefully including the
> > raster provider branch). So for me it would be ok to have 1.7 as the last
> > API compatible release and doing the threading branch merge just after
> > the branching for 1.7.
> 
> Agreed.
> 
> > Anyway, it would be good to merge the changes from trunk into the
> > threading branch already now. Like this, people who need e.g. the globe
> > plugin could work with the threading branch sources until 1.7 is
> > branched. Additionally, it is easier to test the threading branch in
> > productive work with all the fixes and new features from trunk.
> 
> I thought I will do it the other way round: to create a new branch
> from trunk (e.g. threading_branch2) and merge the commits from
> threading_branch there. Looks easier to port those few dozens of
> commits rather than porting nearly 2000(!) commits from trunk back to
> the branch.
> 
> Btw. what functionality from threading branch is required by the globe
> plugin?
> 
> Martin


-- 
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Churerstr. 22, CH-8808 Pfäffikon SZ, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee


More information about the Qgis-developer mailing list