Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > Eric S. Raymond wrote: > >> You get to integrate this. I think the transition strategy Junio >> has chosen is seriously mistaken, leading to unnecessary grief for users >> who will be fooled into thinking it's OK to still use cvsps-2.x. > > So our choices are: > > a. support current users, offend ESR, don't benefit from ESR > improvements > > b. give up on current users, please ESR, benefit from ESR > improvements > > c. some option yet undiscovered > > In that case, (c) sounds like our best bet. Do I understand > correctly? > > Sigh, > Jonathan Isn't (c) is to just build on cvsimport-2 and cvsimport-3 combo? If Eric does not want to get involved in cvsimport-2 (and cvsps2), that is perfectly fine. We have the beginning of cvsimport-3 code that was released with Sign-off, and as long as cvsps3 produces a "more corrrect" output stream (either traditional cvsps2 style or as a fast-import stream) than cvsps2 conversion describes, cvsimport-3 can get the full benefit of his work, no? I do not think that Eric will be the only person who understands cvsps3 output who can fix bugs that may potentially still exist in cvsimport-3 code [*1*]. We live in real world, and distro inertia makes it likely that a new version of git that does not work for people who have been happy with cvsps2 will get resistance from them, when they do not trust the 0.x releases of a new piece of software "cvsps3" that happens to have a name similar to what they have been shipping, i.e. "cvsps2". Shipping such a crippled Git will not be an effective way to promote adoption of "cvsps3". [Footnote] *1* This of course assumes Eric's two major claims are true, that is, (1) cvsimport-3 is already mature and better than cvsimport-2, and (2) the code is so simple that it does not even need its own tests as long as the front-end conversion that happens at the cvsps3 end is tested well. Choosing b. will have to assume them to be true anyway, so I do not think it is a big loss to rely on the same assumptions and choose b. from our point of view. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html