On 20/01/12 13:04 +0100, Mathias Behrle wrote: > > > > So here is how we work at B2CK with our custom modules that we maintain > > > > internally. We have unittest for each one that try to almost cover all > > > > the code and we run it frequently with trunk. When it fails we adapt it > > > > according to the last changes that have been pushed. > > > > > > Trunk is clearly too unstable to be used for customer developments. Even > > > release 2.2 is just now getting rid of bugs and finally ready to be used > > > for > > > customers. We don't think it is possible to develop on trunk for > > > customers. > > > BTW AFAIR a lot of modules you propose on codereview are primarily not on > > > trunk. > > > > This is not what I said. > > I'm speaking about maintaining a module. > > If you are permamnently maintaining your modules on trunk: How can it happen, > that you put in codereview a module for current series?
I think you don't understand what I mean by "maintaining". Maintenance is what comes after the release. So it has nothing to do with the development process. > > > > Also I would like to remember that series are supported for 2.5 years > > > > this give an average of 1.25 year to migrate and it is not required to > > > > migrate through each series. (I did a migration from 1.4 directly to > > > > 2.2). > > > > > > I read it and I congratulate. I for my part had to throw some test > > > databases > > > from 1.8, because they didn't migrate. I think it can work for simple > > > setups. The more customized and sophisticated the setup, the more problems > > > with migration. > > > > No this is wrong. It mainly depends on the quality and the genericity of > > the code. > > Of course, if you change completly the behavior of a Model, you will > > have a lot of work for migration if in some point the upstream Model > > change. But in this cases, a new Model could be a better strategy. > > Please stick to the subject. API migration has to be done whether your > model is generic or not. We are talking about the sheer amount of effort > needed for upstream changes like the expected wizard rewrites. > > It is the concept and in the nature of the framework, that you have to > do customization. Standards may be especially high in Germany, but I think > highly customized software is also required in other (European) countries. So > may be we are hit first by the problem to have to maintain a high number of > modules, but we surely won't be the last. No this is wrong, you should not have a lot of module for customization. If you need then there is a problem in the standard generic module. > > > And there *has* to be done a lot of customization on the official > > > modules. It is in the nature of genericity, that they often can not meet > > > the > > > specific requirements of a specific company. > > > > I think you don't understand what I mean by generic. A generic module is > > a module that will especially adapt well and will not need a lot of > > customization. > > What you say is that our current modules are not generic enough, so > > please help us with your experience to improve their genericity. > > Perhaps they are sometimes not generic enough, but that is not the problem I > talk about (we did contribute of course a lot of changes, when we encountered > problems due to missing genericity). > > As an example: > - In Germany we are required to have a perfect and flexible timeline for > fiscal > years and taxes. This is not doable with historization. To my knowledge we > asked at the time for possible interest and inclusion in the project wrt > timeline in accounting. There wasn't. So we have to customize it. There was no clear proposal for such feature nor about the requirements. Where is the blueprint, the codereview etc. ? > - In Germany it is not allowed to update posted moves. Perhaps inother > countries it is. You won't allow to enter such a change into the base, which > is perfectly understandable. We are still waiting the patch https://bugs.tryton.org/issue1412 > - In Germany we have de facto standards for accounting following one big > provider: DATEV. If you want to get a foot into the German market, you have > to be as good (our goal is better) than them. Our accounting interface has > to > be totally different from upstream to meet the requirements of German > accountants. I never saw any example or talk about the accounting interface? Where is the code ? I'm pretty sure there is some large part that could be included in Tryton. > Those are just very few points showing, that customization is essential for > the > use of Tryton at least in Germany. I don't think it is that different in other > countries. If you don't talk about your issue, you will have to fix it yourself without the help of the community. > Additionally you know, that we have often different point of views wrt > usability. You are always in favor of creating interfaces as a mapping of > underlying python libs, as can be seen in the codereview for account_invoice: > Payment Term refactoring (http://codereview.tryton.org/195001/). This may be > a perfect fit for you as developer, knowing the underlying structure. It is > surely not for our average customer. I will not start again the discussion about this but it seems you and some others don't understand me on this topic > This is another part of customization we have to do to be competitive with > similar softwares. > > This all to show: customization in a lot of modules is the natural fate of a > Tryton integrator. > > > > > In conclusion, I don't think it is good for Tryton to prevent new > > > > features or improvements to come just because there is too much changes > > > > in the coming release. If we behave like that we will slow down a lot > > > > the progress of Tryton. Moreover, if the inovation is not done in > > > > Tryton, it will be done somewhere else and the project will lost appeal. > > > > > > I am contrarily convinced, that the project will gain appeal, if it finds > > > a > > > way to provide a predictable and well measured way to address the main > > > target which are the integrators (at least from what I am seeing until > > > now). > > > We don't talk about *preventing* features, but about evaluating the amount > > > of effort *and* usefulness of a feature per release. > > > > How could we evaluate the amount of effort on something that we don't know. > > Such measure is done on the standard modules before implementing a new > > feature because we have it and we will have to do the work to have the > > feature accepted. > > There can be very well a rough estimation of the needed effort. At least you > can see meanwhile in the release cycle, that wizard rewriting and replace > nested view by reference id are cumbersome enough for one release cycle. I really don't see any problem about the quantity of changes as soon as their are good. Because in any cases, they will be there at some times so waiting for the inclusion is just about pushing the work later but in any way, sooner or later the work will need to be done. And more over, the estimation of the needed effort is not possible to do if we don't know about those hidden modules. For some of our own modules, the cost of the wizard redesign will be 0 because there is no wizard and some others, it will be more because there is 5-10 wizards. But it is the price of such "closed" modules. Let's remember you about the change of Pool and Transaction, the work was done in 1 week on all the "known" modules by everybody. It was a great success showing that we can acheive goals together in short time. The key point in this experience is about sharing the work that's the way OpenSource/Freesoftware works the best. > > > I would like to turn your mind to another important point: > > > We are dedicating a certain amount of our internal working time to > > > upstream, > > > but our ressources to do unpaid work are limited. The more we are consumed > > > by migration and fixing tasks, the less we are able to participate in > > > codereviews, blue prints, disucussions, blue prints, release tasks, etc.. > > > All of those latter activities are contributions directly raising the > > > *quality* of the framework. > > > > I don't see any difference between the two kind of tasks. > > You see no difference between fixing things afterwards and planning them > thoroughly and cleanly beforehand? You are kidding...;) It is a dream to think you can plan bug fixing. By nature bugs are not plannable. > > > We currently feel an unbalance looking at the efforts, we have to do to > > > remain up-to-date and the efforts, we can do to support the framework in > > > the > > > conceptual phase. We like to emphasize on the importance of the conceptual > > > phase, because a good design will reduce the later efforts to be done for > > > fixing (i.e. migration). > > > > Yes it is an investment. And I think until now we are quite good at this > > if you look on how modules don't change in term of business design. > > > > > You seem to want to push the trade-off between development speed and > > > quality in favor of development speed. We on the other side chose Tryton > > > for its quality and would like to stick to it. The goal of this thread is > > > to discuss this trade-off and make it planable. > > > > I don't think so. We have modules waiting for almost 1 year and other > > for arround 6 months to be included in standard. > > For me, it is not a sign of trade-off between quality and development. I > > think even the opposite, at the beginning we included more faster new > > modules than now. > > Again, please stick to the subject. We don't talk about inclusion of new > modules nor new features requiring little or no migration. We are talking of > those heavy migrations, that should be scheduled some way. Sorry, but it is freesoftware. If someone comes with a great new feature completly ready (reviewed, fixed etc.) that most of people wants and if we don't include it for any reason, then the feature will appeare somewhere else on an other project. > > > > About the wiki page for migration, I thought CHANGELOG was enough as > > > > memorandum but we could improve it (comments in the codereview). But > > > > any way, I don't think the wiki is the good place for such document as > > > > it must be maintain as close as possible to the code just like the > > > > documentation (don't repeat past mistakes). > > > > > > It seems you misunderstood or misread the wiki page. > > > > > > It is not just another CHANGELOG, but > > > > > > 1) a collection of all, but jest the necessary steps to do a migration > > > 2) a collection of recipes how to do the migration > > > > > > I don't see how you want to put this near to the code. > > > > For me it is the role of the CHANGELOG. Logging what has changed so what > > needs to be migrated. But as I said, we should perhaps improve the > > verbosity of it if it doesn't help enough. > > Currently it doesn't help at all. How do you want to include migration recipes > into the CHANGELOG. The wiki is a perfect place to do such collaboration. Sorry but after a quick look, the CHANGELOG is most of the time more accurate then the wiki page. For example missing: - Change format of search_value on ir.action.act_window - Remove tabpos attribute on notebook - Add readonly on Transaction - Rename expand and fill attributes into yexpand and yfill And more over you can look at the commit that adds the CHANGELOG entry. But for sure, there are places to improve it like the cron modification in the changeset [1] where an CHANGELOG entry is missing or the reference field modificition in changeset [2] [1] http://hg.tryton.org/trytond/rev/2f69de641ba2 [2] http://hg.tryton.org/trytond/rev/589cf65690bf -- Cédric Krier B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email/Jabber: [email protected] Website: http://www.b2ck.com/
pgpIVcyhWvdxw.pgp
Description: PGP signature
