hg diff --subrepos
Stephen J. Turnbull
stephen at xemacs.org
Sun Dec 25 22:04:21 EST 2011
Mats Lidell writes:
> >>>>> Stephen J Turnbull <stephen at xemacs.org> writes:
> > While this can't corrupt released packages, note that you may get
> > "unpublished" changes in the smoke test.
> That is IMO just what the smoketest is there for. Testing the latest
> released consistent version is not a big favor for developers nor the
> release manager.
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.
> > Probably most people are happy to push only testable commits.
> I hope so. With mercurial you are even better of than with CVS. You
> can commit your work without pushing until you are really done.
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.
> Anyway. This worked rather well with CVS so I think with Mercurial
> it should only be better.
"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.
More information about the XEmacs-Beta