Mats Lidell writes: You're assuming a workflow where all pushed versions are buildable/ testable. But that's not necessarily going to be the case, eg, in a "bug day" or "sprint" context (not that we've had any of those since the big party in 1998, but one can hope!) Or, before the smoke test, in packages I "owned" I often used the CVS repository to communicate between the several machines I worked on. There would often be intervals of hours, sometimes days, when one of those packages would not be in what I considered testable state. You can say "with the smoke test that's not a very good idea", and I'd agree. All I'm trying to do is document limitations of our current infrastructure and suggest good workflows to deal with them. I would like our workflow to produce consistent, expected results. Right now it doesn't, and this thread is the right place to try to figure out why not, and how to improve it. Sometimes that's going to involve developer adjustments, and we should make those explicit. My point is that this *is* a restriction on collaboration and we should say so. That gives potential contributors a chance to say "Hey that's a PITA!" and we can document good ways to accomplish their goals with a minimum of changes from what the contributors expect. "More is not just more, it's *different*." People don't like changes when they can be avoided, and I'd like to be prepared to help contributors develop workflows that are comfortable for them in the context of the overall XEmacs infrastructure. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta