> On May 22, 1:56 pm, b00m_chef <r...@devshell.org> wrote: > > Learn from the best on how to manage a release > > cycle:http://www.youtube.com/watch?v=i7pkyDUX5uM
On May23, 9:17pm, mdipierro <mdipie...@cs.depaul.edu> 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
