On Wednesday 04 February 2009, Ray Henry wrote: > On Wed, 2009-02-04 at 11:58 +0000, paul_c wrote: > > 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.
The "EMC board" over the last two-three years has on one hand sort to dictate terms, and on the other, ignore their mandated responsibilities. The last two "elections", and possibly the third, have been conducted in a haphazard fashion, as a result, I (and a few others) no longer consider it a valid entity. > > * 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. During the time that NIST was involved, I don't recall any disagreements. Plenty of screwball ideas floated, but Fred Proctor was always willing to listen. However, the goals of NIST was never to produce a product, just to demonstrate an idea. > > * Who is responsible for which sections of the code base. > > The community -- like it or not. In which case, the "board" has even less relevance. > > * 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. You certainly need a policy more than ever - There is already a note on coding style that everyone can stick their fingers up at, so it would be reasonable to have a similar one for general development. > 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. As I see it, someone (Chris Morley) wanted to extend stepconf so that it had uses beyond one specific GUI - An effort I for one would support. There is little point in producing a different setup wizard for each and every GUI - It duplicates work, turns support and debugging in to a nightmare. But if the only way to configure this stuff is to use some pointie-clickie tool, then HAL (and the "board") has failed in it's stated aim of simplifying things. > 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. If you build on sand without solid foundations, it will eventually fall down. > > * Where is the public discussion & code review conducted. > > Right here and on IRC. Not everyone has time to waste to spend on IRC, and what (limited) discussion on code has been tendered here has had little impact. >> >> > 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. I said at the time, I want an industrial strength control, not another second rate hobbiest package (there are plenty of offerings available for Windows). HAL in it the form that it was originally proposed was worthy of persuing, and as long as it provides mechanism rather than policy, it still is. I also remember the week beforehand spent at NIST - Even when in the same room, everyone would huddle over their laptops or in pairs and wouldn't discuss anything. Hell, even over breakfast, agreements were made and then forgotton about as soon as the bill arrived. > 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. Little is being done to encourage new developments, if anything users are actively discourgaged. ------------------------------------------------------------------------------ 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
