- From: Michael Kay <mike@saxonica.com>
- Date: Tue, 10 May 2022 15:24:57 +0100
- To: Norm Tovey-Walsh <ndw@nwalsh.com>
- Cc: public-xslt-40@w3.org
Oh. When I generate new tests, I often want them to go into both, and I assumed that making it a fork would make that easier (I do occasionally synchronize, though I haven't done so for a while). Also, I assumed that if it ever happens that 4.0 gets official approval in some sense, then we will want a single converged test suite in which all tests are labelled with the version that they depend on. I certainly hadn't realised this would stop people having forks of both. Does this just mean GitHub forks of both? Does it just mean that the two forks need to be under different GitHub ownership? It seems a very odd restriction. Mike > On 10 May 2022, at 14:52, Norm Tovey-Walsh <ndw@nwalsh.com> wrote: > > Hi folks, > > I’ve just noticed that when the qt4cg/xslt40-test repository was > created, it was created as a fork of the w3c/xslt30-test repository. > > I think this was a mistake. I don’t believe there are any plans for the > 4.0 tests to be contributed back to the 3.0 repository, so making it a > fork serves no useful purpose. > > Also, because it’s a fork of the w3c/xslt30-test repository, anyone on > GitHub who already *has* a fork of the w3c/xslt30-test repository can’t > *also* have a fork of the qt4cg/xslt40-test repository. (I don’t know > why, and I don’t feel like fighting with the GitHub administrators about > it.) > > I propose to create a new repository, replay relevant history onto it, > and then swap the new one in for the old one. I’m tempted to literally > swap it in, but I’m afraid that might make anyone with a current clone > of the xslt40-test repository very cranky. > > The practical solution, I expect, is to create a new xslt40-test > repository with a new name (suggestions?) and then just remove the old > one. > > Comments, questions, or concerns? > > Be seeing you, > norm > > -- > Norman Tovey-Walsh <ndw@nwalsh.com> > https://nwalsh.com/ > >> The problem with ad hoc solutions is that they so often turn out to be >> odd hack solutions.--Michael Sperberg-McQueen
Received on Tuesday, 10 May 2022 14:25:12 UTC