> Some think that the quality of LyX is increased best by any combination > of code reviews, the fact that more than one person understand the code, > that changes are only done in small, incremental steps that are > well-documented and discussed before hand, and that everyone does works > in the same, disciplined way, slowly, but surely moving forward.
Agreed, but this is not necessarily the *slow* way in the long run. It is much easier to review a hot patch, than fixing a bug later. > Others think that is it better to be more pragmatic and get the job > done. To spend more time coding and testing and bug-fixing, rather than > discussing and reviewing. Discussion and review make the job done better. The problem with this approach is that there will be many bugs left behind. You may say that the developer of the feature can test his own patches but it is widely accepted that developers are *not* the best people for testing, *especially* for one's own feature. *Independent* testing and reviewing is the key for the quality of the code. > - Is it OK if someone disagrees with the rules you would like to have? I would judge on a case by case basis. For example, if I am lack of time or knowledge, I would trust Abdel on a small patch in his own domain. I will not trust anyone for a big branch merge. > - Does everybody have to agree on how to work together? No, but if I see a downward trend of lyx' quality, I will doubt if I am investing my time on the right project. If I can not make it better, I will quit. > - Can there be different set of rules for different people? Better not. > - Could code reviews be voluntary? We already have rules. We trust people to different degrees, such as reviewing every patch for newcomers, and trusting veterans on trivial patches. > - Should the rules be flexible or strict? Flexible, controlled by the project manager. > - Should LyX - and thus the rules - try to accommodate as many talented > developers as possible? Sure. > People get upset if they think that someone intentionally breaks the > rules. When you get this feeling, ask yourself: Could it be that the > other person does not believe in and share the rule you have? In that > case, is that person intentionally hurting you by breaking the rule? Or > is that person just following his own set of rules. Maybe, maybe not. > But before you judge the other person, judge the rule: Maybe the rule is > not flexible enough. I will be upset if my patch is accidentally reverted by someone else. I will be upset if lyx 1.6.0svn crashes every one minute, as the case with 1.5.0svn. > Everyone is entitled to their own opinion about rules. The more tolerant > each person is, the better everybody will get along. The more flexible > the rules are, the easier it is to work together. Not necessarily. > I believe José has very clearly demonstrated this with the very flexible > handling of development in the 1.5 cycle. 1.5.0svn may be better than 1.4.0svn, but as I have detailed in another email, the development control was a mess. I guess this is why Georg quited Cheers, Bo