Am 04.02.2013 um 16:20 schrieb John Kasunich: > > > On Mon, Feb 4, 2013, at 09:43 AM, Michael Haberler wrote: >> >> Am 04.02.2013 um 14:11 schrieb EBo: > >>> So my question to you is how long do you keep the 2.5 branch if/when a >>> 3.0 branch becomes stable and fully functional? It should not be 0, but >>> it also should not be forever. >> >> I dont know. I would think the 2.5 branch is a maintenance-only thing, but >> the >> things that are added to it arent consistent with that. I cannot discern any >> communicated policies. Clearly there are lots of un-communicated policies >> around. > > I think the policy is that changes within a major version should either > be bugfixes or improvements that don't break existing configurations. > > In other words, if a user updates from 2.5.2 to 2.5.3, they should not > have to edit their configuraion files (.ini, .hal, tool table, etc). They may > choose to edit the files to take advantage of new features, but they > should not be forced to edit them just to keep their machine working > like it was before. > > Major revisions are allowed to require changes to configuration files, > but the changes should be well documented, preferrably in a step- > by-step document. If there are extensive but straightforward changes, > a script that can do the grunt work would be much appreciated by > the users. Switching from 2.5.6 to 2.6.0 can be expected to cause > some pain, but we should try to minimize it. > > Changing from 2.x.x to 3.0.0 is something we haven't really talked > about. Obviously that would imply major structural changes.
makes sense to me. So far the Xenomai and RT_PREEMPT RTAPI builds run my mill without a user-visible config change. (of course realtime and other scripts behind the scenes are impacted, but the user configs arent) >> Re length: look at it this way: the remapping code added to the >> interpreter was way more massive than the new RTAPI layer in >> terms of LOC. AFAICT there are no open bugtracker entries >> with bona-fide bugs (modulo Xmas wishes) wrt remapping, and >> none which were open more that a few weeks at most. >> >> That branch is entirely usable, and is used; the windows of >> outright brokenness were very short. > > I see this as something that could be added in a minor revision, > since it (hopefully) won't break existing configurations. But to > be honest, since it is a major new feature I would think of it > more as a version 2.6 thing. there it is pretty much, remapping is in master, so that's fine Initially it broke configs by requiring a new section, but I removed the necessity a while ago >>> absolutely. But where do you dry the line between changes that are big >>> enough that they deserve to be slated for 2.6, 2.7, or 3.0? Working >>> incrementally is all find and good, and if we really refactor various >>> pieces of the code to make them more modular or update HAL so we can >>> drop NML, Each of these changes are serious enough to be designated a >>> revision to version bump. >> >> the line I see goes like so: >> >> The messaging-capable HAL layer will have a new API, which >> subsumes some of the existing HAL lib functionality. This >> should be a published, usable API, meant as a base the using >> code in the rest of Linuxcnc (task, GUI's) can be adapted for. >> I think it should also aim making HAL/RTAPI and the HAL-based >> GUI tools usable standalone, without the rest of Linuxcnc code >> draped around it; this isnt only a good sanitary exercise but I >> think is is a tempting tool for entirely new, not classic LinuxCNC-type >> applications. In fact I see no competing attempt for doing that, but >> I see lots of fellows fiddling Arduinos hoping to do something >> which that could do, and then some. > > What exactly do you mean by making HAL/RTAPI usable > standalone? It already is - I've done several things that use > halrun and a hal file but never load task, motion, or a LinuxCNC > GUI. And I know others have done the same. oh, absolutely. There's even an example by BigJohnT in the manual now I think, for HAL+RTAPI+Gladevcp. > Are you referring to making HAL/RTAPI an independent > package that can be installed without the rest of LinuxCNC? I would think that makes sense on several fronts, in particular once work on a HAL messaging API starts. In any case LinuxCNC would remain, and depend on that package. The API used by LinuxCNC would change from 'current' to 'messaging' over time. Once that is complete, the dividing line between the two packages would also be the realtime boundary; there would be no need anymore for the LinuxCNC package proper to be in any way dependent on a particular realtime OS or RTAPI except for the messsaging API. That means LinuxCNC per se would be in principle free to use any UI, and a much wider range of underlying OSes. I see quite a few potential users for such a HAL/RTAPI package; of course it isnt impossible right now, as you say, but the fact that it is integrated with linuxcnc brings not only baggage with it. I would think few people outside the Linuxcnc community are actually aware of separate HAL/RTAPI use is possible, and would consider using it standalone. Maybe Peter can chip in here with an idea for another use case we recently discussed offline. The HAL/RTAPI package would inherit most of the build complexity as now LinuxCNC is pretty much standard userland code; reworking an HAL/RTAPI only build process is a little bit easier than the whole of LinuxCNC. I also see some benefit on the relicensing them (without having properly researched that yet, though) - I would think that HAL/RTAPI - given it has much fewer authors - could be more easily morphed into a less restrictive license enabling the use of several key packages needed for the messaging API. Eventually the whole of LinuxCNC must be relicensed IMO, but at least we have a starting point. So this effort would roughly contain HAL, RTAPI, HAL-capable UI tools like gladevcp, comp, plus the future messaging-based API. As a tentative name I propose 'MachineKit' or 'Realtime MachineKit', so the baby has a name which doesnt break the tongue and conveys a bit of intent and functionality. - Michael > > > -- > John Kasunich > jmkasun...@fastmail.fm > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_jan > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
