On Sat, May 28, 2011 at 1:22 PM, Scott Moreau <[email protected]> wrote: > Sounds like you need to define who are all involved and what they're > expected roles are. It would be nice to have a constant review board but the > reality is sometimes the case where the board does not review in a timely > fashion and commits in cue become stagnant.
This is where the timeout limit comes in - people have a set number of days, eg 5 to review the code before it goes into master. The point is the help others see the development before it actually gets checked into trunk and to ensure that they are ok with the way the code is going so that we end up with better quality code. > Changing or mirroring repos > doesn't seem like it will help the situation though perhaps a staging area > could work. Yes, I agree. I'm suggesting github and launchpad in this case since they provide nicer interfaces to get this stuff done ;-) > The ml isn't an ideal place for this but it could work if > everyone involved are taking part and communicating effectively. The > situation as it is now is that everyone wants a bug fixed or feature added > but the lack of manpower and complexity of the project makes it difficult or > even impossible to do. Right, the point is to show people *how* bugs are fixed by getting them to review the fixes before they go into trunk. By doing this, then we can ensure that people are learning more about the way modules work so they can start working on them themselves. I'm not saying that we should keep patches or commits in limbo for absolutely everything until someone reviews them, I think that this behaviour is counter-productive. We can get people to submit patches by actually formalising a process to review and accept them. > It seems to me that instead of screening new commits > which would stifle progress, the matter on the table should be to define > known bugs that we want to fix and have everyone collaborate to work on > getting the major blockers out of the way from creating a stable release. Right, bug lists and milestones are a good idea for releases. I'm going to post about a proposed upstream rapid release / freeze / review system in a few hours :) Cheers, Sam > _______________________________________________ > dev mailing list > [email protected] > http://lists.compiz.org/mailman/listinfo/dev > > -- Sam Spilsbury _______________________________________________ dev mailing list [email protected] http://lists.compiz.org/mailman/listinfo/dev
