This is the mail archive of the
mailing list for the GCC project.
Re: toplevel commits [was Re: Fix make -j4 installs]
DJ Delorie wrote:
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
As a question -- how does the approval process work with this? Is
maintainer status on either side generally considered sufficient to
approve a patch, and then it doesn't need additional review or testing
before being applied to the other side? Or is the person who commits
the synchronizing patch supposed to treat it as any other unreviewed
patch in need of review?
Also, I was going to ask if any of this was documented in the
gcc.gnu.org webpages anywhere, and was going to propose to add it to
http://gcc.gnu.org/codingconventions.html -- but then I noticed that
there's already a tiny hidden mention of it in the "Upstream Packages"
section. I think it really ought to be moved out of there into its own
section, since it's not really an "upstream" package; I propose to write
a patch to do that if it seems useful.
(For that matter, that bit of documentation really could be improved to
mention the fact that places like RedHat use a combined-tree build
process, rather than using the rather weak "we're doing this because
some people hope to eventually merge the repositories" justification.)