[Qgis-developer] Re: dealing with "long" primary keys / tests

[Mayeul Kauffmann]

Hi,
Just a short remark , quoting one item of the "must needed list" posted
by Paolo C.  yesterday in the user list:
"automatic testing".

In agile programming, you write the tests before implementing new
features. Then you track the bugs at the source. Ideally, very few bugs
hit the beta-testers  (most remaining bugs are due to bugs in the
automated tests). The users test what they are good at: they do
usability tests only.

In the very short term, developing new features is more costly, though.
In the long term, everybody wins.

Hence I would slightly modify Paolo's list from:
- bigfixing
- bugfixing ;)
- automatic testing
- polishing
- infrastructure

into
- automatic testing
- bugfixing
- polishing
- infrastructure

(because if you test more, bugfixing becomes easier).

Just my 2 cents on things to keep in mind IMHO. Thanks all for the
wonderful work!!!
Mayeul

Le mardi 07 juin 2011 à 08:33 +0200, Andreas Neumann a écrit :
> Hi Jürgen,
> 
>  I think it is acceptable to apply this to trunk, even with the risk of 
>  breaking something major. At some point such bigger changes need to be 
>  tested. The current trunk is still young and far away from the release 
>  of version 1.8 or whatever the successor will be called.
> 
>  I'd be willing to test.
> 
>  +1 from me to try and apply the patch, given that it still works.
> 
>  Andreas
> 
>  On Mon, 6 Jun 2011 17:24:00 +0200, Jürgen E. Fischer wrote:
> > Hi Andreas,
> >
> > On Mon, 06. Jun 2011 at 16:21:34 +0200, Andreas Neumann wrote:
> >> If this patch still works I would vote for applying it to trunk. It 
> >> is
> >> sad that one cannot load data with long id integer primary keys. OSM 
> >> is
> >> certainly an important enough community or data source to justify 
> >> the
> >> application of this patch.
> >
> >> Or would it require a lot of additional work besides applying and
> >> reviewing the patch?
> >
> > That's the question.  IIRC the reason why I didn't apply the patch.
> > Currently
> > we don't have a feature id type so everything that is an int might
> > actually be
> > a feature id - that needs to by changed to 64bit.
> >
> > And that not only for variables and parameters, but also for signals
> > and slots.
> > The former case would be picked up by the compiler, but the latter
> > case won't.
> > So that needs quite an amount of testing.
> >
> > The patch is likely to not apply cleanly anymore, but even if it did 
> > - there
> > might be new signals that it doesn't apply to yet.
> >
> > So that probably means we'd apply it, break qgis here and there, test
> > and train
> > to file redmine issues, git some more experience and end up with a 
> > fixed qgis
> > that has support for 64bit keys.
> >
> > If that's ok, I'd revisit the issue.
> >
> >
> > Jürgen
> >
> > --
> > Jürgen E. Fischer         norBIT GmbH               Tel. 
> > +49-4931-918175-20
> > Dipl.-Inf. (FH)           Rheinstraße 13            Fax. 
> > +49-4931-918175-50
> > Software Engineer         D-26506 Norden               
> > http://www.norbit.de
>