[Qgis-developer] Merging the C_API branch

[Marco Hugentobler]

Frank,

I understand your points to some extent. There are things that didn't went 
well and can be improved.

Note the branching and merging is only for larger changes or changes that 
affect a lot of other code. If you do some changes in the raster part of QGIS 
and it is ok with Peter (as he is the raster maintainer), then no problem to 
commit it directly to svn.

Even though branching and merging may cause some inconvenience, I still think 
it is crucial to maintain basic code stability. In the case of the C-Api 
branch, testing revealed 4 bugs that would have been much harder to detect 
without branching. And this is a very low number, usually changes like this 
introduce more bugs.
I remember the times before the branching and merging process, and the 
stability problems then were also putting off some contributors and prevented 
a lot of users from using the software.

> > In my opinion, the "branch for changes then merge" process has increased
> > the stability of the qgis code considerably and also the release interval
> > is much better because of this process (was >1 year before).
>
> If it is the best strategy for the project, then by all means continue. 
> But be aware that the approach is off putting to at least some
> contributors.

I'm open to suggestions on how to improve development. QGIS is a democratic 
project and development practices can be discussed and adapted if a majority 
of developers are in favour of it.


Regards and thanks again for your work,
Marco



  

Am Freitag 14 März 2008 15:51:44 schrieb Frank Warmerdam:
> Marco Hugentobler wrote:
> > Hi Frank and Peter,
> >
> > Thanks for reminding me, I merged the gdal c-api changes to trunk now.
> > Please apologize the delay, I thought that Frank would merge the branch,
> > that's why I didn't do the merge earlier
> >
> > (from my mail Feb 26:
> > "So my suggestion is that you go ahead and merge the branch to
> > trunk if there is no objection on the devel list in the next two days")
>
> Marco,
>
> Well, first of all, any process that requires me to remember to do
> something two days later based on no one objecting has a 93% chance of my
> forgetting it forever.  Also, I imagine the part about me doing it didn't
> sink in - likely I skimmed the email to fast.
>
> >> I must say this "branch for changes then merge" process has not left me
> >> with warm and fuzzy feelings, and it is hard to imagine my taking it on
> >> again unless I am contributing to someone else's effort.
> >
> > Is the delay in merging the reason for the not warm and fuzzy feelings or
> > is it something different?
>
> It seemed like a great deal of overhead for a modest change.  It was a
> painful hassle for me to setup a new development tree and get it configured
> properly (please no volunteers to help with this).  Second it was painful
> for people to test the branch. It seems custom builds of the software had
> to be prepared and distributed for testing.  Third the merge seemed to drag
> on in an unclear sort of limbo for many weeks.
>
> I would add that I'm somewhat merge-phobic, and in other projects I try to
> use it only on very narrowly defined well understood changes.
>
> Some of these issues are just my backwards and grumpy nature.
>
> > In my opinion, the "branch for changes then merge" process has increased
> > the stability of the qgis code considerably and also the release interval
> > is much better because of this process (was >1 year before).
>
> If it is the best strategy for the project, then by all means continue. 
> But be aware that the approach is off putting to at least some
> contributors.
>
> Best regards,



-- 
Dr. Marco Hugentobler
Institute of Cartography
ETH Zurich
Technical Advisor QGIS Project Steering Committee