Helge Hafting <[EMAIL PROTECTED]> writes:
| Lets not turn lyx management into a bureaucrazy where rules must be
| followed mostly for their own sake. You have good arguments
| for "one patch - one feature" in general, but please check
| that they really apply to _this_ particular case before rejecting.
And this whole case was about one patch that I found to not be ok.
One particular case before rejecting...
| > | Let me take my last patch as an example. This patch did two or three
| > | things but they were all related to the BufferView API cleanup.
| >
| > Except the thing that I really bitched about: emit->emitSignal.
| > That one change make the whole patch unpalatable to me.
|
| What I mean exactly. You already like the main part of this patch,
| the BufferView cleanup. Now you you're rejecting it because of a simple
| name change? A name change isn't very complicated to understand,
| even if it is "two" things in one patch.
No it is not a simple thing. It was a change to get around a macros
and code qt force on us. That is what makes the seemingly simple case of
changing emit to something else a bit more complicated and
controversial.
| There is something called compromise, such as accepting a patch
| while still pointing out the ways it could be done even better.
| Accepting a patch that bends the rules now and then makes people
| think they owe you a favor - perhaps they repay by making a
| better patch the next time.
And this is how we work all the time...
| > Our rules are more like guidelines anyhow (and what film is that quote
| > from?)
| >
| Don't know about films, but Terry Pratchett certainly writes stuff like
| that.
Paraphrasing really. Pirates of the Caribbean. The Pirate code.
--
Lgb
