rahn at kde.org
Mon Mar 30 15:40:14 CEST 2009
On Monday 30 March 2009 14:11:44 Jens-Michael Hoffmann wrote:
> This was a lot of code which was merged apparently without any kind of
> review. I think this was not a good idea.
the branch had been there way too long already and it started to suffer from
the symptoms of eternal branches.
Especially now that we have a stream of heavy changes at the pre-alpha stage I
see little chance to stay up to date for a branch which has changes all over
the library due to changes in the handling of a classes such as
So I'm in favour of a remerge that happens ASAP to avoid that Patrick has got
to fight an exhausting battle "until everything fits".
> well, at this point I gave up.
Many of the warning you had commented on appear multiple times. So it should
hopefully be easy to fix.
According to what Patrick and me had discussed there are some further bigger
issues that need to get addressed:
- Currently the placemarks that are displayed don't get displayed properly as
the model is not sorted by popularity anymore. The fix that is needed is a (to
be created) SortProxyModel that is placed on top of MarblePlacemarkModel --
this should take about 1-3h at max. to fix.
- loading the placemarks into the model at startup takes 3x as much as before
the merge. This needs to get investigated.
- The GeoDataPlugin slows down everything as long as it's enabled.
- Possibly run-time performance regressions.
> I'd like to suggest to do the following:
> - revert this merge
> - fix the issues described above
> - post resulting changes for review
> - merge once all issues arising from review have been addressed.
I think that this would cost several weeks if we did it like that as Patrick
would need to keep up with a stream of changes that basically leave him no
time for actual development while trying to keep things up to date. This has
already been the case during the last few days and I don't think that this
If we continue to fix the remaining issues now, we can finish the whole thing off
within a few days. And Patrick can focus on actual work again (instead of
trying to catch up with latest changes all the time).
On the other hand the geodata-ng branch contains some important changes that
affect our fundament ( in the geodata-ng branch we pass GeoDataCoordinates by
value to avoid that you have to worry about ownership all the time when
working with them. And we have the GeoData value classes implicitely shared to
avoid costly copying).
So yes, if the changes in the branch were smaller and more focused on a
certain part of Marble I'd agree with you, Jens-Michael. But I think that the
situation is more complicated ... :-/
What do you think?
> Best Regards
> > So if you come across a new one, just try to fix it, they might be
> > really easy.
> > You can safely commit to marble-trunk again now.
> > regards,
> > Patrick
> Marble-devel mailing list
> Marble-devel at kde.org
More information about the Marble-devel