How to quallity control (was: Spatial selection Tools and Table Enhancements)

[Bernhard Reiter]

Hi Barry,

On Monday 02 October 2006 00:58, Barry Windridge wrote:
> > b) How to quality control.
> > In the earlier days we were working much more intensively on Thuban.
> > During this time we made it a ground rule to have all changes be double
> > checked, enhancements thoroughly discussed, tests
> > and documentation being written before committing to our repository.
> >
> > When intensity dropped this turned out to be not feasable, because
> > turnaround times were getting quite long. I believe it is more important
> > to take up good additions and have less quality control, but show some
> > progress even when there are bugs to attract more users and developers.
> >
> > What do you prefer?
> > If we try to be stricter, it will prove your code and Thuban in general,
> > but it also will take a lot longer and might be potentially frustrating
> > for you.
>
> I have no objections to them going out withoug full quality checking,
> however I don't think that they should go out without some checking!

I cannot say how much peer review we can organise.
If we say that a minimal peer review should be done, e.g.
you need at least one other Thuban developer to sign off your 
changes, it might delay takeup of contributions significantly.

Another self restriction would be to insist on doc-strings,
documentation and test cases before accepting a contribution
into a release. I believe that this might be bit too much to ask.

Next point of quality would to deeply discuss the design implications
of each change, but I believe this will be to much for our current workforce
to maintain.

> The spatial features I submitted last week were submitted for
> comment/checking - I don't think they are ready to go out yet. I am
> still lerning about Thuban and even if the code I have submitted,
> proves to have no obivious bugs (unlikely!), the code and user
> interface needs to be tidied up before it is released.
>
> Can you detail for me how you would see 'early release' working - what
> level of checking would code recieve?

We can put it in an experimental branch of Thuban and do snapshot releases
of it whenever somebody things we have reached a stage were more  
users could be interested.

We could make it a requirement to have at least one positive user report
from a beta tester before taking the change up in the stable mainline.

What do you think?
Bernhard

-- 
Managing Director - Owner, www.intevation.net       (Free Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution, Professional Service)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20061004/3e67878f/attachment.bin