From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Stump To: kenner@vlsi1.ultra.nyu.edu, rth@cygnus.com Cc: gcc@gcc.gnu.org, rms@gnu.org Subject: Re: Why not gnat Ada in gcc? Date: Wed, 01 Nov 2000 19:42:00 -0000 Message-id: <200011020341.TAA17065@kankakee.wrs.com> X-SW-Source: 2000-11/msg00075.html > Date: Wed, 1 Nov 00 21:13:30 EST > From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) > To: rth@cygnus.com > The argument really should be going the other direction. What > reason is so important that you *not* do development in the open? > The issue is the technical one of how to handle merges. My recommendation, finish off any internal work, stable and test your tree, label the bits in your tree (call this A), get those Ada bits into the FSF tree, get it to build, get it to test as well or near as well as before, update and repeat and then get those bits checked in at the FSF (call this B). That is stage one. After that is done, I'd recommend an import of all the FSF code into your tree, preferably the same one as you checked in. Now, the two trees are at parity. Next, maintenance. As work is done at the FSF you want, come up with B' to merge in, do diffs between B and B', merge them in using patch, update B to be B'. This is a logical unit and is separate from other work. The update interval is set by your for your business needs. At Cygnus, g++ ran around once a week, for the rest of the compiler, round once a month (if I recall right). As work is done in your tree, and as you want to expose the FSF tree to that work, you come up with A' (for example, right after a heavy round of successful testing), and then run the diffs between A and A', and check that into the FSF, and update A to be A'. This update interval can be set by what you have time to offer, if the FSF is breathing hard for some particular work you've done, and so on. Notice, I never once said where you `put' work when you develop patches. You can put them into the FSF tree, you can put them into your internal tree. You can decide on a per patch basis, you can change your mind. A master tree is a loose concept. To me, it is the one that has the fine grained cvs log messages approching one entry per changelog entry. Also, this technique scales well. It can handle being done once a minute (if you like fine grained updating), down to once a year or two, if you don't mind the pain that causes. I've used this method in production environments, at both ends of the spectrum. You alreay do exactly one half of this for the gcc backend already, so you should be familiar with it. The one trick is to apply the same process for the other half. I find that real live trees for A and B and A' and B' are best, easiest. One can then drop in local code into in A and the local tree, and it will forever stay local. For any other code, it will propagate automatically. Works great if you have unrestricted write access to the parts so merged. For me, it was the C++ frontend, and I had that. Anyway, I don't know what other issues other than just having a few minutes to do the work remain. If you don't see how something might work, or see problems in what I suggest, let me know, I'd be happy to to some mental work to get this thing off the ground.