Georg Baum a écrit :
Am Samstag, 8. April 2006 17:45 schrieb Bo Peng:
What I need from you, more experienced lyx developers, is a quick look
at the patch, find logic errors (like JMarc did for my auto-cls-layout
patch), design flaws (like the bundling of lastfile with lastpos), or
better implementations.
This is the real problem, not the branch. I would have had a look if I had
time. This won't improve with another branch.
On the other hand, what would improve is the visibility of this patch.
What would improve also is the visibility of the review process. With
better visibility, you get more developer interested and as a
consequence more developer with enough knowledge to review the patch.
And, last but not least, others can help improving the patch (reviewer
included).
The problem for you is to
get a timely feedback. The problem for those who could give the feedback
is that they either have hardly any free LyX time or are using this time
for fixing 1.4.x bugs. I don't see that this improves over the next
weeks, since new bugs are coming in at a fast rate.
If the patch *looks* fine, I will submit to
the trunk and let others have the chance to use and test it. Does this
sound OK to you?
IMO the following procedure would be OK:
That would be a nice improvement on the current process indeed.
Abdel.
If there is agreement about a particular feature, and also about the
general implementation (I don't mean the details, but the overall
approach), then a patch can go into trunk.
I made the assumption that
- you only commit changes that you think you have understood to 100%.
Otherwise ask and wait for feedback.
- you obey the general coding/formatting rules.
This would assure that trunk stays more or less in a usable state.
Mistakes can of course happen, but we would not need to rip out a
complete patch and start from scratch again.
Georg
