[Failure] The Package Smoketest
Stephen J. Turnbull
stephen at xemacs.org
Sun Jul 20 17:04:00 EDT 2008
Mats Lidell writes:
> >>>>> Stephen wrote:
> Stephen> The reason for doing anything in a branch is to avoid
> Stephen> interrupting work on the mainline.
> Yes but what is interrupted is the smoketest and the ability to deliver
> a distribution.
> The smoketest problem might look bad but the reason for having the
> smoketest is to find problems early so they can get fixed.
Sure, but we already knew there was going to be a problem; large
merges like this always bring lots of problems. This isn't a
reflection on any individual developer, as I said. Emacs-devel is
currently having similar problems due to the GNUstep/ Cocoa merge
(which was also done by moving files from a separate workspace into
the mainline workspace); it broke the Windows build and caused several
regressions. The point is that doing it without the help of the
version control system makes it less controllable.
> If the smoketest would have been smarter it would have built each
> package separately and we would only have a red auctex build. Would
> that have been better and acceptable?
Better yes, but still not a good idea in my opinion. Look, Uwe got
the job less than half done and took off on a trip. If it had been
done on a branch, that wouldn't matter.
I don't understand the objection to putting this on a branch. If Uwe
had simply done
cvs-rw checkout -r auctex-1_48 -d auctex-11_84-import auctex
cvs-rw tag -b auctex-11_84-import
and done and committed the work there, at any time he could simply do
cvs-rw update -j auctex-1_48 -j auctex-11_84-import
cvs-rw commit -m "Merge AUCTeX 11.84 improvements into mainline."
and be done. There is no reason not to use CVS in this way, because
he controls the mainline, too.
And if he puts auctex-11_84-import in the list of packages to compile,
he can do a make world, too. The only thing that won't work right is
making individual packages because the mainline and branch auctex
packages will overwrite each other.
> The branch was never discussed before we thought the patch to
> XEmacs.rules was needed so we didn't consider using a branch for
> this reason.
Months ago I recommended to Uwe that he do the work on a branch. Any
experienced developer would recommend that, too.
More information about the XEmacs-Beta