This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Proposal for the transition timetable for the move to GIT


On Dec 26, 2019, "Eric S. Raymond" <esr@thyrsus.com> wrote:

> Alexandre Oliva <oliva@gnu.org>:
>> On Dec 25, 2019, "Eric S. Raymond" <esr@thyrsus.com> wrote:
>> 
>> > Reposurgeon has a reparent command.  If you have determined that a
>> > branch is detached or has an incorrect attachment point, patching the
>> > metadata of the root node to fix that is very easy.
>> 
>> Thanks, I see how that can enable a missed branch to be converted and
>> added incrementally to a converted repo even after it went live, at
>> least as long as there aren't subsequent merges from a converted branch
>> to the missed one.  I don't quite see how this helps if there are,
>> though.

> There's also a command for cutting parent links, ifvthat helps.

I don't see that it does (help).  Incremental conversion of a missed
branch should include the very same parent links that the conversion of
the entire repo would, just linking to the proper commits in the adopted
conversion.  git-svn can do that incrementally, after the fact; I'm not
sure whether either conversion tool we're contemplating does, but being
able to undertake such recovery seems like a desirable feature to me.

> repotool compare does that, and there's a production in the conversion
> makefile that applies it.

> As Joseph says in anotyer reply, he's already doing a lot of the 
> verifications you are suggesting.

>From what I read, he's doing verifications against SVN.  What I'm
suggesting, at this final stage, is for us to do verify one git
converted repo against the other.

Since both claim to be nearing readiness for adoption, I gather it's the
time for both to be comparing with each other (which should be far more
efficient than comparing with SVN) and attempting to narrow down on
differences and converge, so that the community can choose one repo or
another on the actual merits of the converted repositories (e.g. slight
policy differences in metadata conversion), rather than on allegations
by developers of either conversion tool about the reliability of the
tool used by the each other.

Maxim appears to be doing so and finding (easy-to-fix) problems in the
reposurgeon conversion; it would be nice for reposurgeon folks to
reciprocate and maybe even point out problems in the gcc-pretty
conversion, if they can find any, otherwise the allegations of
unsuitability of the tools would have to be taken on blind faith.

I wouldn't like the community to have to decide based on blind faith,
rather than hard data.  I'd much rather we had two great, maybe even
equivalent repos to choose from, possibly with a coin toss if they're
close enough, than pick one over the other on unsubstantiated faith.  It
appears to me that this final stage of collaboration and coopetition,
namely comparing the converted repos proposed for adoption and aiming at
convergence, is in the best interest of our community, even if seemingly
at odds with the promotion of either conversion tool.  I hope we can set
aside these slight conflicts of interest, and do what's best for the
community.

-- 
Alexandre Oliva, freedom fighter   he/him   https://FSFLA.org/blogs/lxo
Free Software Evangelist           Stallman was right, but he's left :(
GNU Toolchain Engineer    FSMatrix: It was he who freed the first of us
FSF & FSFLA board member                The Savior shall return (true);


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]