Lars, I'd suggest cloning emc2's current master on say github, branch and apply from there, so at least you're working within the emc history trail and there no sudden history-free 'out-of-nowhere' patches
when the dust settles, and the it could be made a feature branch on git.linuxcnc.org when it's really usable it could merged I'd assume the EMC board does have an opinion on the issue -Michael Am 27.07.2011 um 11:04 schrieb Pavel Shramov: > On Wed, Jul 27, 2011 at 10:35:52AM +0200, Lars Segerlund wrote: >> Actually it's the patches from : http://www.bitmuster.org/projects/emc.html >> >> I spoke with Michael Abel, and the patches I had and the one he had >> done were from the same origin, ( check his page above ). > You've used his patches or from origin? That's really not important but > just for curiosity. > >> The patches are not intrusive, and unless you build with RT-Preempt >> support they don't affect anything. > Problem with patches vs public repo is that they lack 'origin'. > You don't know what version you need to apply them, you can not reliably > track changes etc... > >> Micheal also added semaphores and shared memory to linux_rtapi. >> I am trying to put them through the paces right now on a parport >> interface and some steppers, so far so good. > So patchset is changing... Another argument to settle it in some repo. > >> I would like to ask, how do one go about becoming an EMC developer ? > Heh, since you are working on it - you are EMC developer :) > >> Also would it be ok to get the patches from above location ? > If there is no other way to get them - yes. > > Is it possible for you (or maybe Michael) to setup repository with your > patchset > somewhere? github (or gitourious) are easy to start with and allow you to > commit > anything you want without threat of breaking main emc2 repository. But will > provide > others with good point to track your changes, review and maybe merge to > mainline. > > If it's not an option somebody may merge theese patches for you but that will > do > more harm then good -- you won't be able to control that process and for > example > if merger has no linux-rt testbed may introduce untested bugs. > >> And could there be a rt-preempt branch or does it go directly in mainline ? > It depends on complexity of changes and probably should live in separate > branch > for a while. > > Pavel > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don't ask for help often. > Plus, you'll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
