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. 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: 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
