Let me explain what we do now because it has some similarities with what described in the video below.
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 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 May 22, 7:31 am, mdipierro <[email protected]> wrote: > > > I am very much interested in this. We may even find a couple of $100 > > to pay for some security testing of web2py. Let me know what we need > > to do. > > > Massimo > > > On May 22, 8:53 am, GoldenTiger <[email protected]> wrote: > > > > Well, I have been working for years as security auditor and etichal > > > hacking. Last years I decided focusing at more creative works and I > > > started personal projects. > > > I can do tests against web2py, no problem, but first I want to > > > understand the framework as well as possible. > > > a friend of mine who audits banks web and networks is interested in > > > python frameworks as I said him, so they could be a good help > > > In my opinion, the most important thing in secure software is the > > > design and the logic, ( microsoft declared some windows desing flaws > > > as a not possible solution) > > > since web2py was designed 100% before implemention, I can say that > > > web2py is probably one of the most consistent frameworks today > > > :D
