[Qgis-developer] Ugly jumping maps while zooming

[Nathan Woodrow]

>> I agree with Paolo, and also see the value of Sandro's argument that
developing such functionality in a branch get's much less
testing/viewing and is very hard to merge back. Myself I only had a
serious look at it when it was in master...

Sometimes it's not about other people testing, sometimes it's about having
time for other developers to review the code, even just by eyeing it over,
before it is merged in.  Other people might be able to pick up things that
you might miss and save you the effort of bug fixing it later, or you might
be doing it completely wrong to start with.

Sometimes it is also about not having a feature until it is ready, some
things just need to wait until they are ready.

I also understand that sometimes things seem simple but lead to more issues
then you expect, we have all been there, however that is why we have
testing branches  It makes the user experience in QGIS a lot nicer.

I am in no way against the feature, it is a good one, in fact I have a use
for it in Roam, and I do not wish to undermine Sandro's efforts rotation is
a big task, however as it has the possibility of introducing regressions it
should be treated with care - also merging a feature in and then trying to
get more funding for bugs is IMO not a cool move.

If you write code that has small impact, import/export bookmarks for
example, I don't care if something like that is merged right in, small foot
print, small use case, easy fix, but for something that touches a major
core part of the code I think reviews should be done.

- Nathan

On Tue Dec 23 2014 at 8:10:18 PM Richard Duivenvoorde <rdmailings at duif.net>
wrote:

> On 23-12-14 08:06, Paolo Cavallini wrote:
> > Hi Nyall,
> >
> > Il 22/12/2014 23:47, Nyall Dawson ha scritto:
> >
> >> I disagree - while there may be an issue with the difficulty of getting
> >> wide testing of pull requests, the solution isn't to allow broken code
> >> into master.
> >
> > You're right, we're big boys now, must behave. However:
> > * the code is in good shape, not broken; works smoothly in a variety of
> > situations
> > * it opens a whole set of new and exciting applications, e.g. live
> > tracking, drone monitoring, etc.
> > * there are unsupported functions, as pointed out
> > * if we remove it from master, it will soon become unmergeable, and will
> > probably get lost; it happened several times in the past that what we
> > left out of the door was never recovered.
> > Overall, I still believe keeping it, but letting conscious users
> > activate it when necessary, is a good compromise.
> > In the meantime, we can start raising funds to complete the set of
> > necessary features (I do not think it's a huge amount of work, once the
> > money is found we have time to implement these for 2.8).
> > All the best, and thanks for your thoughts.
>
> I agree with Paolo, and also see the value of Sandro's argument that
> developing such functionality in a branch get's much less
> testing/viewing and is very hard to merge back. Myself I only had a
> serious look at it when it was in master...
>
> So as long as we can hide it for normal users (even without tickbox, we
> can make a cli-option for it :-) ), AND nothing is broken I'm in favour
> of letting it in master.
>
> I think Sandro should hide the spinbox in the statusbar for now, and
> nay-sayers should now try to find bugs related to rotation work?
>
> There is a PSC-meeting on 2th januari, let's make the final decision there.
>
> Regards,
>
> Richard Duivenvoorde
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20141223/1bc434ca/attachment-0001.html>