Re: git-cvsimport-3 and incremental imports

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Eric S. Raymond" <esr@xxxxxxxxxxx> writes:

> Jonathan Nieder <jrnieder@xxxxxxxxx>:
>> Junio proposed a transition strategy, but I don't think it's fair to
>> say he has chosen it without discussion or is imposing it on you.
>
> I have said everything I could about the bad effects of encouraging
> people to continue to use cvsps-2.x, it didn't budge Junio an
> inch, and I'm tired of fighting about it.  Quibbling about the 
> semantics of 'impose' will neither change these facts nor make
> me any less frustrated with the outcome.

I am not quite sure if I follow you.

The primary thing I am aiming for is to rob an excuse from people
and from their distros to block newer Git and cvsps3.  I've already
cited a few URLs where we can see cvsps3 is blocked with an excuse
"it does not work with Git yet".

If we ship new version of Git that only works with cvsps3, we will
end up giving an excuse "this version of Git no longer works with
cvsps2" for distro packagers whose cvsps distro maintainer is slower
than others to pick up cvsps3 for whatever reason.

You may care deeply about CVS conversion part of the system, but you
need to realize that majority of Git users do not care a whit about
cvsimport. I do not want to give those distros that ship stale cvsps
an excuse to pin their users at an old version of Git.

By shipping both cvsimport-2 and cvsimport-3, we will rob from these
distros the excuse to block shipping the version of Git that does
support cvsps3 output.  They can choose to update cvsps to 3.x and
disable cvsimport-2 altogether at the build time, or if their cvsps
distro maintainer is slow, they can ship both cvsimport-2 and -3 and
let the user install cvsps 3.x under their $HOME if they want.

If you want to abandon cvsps2 users, that is perfectly fine by me.
As long as cvsps3 and cvsimport-3 combo works, Git before this
series will have a _working_ cvsimport as far as I am concerned.

In other words, I am fine to add a paragraph at the top of the
Release Notes saying that

 (1) cvsps2 is no longer maintained;

 (2) using cvsps3 is the future direction for the users; and

 (3) if their distro is slow to adopt cvsps3, however, cvsimport can
     still be used with cvsps2, but bugs in it or cvsps2 are not
     expected to be fixed.

to nudge distros to adopt cvsps3.

> I will continue to do what I can to make cvsps-3.x and cvs-fast-export as
> bug-free as possible, given the innate perverseness of CVS.  They
> won't be perfect; they will be *better*.

Yes, that is what we want.
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]