* Betr.: " Re: [tryton-dev] About API-Migration" (Fri, 20 Jan 2012 14:16:32 +0100):
> 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. So it has nothing to do with migration, the subject of this mail. > > > > > 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. Yes, there is a 'problem' in the standard modules: a company (at least in Germany) with sophisticated requirements won't use them as such, because they don't meet the usual and common standards that other comparable softwares provide. There is no common solution to fit for every business. As long as you remain generic (which is of course a good thing), you will be in customization. > > > > 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. ? From my memory we asked on IRC to make a short inquiry, if there is a chance for inclusion. You were convinced, that it was enough to have the update functionality for accounting charts instead of having them separated by fiscal year. It is clearly a waste of time to do a blue print, that will never be accepted. > > - 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 Fine, I missed that one. > > - 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. Perhaps, perhaps not. As this discussion shows it is not easy to get things changed or accepted in Tryton. We are meanwhile doing a short internal investigation of features, if we should propose them. If we feel, that there could be a slight chance we do it. In this case I am pretty sure, that some large part wouldn't be included the way we need it. > > 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. Yes, we are used to that. No need to discuss it further, because you miss the point. I am showing, that for our requirements a lot of customization is required. Again: I suggest it will perhaps not be as accentuated but similar for other integrators in other countries. May be I am wrong and they can work with not customized standard modules. May be they are not yet hit by the problem, because they don't work with Tryton as long as we do. Would be nice to get some input here. > > 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 And probably the other way round. It seems that you keep the secret of absolute knowledge in those topics, if not all. > > 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. Again you are distracting from the subject. It is not about the quantity of changes, but about the quantity of expensive migrations. > 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. If you are developing a framework providing a tool like wizards you should be aware that it will be used. Extrapolating your own missing use of the feature is not adequate. > But it is the price of such "closed" modules. No, it is the current price to use the framework at all. > 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. We are going in circles. You know very well, that usually we are participating in those tasks. You simply don't want to accept, that all those modules designed exactly after the conceptions of Cédric Krier are not enough to meet all requirements needed in the daily life of an integrator or a company. I see your point with genericity of modules, which is mine, too. You don't see my point of the need of additional customized modules. We can stop discussion here. > > > > 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. Where did I speak about the planning of bug fixing? > > > > 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. I can not follow at all. If you are saying 'Change of format of __tryton__.py' won't go into 2.4, but into 2.6, because there is enough change requiring migration, then it will be put on another project, probably named 'The beauty of __tryton__.py'? > > > > > 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 Fine! I added them to the wiki page. Even better if you can include a recipe to automate the task or describe what to do. -- 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
