Hi list,
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]
*************************
Here is a summary of the issues raised about the code itself in
Saturday's discussion, and how this rebase addresses those:
* Conflict markers
Bad merge commits with merge conflict markers ('<<<<<<<', '=======',
etc.) left in code break builds, and by extension the git bisect workflow.
Such merge commits are amended and their later fixups squashed or
removed. (There is one case where markers remain in a single
documentation file for four commits during a string of merges; it was
simply too difficult to remove them, and their presence won't interfere
with bisecting.)
* Strings of 'wip' commits
Strings of commits with messages like 'wip' early in the history cause
both readability and buildability problems.
Those commits are squashed together. They were in the tree from
Michael's first Xenomai work in October when he was still working by
himself, dabbling with that first alternate RT system.
* More meaningful commit messages
Commit messages like 'wip' and 'touchup' aren't sufficiently meaningful,
and were reworded.
* Bogus authors and emails
Commits with bogus author or email fields are corrected.
* 'emcweb' needs to be renamed
This rebase does not rename emcweb. Michael announced the inclusion of
emcweb in our proposed branch earlier on the list, and no objections
were raised at that time. At this point, the concern over the string
'emc' in its name should be considered part of the bigger project to
remove the name 'emc' from mainline code.
*************************
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.
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.
As for the Universal Build branches: we have not yet announced the
earlier branch for evaluation by the community at large, and will also
not do so with the rebased branch until we have more feedback from the
current, closed circle of advanced testers, and a general picture of the
branch's status and usability emerges. Thanks to all you eager, itchy
folks for keeping up your patience!
John
[1]
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-07-27.html#16:55:03
[2] http://paste.ubuntu.com/5940760/
[3] http://static.mah.priv.at/public/UnifiedBuild.html
------------------------------------------------------------------------------
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
