Lars, all,
I would like to propose a way forward for new development. Just jump to
the conclusion if this mail seems too long to read :-)
Basically, I would like the decision process to be smoothed and based on
merit. There are some advantages of the one-patch/one-feature approach
but there also some drawbacks:
The pros:
- For projects with many dozens of developers and a lot of student among
them, the one-patch/one-feature approach is perhaps the only way to
proceed as you need to keep the whole in a stable state.
- With patch oriented review style, it is easier to review a patch that
does only one thing. We are talking here about deep review, here, not
only code sanity review.
The cons for LyX:
- We are at most a dozen developers, only 4 or 5 are active at the same
time.
- We are not students (except for Jose which is a bit late in his Ph.D.
;-)). I guess most of us have a day job and cannot afford to spend too
much time on LyX. So when one invests some time, he tries to do as much
as he can. Wasting time on patch procedure process is definitely not fun.
- I estimate that only 2 or 3 developers know at the same time a given
area of the source code. This doesn't facilitate patch review.
- The SVN log is here to explain what is in the commits. Reviewers that
don't know this particular code area just need to verify the C++
correctness and to some extent that what is in the patch corresponds to
what the SVN log says. For reviewers that know this code area, it should
be very easy to review the _contents_ of the patch, even if it does many
things at the same time. Of course some arguing could and should take
place if there is a disagreement.
- LyX is just GUI application, it is not rocket science. If some patch
is wrong, it will show sooner rather than later.
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. I came
to the conclusion that not many active developers knows this area of the
code... maybe it's only Lars and he probably forgot most of it. Lars is
arguing that the patch should have been split out to let others
understand the changes. Quite frankly, I don't see how "others" could
understand the changes when they don't know the code in the first place.
I am arguing that the one who knows the code would have no problem
reviewing the changes. In any case, one does not have to understand
everything.
Splitting my patch won't solve anything. I believe that we are all wise
enough to decide what's right and what's wrong when we do development.
When I am not sure of something, I ask. If I have no answer and have the
energy to understand the code by myself then I am appropriating the
code. But the resulting code is not mine, it belongs to the one who will
do some other work after me.
My last point, maybe the more important point is that, while I am
wishing all the best for the LyX project, I am not willing to develop if
it is not fun to do so. For me making the effort of splitting a patch by
using different trees and waiting for one patch to be accepted before
pushing another is simply too cumbersome. The simple truth is that I am
not willing to do the effort, it will remove all the fun of coding.
Conclusion:
I propose that the LyX community becomes more of a "meritocracy". Once a
developer has acquired enough trust from his fellow LyX developers, he
should be the one who decide what should go in. I am not saying that
discussion is forbidden but just that we should not be rigid about the
"rules". Responsible men do not need rules.
So, can I commit my patch? I have some others in the queue...
Abdel.
