Kent, Am 28.10.2011 um 19:29 schrieb Kent A. Reed:
> > As much as I want to be I've had to admit to myself that I'm not going to be > a core EMC2 developer nor am I likely in my remaining years to work with > machinery > Regarding a proposed revamp of EMC2's logging capability and the question of > Python, do you believe Python's existing logging capability is sufficient or > do you envision some sort of Python-log4cxx mashup? no, I still have to look into Python options here. I'm not married to a particular approach, but I would think a guideline what to use how would be better than various ad-hoc mechanism ranging from the clever to the printf. > One of those questions was "how will the results be implemented?" Maybe it's > clear to the developers and the board, but it isn't clear to me which of the > items you discuss need be introduced simultaneously as a major revision and > which can be introduced individually as minor revisions. I'd say first an agreed, spelled out direction is needed, on issues large or small. Sometimes it's hard to figure wether a small change is in scope or not. However, it feels extra odd to attack a large issue with about as much solid basis as a line in mail from years back saying 'wouldnt it be nice if..'. Again, initiating and moderating this goal finding process is more of a social exercise, and I think is misunderstood by many as primarily 'technical'. Once that's done, you can look into divying it up, and that can assume different shapes or forms. There is, however, no point whatsoever in trying to divy up some implicit osmotic self-understanding some might perceive as 'direction'. To stay with the world model example: the touchy part is deciding for some 130+ variables in the interpreter which part of the state model they belong to. For many variables it's completely clear; for some it isnt; for some historic knowledge would help which I lack; some are fluff. That said, divying up the work doesnt necessarily mean person X commiting to modules a and b, and person Y to modules c and d; with that example it would be extremely helpful just to have a review commitment by others. That rewrite IMV would have to come in two stages: first, divy up the state as outlined. That should be a drop-in replacement for existing code with no visible changes, including to emcStatus fields I hope, and I think that could be exercised by some well though-out regression tests. So, merge of a branch with quite a few changes. Second, one could start moving parts of the state to the redis mechanism, and start expanding on the status quo. That would lend itself more to incremental change and debugging I guess. - Michael ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
