Am 21.10.2011 um 01:57 schrieb Dave: > On 10/20/2011 2:20 PM, Kirk Wallace wrote: >> Not yet, but that is my fault. To take a more anti-NML approach, it >> might be argued that extremely few EMC2 machines are in production >> environments or even on a network. It seems EMC2 might benefit greatly >> by optimizing it for a single computer/user hobby shop context. >> > > I think it would be a big mistake to confine EMC2 to a single PC.
I do think so as well, even if that entails more complexity. So far, fine - we agree on an issue. Unfortunately, opinions are a dime a dozen, and no concrete activity derives from our consenus. And now the part that is defective with the EMC project: This needs to be made a *goal*. That means it needs to discussed in a moderated fashion, and decided and communicated with respect to direction, extent and timeframe. That's a prerequisite so the work can be broken down to fit into folk's individual time budget. And that is a key issue around here: small individual time budgets, no agreed direction, no division of labor possible, no progress on large issues. Let me give a example how that could look. Let us assume that the software shutdown behaviour of EMC has been identified as an issue. For instance, milltask going haywire could raise havoc. - overall goal direction would be 'harden EMC by providing monitoring/fault detection and controlled reaction' - broken down extent would be 'milltask needs XYZ','foo needs bar', 'watchdog needs fixing', 'the standard hardware configs parport, manufacturer A,B and C shall get a kill switch', 'a manual section "How to react fast if shit happens" should be started in section X' and so forth. - Timeframe for a milestone: "we want milltask self detection and shutdown for parport and config A,B,C working and documented by release X which is roundabout month Y year Z'. The result is called 'division of labour', has been invented and does work even for Open source projects, although it seems there are few believers around here. But I am certain it would work. I lay the responsibility for *managing that process* at the EMC board's door. NB I did not say 'goal definition'. And: it is largely a social activity. Here are examples from OpenVPN, a well managed project (a bit unfair comparison I admit - it does have outside funding): https://community.openvpn.net/openvpn/wiki/IrcMeetings https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation To summarize: The EMC project has some excellent technical outcome, but its management approach has not scaled with its success, and the growth and change in developers. Note this is not blameshifting - it is a great problem to have. Many OS projects would just love to have it: the need to scale in the face of success. But it needs to be addressed now. If this doesnt happen, EMC will continue in the current mode, which is growing by either: - "let me lay my stunning individual contribution at your doorsteps, I felt through osmosis and phase of the moon that this needed to be done" - "here is my heroic bugfix" - Michael ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
