Hi, I should say that unfortunately I mostly agree with GeeJay, both for the chaos thing rant and the unstable trunk. To make it more transparent and in case Fabien didn't got the mail, here are the relevant parts of the message I posted on the partner list today:
Ideally trunk would be a lot more stable. As Geegay suggested untested risky dev is better done in branches. And about regression: a continuous integration server would be ideal, the best open source project have that. Of course all this have a small cost. That's very well if you can't afford that now. Then I would suggest more explicit and systematic tagging to provide more clues on what is going on, here is what I wrote: "I would recommend tagging the trunk a lot and explicitly, to highlights what the changes are, no matter how unstable it is: partial information is better than no information. They are indeed larger development phases than the basic commit sets Tiny.be is aware of but the issue is that, we, the poor mortals, have no clues on those phases and should crash test every single release version instead. I think they are better ways to make everybody more work efficiently and hope OpenERP will tend to it. Also notice that JRuby don't tag extensively unstable release, they use to release very frequently and also keep trunk very stable as well instead. But I experienced tagging extensively when I worked for large software projects in Amadeus and I would say that if you can't warranty that trunk is stable enough with say an integration server, then that's better than nothing. Of course a pubic integration server would also be a must." Then I suggested some concrete actions to help keeping a better consistency of the trunk: " 1) You tag the trunk after every big dev phases, like 'new process feature implemented', 'access rules refactoring mostly done' etc... 2) You work out a list of people, if not the partners, you can rely on their bug reports, so you look at them in priority, because chances are those report are more pertinent than the average beginner experiencing some usual difficulties with OpenERP. Analyzing Bazaar merges proposals is great but I just think there should be a room for some in between between a merge proposal and a non qualified bug report. Looking at bugs with included patches might be a good first step. 3) As the developer network just keep growing worldwide, I would personally suggest to have things like irc channels for real time communication. Of course, you might fear the average beginner would bloat it up and make you waste your time. Several possibilities: restrict that channels to Tiny.be internals + partners, or simply state it clearly that feedback from Tiny.be is only provided to either simple questions or either for active contributors. " Overall, I'm really happy with the recent improvements of OpenERP and I really don't want think I'm some spoiled naysayer. But I just hope that you can lower even more the development entry barrier to get maximize the feedback and develop even faster. I should say contrary to GeeJay, I really like the idea of decentralized blog communication right from the developers and even proposed that at Smile.fr (not yet accepted unfortunately, we are a bit old school), that's pretty much how open source generally works; even Google or Sun now do that for their communication and I think they are doing it right here (take a look at talented bloggers like Dion Almaer, Charles Headius Nutter or Steve Yegge to know what I mean) : then you don't need to waste too much money on marketing so you can afford being nearly free and really change the game. Take Openbravo or Compiere, they have a much more corporate of communicating instead, but the drawback is that they spend a lot on this and the cost and entry barrier of their product is thus much higher. Openbravo sometimes said that they had no doc because they didn't hired some $$$ 'senior' doc writer yet. By far I prefer the approximated english posts of your Indian dev network than nothing until you injected nearly as much money in the oss ERP than a proprietary ERP before getting any doc out, not to speak about the low peer review that second option has. Still, that's true, the information could be way better organized I think. Also, getting started to the basic development or even installing the ERP from source or even installing it is still way too much complex. Lot's of windows users get their install all screwed up with the postgres rights, even with the latest version, no joke. Still, who is not able to install the stuff properly will never manage to have OpenERP properly, so this acts as the filter barrier actually. Now, this leads to a lot of frustration for those users/beginners and I'm not sure this is the best way get a nice fame. May be it would just be better to have a more streamlined/robust process both for installing and getting started so users have first a very nice feeling about the products and still you would state EXPLICITELY that without strong ERP + computer science knowledge + willingness one would never get it running right without hiring some consultancy. They will notice it but at least they couldn't feel misinformed as they sometimes feel now that you lowered the access level somewhat with the book. My very volatile 0.02$ Raphaël Valyi. ------------------------ http://www.smile.fr -------------------- m2f -------------------- -- http://www.openerp.com/forum/viewtopic.php?p=25287#25287 -------------------- m2f -------------------- _______________________________________________ Tinyerp-users mailing list http://tiny.be/mailman/listinfo/tinyerp-users
