This is the mail archive of the gcc-patches@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: 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
person anyway.

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.)

- Brooks


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