Hi all. [ Glossary: "we" = all experts and community, if the following opinions really express others but the writer ]
I have been reading the latest threads about all the features we would wish to see in v6.0 . During the past months, many of them have been discussed extensively, some people like it and some not. The community has had a large number of wonderful ideas about improving the framework, the modules and other points. I was one of them, with some ideas hitting the trunk (and making you suffer), some others rejected. May I remind everybody about our goal, which is to release v6.0 ASAP! You see, we are left with v5.0 in production state, which has so plenty of little issues or missing features. It is more than a year that we have not had a "stable" feature release (slipping features into 5.0 is a sad fact).. So, we do need a v6.0 release, we want a hot new product to market. This means that any change we make now, will have to consider implementation time and any implications that would set other parts of the application back (like breaking the API in a non-backward compatible way). Also, consider that some features will need enough of our resources in discussions, implementation, testing etc. Please be very strict about that. /On the other hand/ this doesn't mean that we are going conservative and turning down any good idea. There is always room and intent of improvement. If not in v6.0, in v6.+ My suggestion: 1) Respect the release schedule (yes, the one that we're running late) of v6.0 2) Submit ideas. Preferably, with a proposed course. Even better, with a good description and estimated time, implications for other parts. 3) If you think you can give an example, please code it. Just the minimal way, not big changes at this stage. Do write stubs and parts that would be better implemented in a later release. (= don't expect a perfect implementation now). 4) Try to answer the question: do we need to hold back v6.0 for that, or can it go into v6.2? or does it belong to a v7.0 release (=big change)? 5) In some cases, a change in the API would mean that if we don't put it now, we will have to wait until a v7.0 release (because it will be API- incompatible). Then, does it make sense to have a *provision* in v.6.0 for that? I mean, if we don't put the full implementation, but just one variable, one function argument for future use (that will now raise a NotImplementedError), will it suit us? I think it is a nice way to avoid breaking the API after v6.0 again. 6) Please, be very descriptive (and, still, short) in the way you write ideas. Not all developers have a deep knowledge of all code corners. If we explain to each other what we are changing, we help understand and vote for changes. 7) In all cases, thing about backwards compatibility. Don't expect your patch to require changes to all modules, etc. Make it behave right, when modules don't call it correctly. 8) Some patches/ideas *will* be rejected, or put in the large queue.. Please bear with that, let us not waste too much time discussing that. 9) The fact that some ideas are not in the trunk, doesn't mean that OpenERP is a closed product, being only developed by a cast of priviledged people. Everybody's branch is still important. 10) For that, I have proposed a system of "slots", where we could optionally develop new features in a way that they will smoothly fit in a server, and called only if they exist. Servers/clients should fallback to the trunk behaviour, if the feature is not present.. And, last, I'd like to keep spending my extra time to test things, so I would take any good-looking (yes, subjective criteria) patch and merge it in my personal branches. This would give new ideas some mileage, before they can be considered for the trunk. I suppose other experts /could/ do the same, and I prompt them to do so: to take each other's patches and examine, so that each idea has been revised enough. Thanks. _______________________________________________ Mailing list: https://launchpad.net/~openerp-community-leaders Post to : openerp-community-leaders@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community-leaders More help : https://help.launchpad.net/ListHelp