Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > We cannot continue to have this battle every time you create a new
| > patch.
|
| Right, trusting me a tiny more bit would help.
It is not about trust. It is about not doing too many changes at the
same time.
Actually, I do trust you, your code is good. But that is not really
the point though.
| > And from glancing over the patch there are several things that could
| > have been broken out into separate patches.
|
| Then I am stopping here because I am already investing too much time
| in LyX. Feel free to split up the patch as you will so that you can
| review it easily. But quite frankly I am sure that you *can* review
| the patch if you really want to.
...
| > | Beside, the svn log is not clear enough?
| > Not the point.
| > | > It must be possible to split this patch into more manageable
| > pieces.
| > | | Maybe but I really don't see the advantage and it will require
| > me to
| > | invest much more time working on this for nothing.
| > I surely see the advantage. Easier to review, easier to understand,
| > takes shorter time to review -> can actually result in faster
| > progress.
|
| I strongly disagree. I have seen many patches in the list that were
| much bigger than this one and didn't provoke the reaction my patches
| always provoke from you.
It is not the size of the patch that is the problem, it is that it
changes unrelated things that could have been in separate patches.
Then the individual chanes hat been easier to see.
You trust him, his code is good, the patch isn't overly large.
How about making the occational exception to your rules,
so lyx can progress forward, instead of stalling as developers quit?
I often see the complaint that there are few developers,
and therefore long time between releases.
Perhaps then, it is a good idea to get and keep more developers
by being less strict. Particularly with people who has proved
themselves with large contributions.
You can still _complain_ of course, but how about grudgingly
accepting a bit more?
There is also the "try it out" approach. Accept a big patch,
and if it turns out ok, fine. If it doesn't, the whole thing
can be reverted as a unit, and then the developer will be
forced to break it up more finely. People won't mind having to
do that occationally, but all the time is different.
Note it is not only about review, but also for other to understand
your changes. If too many changes are bundled together that becomes too
hard.
The principle is good, but "no developers - no changes at all."
| I know you are the principal architect of the
| LyX kernel but IMHO, you really should loose some control over the
| project.
Yeay! anarchy!
I don't think he meant anarchy. More like delegating some
decicion power to other long time developers.
| > | Please try to read
| > | the code instead. If you prefer a branch, we could do that also.
| > Same problem with that. Too many changes in the same patch or branch
| > is equally bad.
|
| Then, that's the end.
I really wish you had listened to me when I brought the samme issue up
ealier...
| PS: Lars, this is email so I probably should precise that there is no
| hard feeling at all in what I am saying. But I have to make a decision
| so I am officially retired now.
I am sorry to hear that...
You have been a fresh breeze on the list.
Indeed.
Helge Hafting
