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. > > 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. > > 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. > 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. > > 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. > 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. > 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. > > 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. -- 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/
pgpXvb3XjKDLy.pgp
Description: PGP signature
