Re: [PATCH 0/4] jk/version-string and google code
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 10, 2012, 22:36 UTC
- Message-ID
- <7vy5lmgyra.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <CAJo=hJsaQyBEjH8uWHqnR9Sk9HwFqCwe81HRN3HxUi2j76YNAg@mail.gmail.com>
Shawn Pearce <spearce@spearce.org> writes:
Show 22 quoted lines
> On Fri, Aug 10, 2012 at 2:50 PM, Jeff King <peff@peff.net> wrote: >> On Fri, Aug 10, 2012 at 11:52:28AM -0700, Junio C Hamano wrote: >> >>> When evaluating a change in the interoperability area, it does not >>> add much more confidence to the correctness that the change has been >>> in use for months with the same partner than that it has been used >>> to talk to many different partners even for a short period of time, >>> I guess. >> >> Traditionally our interoperability testing has been to cook things in >> "next" and "master" and see if anybody complains. It would be nice to >> have an interoperability test suite that could hit some common hosting >> sites, as well as older versions of git-core itself. I suspect >> automating that would be a big pain, though. > > I don't know that you need to hit the hosting sites themselves, just > the implementations they are using. Dulwich and JGit are both open > source. It should be possible to build a smallish compatibility test > suite that grabs everyone into one tree, compiles a small test server > from each, and runs the matrix locally. Then its up to the hosting > sites to worry about making sure their implementations are included in > this suite, and up-to-date. :-)
Yeah, and do that for all the major versions of these implementations.