I am really happy with how web2py development is going. As long as the project keeps growing, the code will keep getting better. You guys are doing a great job!
On May 23, 11:34 am, Iceberg <[email protected]> wrote: > > On May 22, 1:56 pm, b00m_chef <[email protected]> wrote: > > > Learn from the best on how to manage a release > > > cycle:http://www.youtube.com/watch?v=i7pkyDUX5uM > > On May23, 9:17pm, mdipierro <[email protected]> wrote: > > > > > > > Let me explain what we do now because it has some similarities with > > what described in the video below (above). > > > There is a single web2py. I do not branch a release and fix bugs in > > the brunched release. A release in web2py is just a snapshot in time > > of the official web2py branch. This means we do not need to have a > > testing team and a development team. We do not have problems with > > people working on different branches. I always run the latest (trunk) > > version and I hope other developers are doing the same. > > > Because web2py has to keep API backward compatibility we do not the > > concept of "locking" the API because they are always locked. > > > When I receive patches they belong to one of the following categories: > > 1) a bug fix. Usually they are in response of a clear problem and > > problem and self contained. > > 2) a new feature. In this case I look at the code and make sure it is > > backward compatibility. I may or may not test the new feature. I > > usually ask users to do so. The person who proposed the new feature > > usually tests and maintains the new feature. > > 3) a rewrite. This happened rarely but has been the cause of some > > problem. Once in a while we feel that some piece of code (complex, > > designed and optimized over years) needs to be rewritten (this may be > > necessary because users feel the code could be more readable, faster > > or simply in order to a new "major" feature). > > > We never had problems with 1 and 2. The problems we have had were > > always due to 3, code rewrite. Whether it was a single function or an > > entire module. The problem with code rewrite is that there is some > > collective knowledge about the code to be rewritten and no individual > > has the same knowledge about all the details. For example a certain > > line of code may be written in certain way to make sure that it works > > on python 2.4 or to provide a certain obscure feature that is not > > documented (not even designed) but users have unknowingly started to > > rely on it. When code is rewritten people make sure that the new code > > behaves exactly like the old code in regard to documented features but > > that is not enough. New code should behave exactly as old code even > > (before new features are added) in all cases. That is very hard to > > test. > > > How do I handle this? If there is a minor code rewrite I test it > > myself and assign somebody to look at it. If the code rewrite is > > major, I keep it in a separate file (dal.py intead of sql.py and > > template2.py instead of template.py) and ask people to run web2py with > > the new module instead of the old module. We do not branch web2py > > because small (and safe) features and bug fixes are being added to > > web2py that do not interfere with the rewrite. > > > What can we do? 1) we should have more unittests; 2) we should lock a > > release for one week before releasing and allow people testing it; 3) > > we should keep track of how many people are using the release > > candidate. > > > Some people think that unittests fix all problems. That is not true. > > Consider the case of the rewrite of the template module. The new > > module worked almost identical to the original one (except for the new > > features) with one caveat: It changed the way application bugs were > > going to reported in the ticket. How do you write unittests for > > application bugs? It is possible but very time consuming. Even if the > > code has been in the nightly built for two weeks and even if emailed > > other developers for checking it, some of the issues did not come up > > because web2py developers tend not to introduce bugs in their > > application code and therefore they did not notice the differences in > > how errors were reported. Only once released to the general public the > > problem showed up. The problem was identified and fixed in 24 hours. > > Unfortunately some of the new features introduced in the rewrite had > > to be reverted and their release postponed pending more testing (now > > that we know what to test). > > > Massimo > > I used to work for a big company for a big product, therefore kind of > knew how difficult to maintain a product with many branches, in the > traditional way, a.k.a. new features are only added into trunk, and > each release is tagged and forked as a bugfix-only branch. > > Now I would like to say, web2py uses a completely different approach, > that is "no need to branch", therefore do not have problems when > people would work on different branches. Thanks to web2py's stable API > from the beginning (awesome job, Massimo), and the promise of backward > compatibility. > > Unittest surely can not prevent all problem, but I think we are now > doing less than enough, rather than overcooked. Most features are > testable but still without test cases. I admit sometimes it can feel > boring and time consuming to write test cases, but it is still worthy > if you believe test cases should be considered a valuable part of > source code and it pays off when doing TDD or recursive test after > refactoring. Ok, ok, enough preachment here. :) > > Locking a release (candidate) for one week before releasing and allow > people testing it, is the way python doing. It should work as long as, > enough people, even those who would not update his work copy > frequently, are willing to response to the call of "Uncle M" saying "I > want you to test web2py RC-1.x" > :-)http://blogs.gnome.org/dcbw/files/2009/03/unclesam.jpg > > Let's keep making web2py better! > > Regards, > Iceberg
