>> <span style="line-height:19.7999992370605px">I agree with Paolo, and also see the value of Sandro's argument that</span><br style="line-height:19.7999992370605px"><span style="line-height:19.7999992370605px">developing such functionality in a branch get's much less</span><br style="line-height:19.7999992370605px"><span style="line-height:19.7999992370605px">testing/viewing and is very hard to merge back. Myself I only had a</span><br style="line-height:19.7999992370605px"><span style="line-height:19.7999992370605px">serious look at it when it was in master...</span><div><span style="line-height:19.7999992370605px"><br></span></div><div><span style="line-height:19.7999992370605px">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. </span></div><div><span style="line-height:19.7999992370605px"><br></span></div><div><span style="line-height:19.7999992370605px">Sometimes it is also about not having a feature until it is ready, some things just need to wait until they are ready.  </span></div><div><span style="line-height:19.7999992370605px"><br></span></div><div><span style="line-height:19.7999992370605px">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. </span></div><div><span style="line-height:19.7999992370605px"><br></span></div><div><span style="line-height:19.7999992370605px">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.</span></div><div><span style="line-height:19.7999992370605px"><br></span></div><div><span style="line-height:19.7999992370605px">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.  </span></div><div><span style="line-height:19.7999992370605px"><br></span></div><div><span style="line-height:19.7999992370605px">- Nathan</span></div><div><br></div><div><div class="gmail_quote">On Tue Dec 23 2014 at 8:10:18 PM Richard Duivenvoorde <<a href="mailto:rdmailings@duif.net">rdmailings@duif.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 23-12-14 08:06, Paolo Cavallini wrote:<br>
> Hi Nyall,<br>
><br>
> Il 22/12/2014 23:47, Nyall Dawson ha scritto:<br>
><br>
>> I disagree - while there may be an issue with the difficulty of getting<br>
>> wide testing of pull requests, the solution isn't to allow broken code<br>
>> into master.<br>
><br>
> You're right, we're big boys now, must behave. However:<br>
> * the code is in good shape, not broken; works smoothly in a variety of<br>
> situations<br>
> * it opens a whole set of new and exciting applications, e.g. live<br>
> tracking, drone monitoring, etc.<br>
> * there are unsupported functions, as pointed out<br>
> * if we remove it from master, it will soon become unmergeable, and will<br>
> probably get lost; it happened several times in the past that what we<br>
> left out of the door was never recovered.<br>
> Overall, I still believe keeping it, but letting conscious users<br>
> activate it when necessary, is a good compromise.<br>
> In the meantime, we can start raising funds to complete the set of<br>
> necessary features (I do not think it's a huge amount of work, once the<br>
> money is found we have time to implement these for 2.8).<br>
> All the best, and thanks for your thoughts.<br>
<br>
I agree with Paolo, and also see the value of Sandro's argument that<br>
developing such functionality in a branch get's much less<br>
testing/viewing and is very hard to merge back. Myself I only had a<br>
serious look at it when it was in master...<br>
<br>
So as long as we can hide it for normal users (even without tickbox, we<br>
can make a cli-option for it :-) ), AND nothing is broken I'm in favour<br>
of letting it in master.<br>
<br>
I think Sandro should hide the spinbox in the statusbar for now, and<br>
nay-sayers should now try to find bugs related to rotation work?<br>
<br>
There is a PSC-meeting on 2th januari, let's make the final decision there.<br>
<br>
Regards,<br>
<br>
Richard Duivenvoorde<br>
______________________________<u></u>_________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/qgis-<u></u>developer</a><br>
</blockquote></div></div>