On 8/2/13 15:04 , John Morris wrote: > After Saturday's IRC meeting, seb_kuzminsky, cradek, jmk-mcfaul, > mhaberler and I (zultron) discussed on #linuxcnc-devel how to > prepare the Unified Build/RTOS branch for eventual integration into > mainline. [1] > > I was elated leaving Wichita after our initial breakthrough discussions, > when for the first time we established basic understanding that the > UB/RTOS code would be mainlined, perhaps in time for a 2.6 release. > Saturday's IRC discussion was another big step forward, resulting in > specific agreements about how the UB/RTOS branch should be prepared. > > With that discussion in mind, I have spent the last four days immersed > in rebasing the 1200+ commits and 80+ merges of an extremely complex > commit graph. [2]
Awesome, thanks Zultron. I quickly spot-checked a couple of places and it does indeed look much cleaner in several ways, thanks for that. > The last big question remaining from the discussion is how to get a > handle on the complexity of the changes so that the code can be reviewed. > > It was strongly suggested we rewrite the git history to separate the > dozen or so features for independent review. That is good practice for > localized feature branches or fixes. However, UB/RTOS is a major change > representing multiple man-years of effort where src/rtapi grew from 6700 > to 16600 SLOC. > > The mainline project itself handles major changes, such as the > difference between v2.5_branch and master, with roll-forward merges, and > the UB/RTOS has tracked mainline in the same way. These merges are a > big factor in the complexity of the commit graph and made this 'simple' > rebase extremely painful. > > Suggesting we rewrite history to separate distinct features is far, far > more ambitious. Each of the dozen features, individually, would require > identifying related commits, massaging them to apply cleanly, more fixes > to build cleanly, and then testing and debugging the result to be ready > for review. The question of how to handle the periodic merges with > mainline is an additional unknown. That amounts to a major refactor, > and to seriously expect us to do that is unrealistic and unfair. What you did (going from ub-c-0 to ub-c-1) was not a simple rebase by any stretch. I understand the level of effort involved in the work you already did, and the work you're choosing not to do, and i would probably make the same choice as you, were i in your situation. > I propose that a better way to get a handle on the complexity is to > look only at the current commit tree. Michael's excellent document [3] > (specifically written for this audience) explains the rationale and > architecture behind the work, and details how to build and run the code. > Reading it is a half hour well-invested, trust me. > > Michael and I aren't going to go anywhere. We're very available to help > with problems and answer questions. We're committed not only to > developing this code, but also to make it easier to use, as demonstrated > by our efforts over the last half year such as packaging kernels for > many environments, supporting testers, writing documentation, and > Charles's providing BeagleBone images. I'll try to spend some time this weekend to review the end result of the ub-c-1 branch. I'll look for you on #linuxcnc-devel when i have questions or comments. -- Sebastian Kuzminsky ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
