[Qgis-developer] Merging of incompatible changes

[Tim Sutton]

Hi All


Firstly my apologies for taking so long to join in to this thread (and
for top posting) - I haven't been able to come up for air since
leaving Essen. In terms of the release roadmap for 2.0 the following
items were discussed in the hackfest in Essen as being the key
features we would hold the release for:

1) Raster overhaul
2) WMTS Support
3) Atlas integration for composer
4) WCS Client support
5) Transactional WFS support for QGIS Server
6) SIP Bindings revision
7) Symbology overhaul (needs support for random colour assignment and
property change on multiselections)
8) Sextante
9) Threading (non blocker wait fro 3.0)
10) Labelling overhaul
11) Diagrams overhaul (and remove of old implementation)
12) Oracle support (non blocker for 2.0)
13) Web site and docs update
14) Universal usage of expression builder

We agreed that when these features are present we will roll out the
release, with the hope that that could take place early next year.
Come end of December I think we should take a look at the items listed
and if any are obviously not making headway we should remove them from
the blocker list or find out if there is a way to bring them to the
foreground. The list above was also not intended to be exclusive, so
if other developments are offered for incorporation they will be
considered and accepted / declined on their merits.


<release manager hat off>

* My opinion on whether or not to include Martin's work is that we
should include it as I prefer one large disruption (along with raster
and other API breaking changes) rather than that we have a succession
of them. As Martin pointed out we have maintained 1.0 compatibility
for around 4 years and it would be nice to have a stable API again for
the next few years.

* I also think we need to be pragmatic here - we have a window of
opportunity with Martins work that may not come around in the near
future again - if he gets busy with his job etc. we may land up back
in the situation we had with the last threading branch.

* Adding a max version identifier as has been suggested (with max 1.8
being assumed if min version <= 1.8 and max version not explicitly
given) seems like a pragmatic way to deal with marking plugins as
unsupported.

* One of the major limitations I and the many people that contact me
about QGIS experience is lack of performance. Just yesterday I got an
email from someone in Sudan trying to use QGIS to work with ~300 000
point records and it taking 4 hours to do some simple operations on
the dataset.  I know you can deal with large datasets more effectively
in e.g. PostGIS but this is beyond the skill level of many of the
users who naturally gravitate towards QGIS 'because it is easy' - I
think we tantalise people with an increasingly rich feature set and
then frustrate them with slow performance. Putting in threading (and
other performance boosting improvements) will help to improve this.

For these reasons I vote +1 for Martin to merge in his work.

<release manager hat off/>

A few other general thread responses (with my release manager hat back
on again):

- no bugfix releases for 1.8 are planned unless someone wants to
volunteer for the maintenance, release and packaging process we simply
don't have the manpower
- no 1.9 release - we have broken API already and following
http://semver.org/ this precludes us doing another release.
- release cadence - releasing yearly is probably unlikely developers
(and developer funders too) need to see their work rolled out into
public releases regularly. If you want a yearly cadence, simply pick
one release a year and hold off on deploying newer releases in that
year.
- managing expectations  - I think it is very important that we (the
docs and community team especially) really prepare good materials to
accompany the release explaining the implications of the release and
the path to follow to get their preferred tools working on 2.0
- as Code PSC representative, Marco H ultimately should be the one who
facilitates the decision as to whether Martins work can be merged,
>From a release point of view I would support its inclusion assuming
Marco is happy that it is stable and doesn't break QGIS in new and
mysterious ways.

A last 'dreaming of a nicer vector api' note for Martin: Since you are
adjusting the feature iterator API, wouldn't it also be nice to
support this:

for reading:

    while myProvider.nextFeature(myFeature):  # or equivalent in new api
        myGeometry = myFeature.geometry()
        myFooValue = myFeature['foo']
        .... do stuff .....

And for writing:

            myNewFeature = QgsFeature()
            myGeometry = QgsGeometry.fromWkt(myRectangle.asWktPolygon())
            myNewFeature.setGeometry(myGeometry)
            myNewFeature['foo'] = 'bar'
            myResult = myMemoryProvider.addFeatures(myFeatures)
            myMemoryLayer.commitChanges()

In otherwords, the AttributeMap is nice for feature introspection but
its heavy baggage when all you want to do is write or read features.


Regards

Tim


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