[Sugar-devel] RFC: Kill the delayed menus for good

[David Farning]

On Mon, Oct 12, 2009 at 9:40 PM, Bernie Innocenti <bernie at codewiz.org> wrote:
> El Mon, 12-10-2009 a las 22:36 -0400, Bernie Innocenti escribió:
>> Hello,
>>
>> Michael just passed by the Acetarium and, since the dinner was late, we
>> found the time to test and review his latest prototype^W patch.
>>
>> I'm loving how the menus suddenly are now snappy and responsive. Please,
>> test it yourself and report back. If we like this change, I think we
>> should go on and also kill the code that this patch makes redundant.
>> (please, let's not add another configurable knob!)
>
> BTW, Michael and I have a "small disagreement" on how a maintainer
> should react to the present patch. From a purely functional PoV, this
> patch is short, correct and low impact. Yeah, but... who's ever going to
> clean up after it if we do not demand the cleanup to be merged
> atomically with the patch that opens the need for it? Once the patch is
> in, the maintainer would no longer have a stick to brandish while saying
> "now eat your veggies!".
>
> (Michael replies: "This is a flawed position because it leads to absurd
> conclusions. More specifically, it actively discourages the current
> contributor from submitting more patches by denying the satisfaction of
> seeing their existing patch merged, delays the deferral of a correct and
> believable patch that introduces behavior you yourself describe as
> 'desirable' and, last but not least, misses an opportunity to involve
> inexperienced contributors by providing appropriate "on-ramp" bugs like
> the proposed refactoring.)
>
>  -- Bernie & Michael

The requirement for patches which are clean, correct, and adhere to SL
coding standards is orthogonalization to either sticks or carrots.
The requirement exists because code is expensive to maintain.  The
decision to accept code is up to the maintainer.

This is yet another example of the upstream-downstream tension.  In
this case, the developer wants "early and often" while the maintainer
wants "stable and seldom."  It is interesting to see how the
definitions of "early and often" and "stable and seldom" shift as we
move up and down the stream.

david