IMHO This proposal has multiple goals packed into a very short summary. Since I have not read a rationale for this proposal, I hope I am not confused about the goals.
Anyway, to me it breaks down into at least 4 things: 1. The "machinekit" name 2. New features in RTAPI and HAL such as zeromq 3. Source code organization and possibly release management 4. Distribution packaging (note: when I write 'hal' below I generally mean to indicate 'rtapi and hal') Let's go from back to front: 4. Distribution packaging I do not use any storage-constrained systems in my day to day life, but for those who do, the current monolithic package (except for -dev) may be a problem, because e.g., it pulls in 2 graphical toolkits and at least one interpreted language that are not in a typical base system. (xaw, tk, tcl, and maybe python depending on your base system) To serve the needs of people with storage-constrained systems, we should clearly consider patches which split the current monolithic linuxcnc.deb package in a way that serves them better. I am +1 on this idea, though as far as I know there are no proposed patches as yet. Also it's not 100% clear to me that hal vs non-hal is the right split point. For instance, without looking I assume that it is the UIs that create the greatest foot print in terms of installed size with prerequisites. (for instance, stripped of debug information, milltask 200kB and motmod is 100k) On the other hand, halshow is a tcl/tk app so if the packaging split is hal vs linuxcnc then the hal part would still pull in tcl tk. (related: configure flags to disable stuff at build-time are also good for many of the same reasons and I'm +1 here too if someone does the work) I welcome the RM's input about whether packaging changes between now and 2.6 are welcome or unwelcome. 3. Source code organization and release management The primary user and driver of new hal features is LinuxCNC. As a result, I personally am happy that the LinuxCNC release cycle drives the hal release cycle, and don't experience any pain resulting from hal and linuxcnc living in the same git repository with a single release branch managed by the same release manager. At the present time I do not see a reason to change this. This questiom would merit revisiting once there are substantial non-LinuxCNC users of hal. As a result, I am -0 on this idea right now but realize that it may change in the future. Remember, as long as we learn to use git better we will get better at incorporating changes from people whose interest is in the hal layer even if it's still part of a monolithic linuxcnc.git. 2. New features in RTAPI and HAL such as zeromq These need to be reviewed independently on their merits. They should not be a part of this proposal. Since these are not ready for review I cannot comment, but I'm optimistic that once the code behind these ideas is ready for the light of day we will be able to see that it improves LinuxCNC (e.g., that it will happen to simplify halstreamer/halscope/halsampler's handling of rt<->userland fifos by providing a single working ring-buffer implementation that can be used in 6+ sites). 1. The machinekit name I prefer to keep the name LinuxCNC related, such as "LinuxCNC HAL". I imagine other people will have different names to propose, and I'm not sure how best to settle it. All items but #4 (depending on RM's opinion) look like post-2.6 so I'd also prefer to punt them down the road until 2.6 is on our users' systems. Jeff ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
