On 10 May 2012 11:52, Iain Buclaw <ibuc...@ubuntu.com> wrote: > > Thanks, would it be best to split the frontend, library, and patches > to gcc proper into three parts?
>From observing how other big projects got merged, I think it is better: 1) If you have anything that can be committed independently of gdc (like bug-fixes, cleanups, etc.), send those first as individual self-contained patches. This will reduce the delta. This will also give you a sense of the stylistic changes reviewers are more likely to complain about and fix them in your branch before presenting it for approval. 2) Next, for changes to various parts of GCC that are not independent of GDC, isolate changes by subsystem (see MAINTAINERS), then either produce a patch or, if too large, point how to get a diff of exactly those parts in a branch. Send it to gcc-patches and CC the relevant maintainers. This includes also splitting out changes to the shared build machinery and to the shared testsuite infrastructure. 3) Finally, once all those parts are approved, you will have to convince one or various global reviewers to go through the rest of the branch (FE proper, runtime and testcases) and ACK it. The merge of Go could be a good example to follow: http://gcc.gnu.org/ml/gcc/2010-10/msg00342.html It was finally committed here, so it "only" took two months for someone who is one of the few top-class experts in GCC, with decades of experience, so be patient and persevere: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00274.html You should probably also read this: http://gcc.gnu.org/onlinedocs/gccint/Front-End.html Cheers, Manuel.
