This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Proposal for the transition timetable for the move to GIT
On Mon, Dec 16, 2019 at 11:27:56AM -0500, Eric S. Raymond wrote:
> Joseph Myers <joseph@codesourcery.com>:
> > When we're talking about something to be used
> > for the next 20 years we should make sure to get it right.
>
> Segher and others should note that I'm not in the habit of sinking most of
> a year of my time into problems that I don't think are extremely
> important. This conversion *is* that important.
To you, whatever reposurgeon does that nothing else can, is important.
To many other people, not. Most people are totally pragmatic and want
to use a git-based workflow with GCC, and then soon upgrade some other
things in our workflow, to improve our day-to-day experience, and to
allow us to do things we couldn't do before.
Most people do not care about fixing the imperfections in the CVS->SVN
conversion. We have been using the SVN->Git mirror for over ten years
now, and it is perfectly workable. Now we want to finally finally
_FINALLY_ have an actual git repo that we can commit patches to
directly. Which we unanimously decided to do over three months ago.
> Nor, as far as I am aware, do the scripts have anything resembling
> reposurgeon's test suite.
So? Such a test suite does not magically prevent bugs (whatever type
it is: regressions, unit tests, whatever methodology).
The only thing that matters is acceptance testing (which includes such
trivial things ass "are all the files on trunk what they should be").
> Segher Boessenkool:
> > > If the reposurgeon conversion is not ready now, then it is too late
> > > to be selected.
>
> Maxim's conversion pipeline isn't ready either -- there are known
> bugs with its result.
Are there? The last I heard is that branches that do not share any
history with GCC are not in there. That's a feature, not a bug, imnsho.
If you know of any other bugs, detail them, don't make unfounded
statements please.
> Does that mean it's too late to select Maxim's
> conversion? If so, what do you propose be done?
Maxim's conversion was perfectly acceptable many months ago already.
> Please stop bellyaching and pitch in. Whether it's by fixing up
> Maxim's conversion, helping improve the reposurgeon one,
> or writing a conversion method of your own - I don't much care
> and it's not my job to tell you what to do, anyway. Any of those
> choices might be helpful; sniping from the sidelines is not.
Lol. Yeah, I won't answer that at all, I guess.
Segher