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 > _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
