* Betr.: " Re: [tryton-dev] About API-Migration" (Thu, 19 Jan 2012 14:41:26 +0100):
> On 19/01/12 14:06 +0100, Mathias Behrle wrote: > > * Betr.: " Re: [tryton-dev] About API-Migration" (Thu, 19 Jan 2012 01:13:14 > > +0100): > > > > > As I think there is no need for such limitation (even if I think we have > > > never made and will never do big changes close to release date). > > > > > > Almost every API changes that require the code to be adapted, are done > > > in such way that the code will fail to run if not changed. > > > From my experience, I do the update of the official module by looking at > > > failure. > > > > I can not imagine, that you are waiting always for failures on unittests, > > when you are expecting, that several modules have to be adapted for specific > > chnages. It is much more time consuming to only run for failures than to fix > > the code in advance. > > Waiting unittest failure doesn't consume time. Waiting ... doesn't consume time :). Nice. > > > 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? > > > 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. > > 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. - 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. - 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. 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. 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. 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 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...;) > > 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. > > > 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. -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
signature.asc
Description: PGP signature
