[Qgis-developer] Rethinking the testing and release procedure of QGIS

[Tim Sutton]

Hi Marco

On Fri, Jul 8, 2011 at 5:10 PM, Marco Hugentobler
<marco.hugentobler at sourcepole.ch> wrote:
> Hi Tim
>
> I also like a mandatory workflow for branching, request for merge, integrate
> (and also the unit tests for new features). However, let's discuss the details
> here and let people from the developer team comment if they think to be able
> to work like this.

Good !

>If we achieve a clear consensus, we can write it down and
> then I can do the shouting, no problem.
>

Ok great.


> Because in svn times, we also had a branching / merging policy. But after some
> time, most devs  found it unpractical to develop new features in branches
> only. In the end nobody did it (which I still think is a pitty).
>
>> branch
>> write tests
>> work
>> request for merge
>> integrate
>
> For me, this workflow is fine in case of new features. For smaller changes or
> quick bugfixes, it seems unhandy to always write a unit test for it.
> Furthermore we would discourage people from generating small pull requests
> like that.
>

For me I would consider 'a repository other than the official QGIS
repo' to be a branch. So in the case that Joe decides to clone and
make a small fix in his master branch and issue a pull request, it
should be no problem, In my work pattern when I receive even a small
change that I want to test e.g. Nathans table spacing pull request, I
would add his repo as a remote, make a tracking branch against his
master or branch, and then compile and test. Then I merge it to my
local master and push it in to the main QGIS master. What I am trying
to say I guess is that this is really the natural workflow of Git (and
why we should encorage people to have their own fork). There is always
the GitHub automerge pull request for really trivial changes that
allow you to skip some of the above steps (though Sandro seemed to
think it was the spawn of all evil on IRC :-) ).

In general I agree with your comments - we need to be level headed
about what we write tests for and what we are reasonably able to test.
I don't think your comments  about complex interactions were well
understood by others in this discussion. Particulaly in the
application itelf, a user may go through a complex of steps in order
to cause a bug to take place (e.g. loading a peculiar data set and
then using it for interacting with another data set etc etc). These
things are not easy to write unit tests for, but ultimately many of
them boil down to robustness in the underlying libraries. So in order
to keep sane while we embrace the unit testing, I would suggest that
we need a two pronged approach:

- a methodical writing of tests library by library, starting with
core, gui then analysis
- ad hoc creation of tests for new features that make their way into QGIS

The former is where some funding would be useful to pay a developer
(or several) to sit down and write a simple test for each public
method in each class. Perhaps we can exclude accessors and mutators
from the test coverage.

The latter is where we petition industry who are making use of
contractors, our own developer team and third party contributors to
provide unit tests with new code that will be added to the official
repo.

Regards

Tim

> What do other developers think about it?
>
>
> Regards,
> Marco
>
>
>
>
>
>
>
> Am Donnerstag, 7. Juli 2011, 21.15:39 schrieb Tim Sutton:
>> Hi
>>
>> On Thu, Jul 7, 2011 at 4:24 PM, Paolo Cavallini <cavallini at faunalia.it>
> wrote:
>> > Il 07/07/2011 16:21, Martin Dobias ha scritto:
>> >> some kind of challenge :-) And maybe to have someone who will start
>> >> shouting when new functionality does not receive tests :-)
>> >
>> > right, this seems a crucial role: perhaps the release manager is the
>> > right person for this?
>> > all the best.
>>
>> I'm happy to do it, though as code manager it might make more sense
>> for  Marco to do it. We should get in the habit of
>>
>> fork
>> branch
>> work
>> write tests
>> request for merge
>> integrate
>>
>> or something along those lines. When merges are done and all tests are
>> passing in theory the code should be release ready...
>>
>> Regards
>>
>> Tim
>>
>> > --
>> > Paolo Cavallini: http://www.faunalia.it/pc
>> > _______________________________________________
>> > Qgis-developer mailing list
>> > Qgis-developer at lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> --
> Dr. Marco Hugentobler
> Sourcepole -  Linux & Open Source Solutions
> Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland
> marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
> Technical Advisor QGIS Project Steering Committee
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>



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