The current work flow assumes that we do our OS/2 work on copies of official upstream branches. Each copy is started at some official release tag of the corresponding branch and then updates in that branch are periodically merged into our copy as the original project evolves. This is easier to explain with the picture:
I.e. our gcc-4_7-branch-os2 is a copy of the gcc-4_7-branch (that was started at the gcc-4_7_3-release tag), the gcc-4_9-branch-os2 is a copy of the gcc-4_9-branch (started at gcc-4_9_0-release). Since our changes are never pushed upstream, they have no chance to end up on master where new official branches originate from. This means that we must port our OS/2 changes to each new branch over and over again. On the picture above, this means that commits o1 and o2 are mostly duplicates of each other, incapsulating all OS/2 work plus a few patches specific to the given branch. Note that while this work is represented by a single commit on each branch (to simplify the graph), in reality it's a big number of separate commits. And as OS/2 development evolves, the number of commits we need to port to each new branch (e.g. to imaginary future gcc-4_10-branch and gcc-4_11-branch) will keep growing and will eventually make maintenance impossibly difficult and/or too error prone.
Instead, I suggest a different approach. We will create a special master branch for our OS/2 development, called master-os2. This branch will be started off from the original master branch to maintain proper ancestry and history information. The best place to start it is the next major release of gcc — or, more specifically, the place on master where a branch for the new major release will originate from (commit 8 on the picture). Then we will apply all our current OS/2 patches to master-os2 (commit o3) and do all further development on it as well. When it's time for a release, we will start an OS/2 specific branch (gcc-4_10-branch-os2) at our master-os2 branch and not at the original branch as we do now. Then we will merge any changes from the original branch we want in our release (this will most likely be an official release tag, like gcc-4_10_0-release, marked with commit 9 on the picture) with our OS/2 specific branch (commit o4) and here we are.
Then we will continue our future OS/2 work on our OS/2 master branch (not shown on the picture) back-porting it to branches we still support when necessary (not shown), as well as do some fixes right on the branches back-porting them back to our master when necessary (not shown).
When it's time to do a new major release, we will merge master changes to master-os2— again, at the point where the new major release branch starts off (commit 10 on the picture) which will result in commit o5 where the new OS/2-specific branch for that major release will originate from. Then we will merge changes from the original branch at the point of an official release we want to do (using the release tag, commit 11) to some release to our OS/2 branch (commit o6) and we are done again. And so on.
This new work flow will give us one significant benefit: all OS/2 patches (except a few very branch specific ones) will be done only ONCE, on master-os2, where they will be inherited by all our OS/2 branches in the future — w/o the need to port them again and again to each new branch. This will both significantly decrease the amount of work needed for each new release and make history much cleaner allowing to track history of OS/2 changes and their evolvement over time.
This issue is to discuss the suggested work flow and to track its implementation. Comments are welcome.
The current work flow assumes that we do our OS/2 work on copies of official upstream branches. Each copy is started at some official release tag of the corresponding branch and then updates in that branch are periodically merged into our copy as the original project evolves. This is easier to explain with the picture:
I.e. our
gcc-4_7-branch-os2is a copy of thegcc-4_7-branch(that was started at thegcc-4_7_3-releasetag), thegcc-4_9-branch-os2is a copy of thegcc-4_9-branch(started atgcc-4_9_0-release). Since our changes are never pushed upstream, they have no chance to end up onmasterwhere new official branches originate from. This means that we must port our OS/2 changes to each new branch over and over again. On the picture above, this means that commits o1 and o2 are mostly duplicates of each other, incapsulating all OS/2 work plus a few patches specific to the given branch. Note that while this work is represented by a single commit on each branch (to simplify the graph), in reality it's a big number of separate commits. And as OS/2 development evolves, the number of commits we need to port to each new branch (e.g. to imaginary futuregcc-4_10-branchandgcc-4_11-branch) will keep growing and will eventually make maintenance impossibly difficult and/or too error prone.Instead, I suggest a different approach. We will create a special master branch for our OS/2 development, called
master-os2. This branch will be started off from the originalmasterbranch to maintain proper ancestry and history information. The best place to start it is the next major release of gcc — or, more specifically, the place onmasterwhere a branch for the new major release will originate from (commit 8 on the picture). Then we will apply all our current OS/2 patches tomaster-os2(commit o3) and do all further development on it as well. When it's time for a release, we will start an OS/2 specific branch (gcc-4_10-branch-os2) at ourmaster-os2branch and not at the original branch as we do now. Then we will merge any changes from the original branch we want in our release (this will most likely be an official release tag, likegcc-4_10_0-release, marked with commit 9 on the picture) with our OS/2 specific branch (commit o4) and here we are.Then we will continue our future OS/2 work on our OS/2 master branch (not shown on the picture) back-porting it to branches we still support when necessary (not shown), as well as do some fixes right on the branches back-porting them back to our master when necessary (not shown).
When it's time to do a new major release, we will merge
masterchanges tomaster-os2— again, at the point where the new major release branch starts off (commit 10 on the picture) which will result in commit o5 where the new OS/2-specific branch for that major release will originate from. Then we will merge changes from the original branch at the point of an official release we want to do (using the release tag, commit 11) to some release to our OS/2 branch (commit o6) and we are done again. And so on.This new work flow will give us one significant benefit: all OS/2 patches (except a few very branch specific ones) will be done only ONCE, on
master-os2, where they will be inherited by all our OS/2 branches in the future — w/o the need to port them again and again to each new branch. This will both significantly decrease the amount of work needed for each new release and make history much cleaner allowing to track history of OS/2 changes and their evolvement over time.This issue is to discuss the suggested work flow and to track its implementation. Comments are welcome.