[Qgis-developer] Ugly jumping maps while zooming

[Mathieu Pellerin]

To be fair to all, there should probably be an agreed upon understanding on
what would need fixing/implementing for the rotation feature to sticik
prior to 2.8, and if it can't be achieved by then revert the commits until
next dev cycle?

I can't be the judge of that, senior devs needed :)
On 23 Dec 2014 19:06, "Nathan Woodrow" <madmanwoo at gmail.com> wrote:

> >> 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
>>
>
> _______________________________________________
> 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/45386bf1/attachment.html>