Ben Collins-Sussman wrote:
> * A lot of the reason people want the branch merged to trunk was to
> give it more attention and testing. Problem is, we can't test the
> feature without running trunk code on svn.collab.net (it requires
> new RA methods), and as a community we have a long-standing rule
> about only running released versions on our own server. So how do
> we deal with this? We've *got* to do "eat our own dogfood"
> testing before releasing it to the public, not just depend on unit
> tests.
We *always* do "eat our own dogfood" testing before releasing to the
public. We call them release candidates. They come with warnings about
possible unforeseen concerns, but they also come with reasonable levels
of confidence that, in fact, we aren't really going to break anything
badly if someone decides to run the RC.
I fail to see how the merge tracking feature is *any* different.
Real-world, adhoc testing should not be the first line of quality
assurance -- it should be the *last*, after well-written, automated unit
and functional tests. Besides, to truly test the merge tracking
feature "in real life", you need to exercise the breadth of real-world
branching and merging scenarios, perhaps in ways that are foreign to our
own development processes. And there's the rub -- I don't see our
repository as a playground.
If the folks doing merge tracking think the implementation is ready to
fly, put it into an RC and we'll upgrade svn.collab.net. Otherwise, I
vote against burdening the whole of the development process while they
work out the kinks, *especially* when we're talking about repository
data storage changes.
In the meantime, I wonder if there's somebody out there who could take
the continuous build concept one step further -- not just building trunk
constantly, but also installing the results on a running server, with a
dataset that gets wiped at regular intervals or somesuch, precisely for
this kind of adhoc testing.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Wed Dec 13 22:51:46 2006