[Qgis-developer] Pending PRs

[Hugo Mercier]

Hi Nyall,

On 07/10/2015 03:36, Nyall Dawson wrote:
> On 7 October 2015 at 03:01, Hugo Mercier <hugo.mercier at oslandia.com> wrote:

>>
>> But it becomes problematic when deadlines should be met, usually because
>> funders have to know with some confidence in which release a new feature
>> is going to be included.
>>
>> And I thought in this case if minor aspects (or even bugs) of a PR is
>> being discussed as the feature freeze is pronounced, the PR could be
>> merged provided fixes will be delivered asap (including during the freeze).
>>
>> #2189 had a bit more bugs than I initially thought (UI parts are not
>> always easy to test), but I don't think it has major design issues ...
>> and I am not sure other devs think it has (Nyall ? Martin ?). So I don't
>> understand why it's stuck.
> 
> My apologies for any delay I've caused in this PR - I've tried to
> respond as quickly as possible, but that's not always easy. It
> actually took a considerable amount of time to review/test this PR
> (and honestly, it didn't help that the initial implementation was
> quite buggy and confusing to test ;)
>

As I said, I agree this was not perfect the first time in terms of
design. Once fixed, you spent a considerable amount of time on testing
and that certainly helps.
But my point is I am not sure it is optimal, because everything depends
on you.
Once merged in the master, it would have allowed other people (including
the funder) to test it. This is the point of having a "development"
version (master) I think.

> I'd still be in favor of merging this PR for 2.12 (given the extensive
> testing given to the latest version), but that's Jürgen's call to
> make, not mine. As mentioned in the PR, it still should be looked over
> by Martin as I have no experience with the layer tree code and can't
> make a call on those changes.

Apart from Jürgen's call, as mentioned in the PR before the freeze, why
not merging it and fixing bugs that could eventually occur during the
bug fixing period (i.e. feature freeze) ?

Generally speaking, I think the commit right should allow to push new
things in the master with an "optimistic" view: if someone has to say
something against a commit, he will still have the opportunity to do so.
For this PR this is a pessimistic view: don't merge before extensive
tests and multiple peer agreements. It just does not scale, because
there is not enough available devs.