On Wed, 2009-02-04 at 11:58 +0000, paul_c wrote: > On Wednesday 04 February 2009, Chris Morley wrote: > > All valid points that could have been a good start to a discussion for > > changes rather then deletion. The panel did not just have buttons > > for offsets.
The EMC development community does not, nor has it ever used an autocrat to govern it's development. On occasions we have leaned heavily on one or two code writers but that does not mean that those folk are in charge of the direction of the project. > Chris, your thread raises several questions, none of which have had a > satisfactory answer when asked in the past... We really should be asking this questions of the EMC board -- of which Chris is but one member. > * Who decides what "features" get included. The recent disagreement between at least three folk is not at all new. These disagreements have cropped up from time to time since the project evolved at NIST. > * Who is responsible for which sections of the code base. The community -- like it or not. > * Where is the guiding policy document detailing ongoing development. Policy? "We don't need no stinking policy!" But you are correct that even the most agile sorts of code development have some sort of systematic approach to the road ahead. That may be as simple as a policy about how the code repository works. It seems to this observer that what has happened recently centers around who wrote the original and the vision they had for it. As others saw potential for new abilities that piggybacked the earlier work there was a clash of vision. IMO a better product comes from the clash of visions. We need to be certain that we focus the disagreement on the vision and the code rather than the people involved. I think this is proving to be the case this time as well. > * Where is the public discussion & code review conducted. Right here and on IRC. > In regards of your particular case - Not everyone wants to be forced in to > using one specific GUI. So if pyvcp offers something that has a more > universal appeal, it should be worth considering.. On the flip side, > if "duplication of functionality is forbidden", then I would take that as a > green light to arbitrarily delete the cruft. So if axis duplicates pyvcp > functionality, remove it from axis. Wah! If we are not permitted to write and explore multiple approaches to any part of EMC we are back in the motion control dark ages. I seem to remember a "dark ages" meeting between a few of us in Matt's garage and driveway where an attempt was made to steer EMC away from HAL. I've since become a dedicated user. This is not intended to make light of any one person's effort here. I really appreciate each developer and the contributions they have made but these are some really big and important things. Once again the pool of contributing code writers is expanding and that expansion causes some friction. The key to the future is that we not prevent contributions, rather that we encourage tagging, branching, and development of the widest possible range of machine control options. M2CW Rayh ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
