This is the mail archive of the 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: toplevel commits [was Re: Fix make -j4 installs]

> It is kinda hard when a lot of GCC developers don't have access to
> the src cvs and it is even harder to remember to ask someone to do
> it for you.

Yeah, it's not an ideal "solution", but neither side was willing to
cede control to the other (like libiberty, which is "owned" by gcc),
so it's technically infeasible to set up an automatic merge script.
I'm mostly concerned about patches that get applied without anyone
even realizing it needs to go to two places, because that is the most
difficult to merge later.  And no, my mail filters (electronic and
biological) don't always catch the toplevel commits ;-)

So, I have a cron job that watches the two toplevels and notifies me
(and a few other maintainers) when they're out of sync.  I ask the
committer if they can do the merge, or if they work for a company, can
a co-worker do it, else I usually end up doing it myself (or one of
the other maintainers).  If you're a port maintainer, who maintains
the binutils port for your chip?  That's usually a good person to ask,
and there's sometimes a need to coordinate toplevel changes with that
person anyway.

As for being hard to remember to ask someone, well, it's part of the
process like all the other little steps you have to remember.  Since
most people don't modify the toplevel, it doesn't come up often.

Of course, we could always choose to de-sync the toplevel, with the
understanding that NOBODY would be able to build a combined tree again
EVER (for example, this would screw Red Hat's internal builds, I don't
know about other companies), but I don't think I could agree to
maintain that.

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