About communication and expectation(, and about packaging). It seems planning and communication with the community is a worrisome subjet. And indeed there is no surprise (at least for me, on a personal basis) this is the case!
Nobody in the R&D like to announce plan that we're not able to fulfil in due time. Still, some people (it is always hard for us to judge the community as a whole based on the comment of a few persons) are eager to know more. Actually, it is even worse: we can't annouce things we don't plan at all. As a clear example, let's talk about the openerp-command Antony mentioned in its comment. (Similar stories can be given for a lot of things people complain they were not shared with the community before they were 'done'.) I started that tool because I was tired of writing throw-away/one-shot scripts to try out things when working on the framework. I started that tool because when giving the one week technical training I wish I had a scaffolding script to generate some empty/sample module to show to the trainees and improve upon. I started that tool because I knew it would be a good place to add some benchmarking client-side code. But none of the above reasons was a priority. The script was not an official, planned decision. So what? Should I have stopped working on it and wait for our management to agree with my views, wait for the PR team to do the communication, and only after resume my work? The end result is a new, evolving script, with no clear resource (i.e. time) affected to it. And at some point, it becomes clearer in our mind we want to use that tool more widely. And we then decide to share it with the community. I believe this is the normal course of action in open source projects/communities. You scratch your own itch, then share the result. You don't repeatedly bang on the doors of some developer to get the features you want be developed. (Or maybe I should bang on the doors of Guido to get some static typing.) Of course, some things definitely need to be done in concert but not writing and releasing in the wild some trivial script (even if it is insanely useful). As surely we understand it can be frustrating to feel being left on the side of the road, this is not what we're doing. Maybe it is a situation that developers are being acustomed to and not end users, but this is the reality of developement: things are not always planned, things are not always ready when we want them. Should we not release a new script or a new feature because it was not announced with a six months notice? (About packaging.) It is the desire of (at least part of) the R&D to be present on pypi. We still need to make sure it is the right thing. At this point, I'm sure a lot of you will think 'of course it is the right thing'. Even maybe 'this is the only right Python way to deal with packaging and dependency management'. Well this is not as straightforward as this. For instance, is namespacing a 'Python' way? And it is not only about dependency management. OpenERP is a complex beast. People don't only create packages that depend on other packages. As a matter of fact, people create drop-in replacement for official OpenERP modules. If it is a drop-in replacement, surely it would be a problem for a module to strictly depend on, say, openerp_sale. This means it wouldn't work with my <partner_name>_sale module. So again, what can we announce here? That we are thinking about it? Make some kind of planning? This is the kind of things that need a proof-of-concept. And when you have such an executable proof-of-concept, you're very close to have the thing you will shortly announce (and people will complain because it was not planned). Here again, the best thing to do is to write code. You can do it and share it. Or we certainly will write something, try it, think more about it (maybe write something else and see if it is better) and share it. Please don't feel bad because we didn't announce it. When will we really give a shot at being on pypi? Nobody knows. For instance, in my opinion, we should first work more on testing and bechmarking our code, and write quality documentation, and write an awesome openerp-command, and... (And obviously we can't do everything at once.) -- https://code.launchpad.net/~openerp-community/openerp/skitzotek_trunk_symlinks/+merge/93115 Your team OpenERP Community is subscribed to branch lp:~openerp-community/openerp/skitzotek_trunk_symlinks. _______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
