Taras, On Tue, Sep 14, 2010 at 9:54 AM, Taras <ox...@oxdef.info> wrote: > Andres, > > minus w3af-users@ list > >> >> At some point I thought that having a branch for a stable release was >> >> a good idea... but... people want new features also... >> > New features must be correctly implemented and *tested*. >> > W3AF has a lot of features and a lot of LOC (lines of code). It is big >> > project. >> > As I think it will be difficult to maintain and develop it in the future >> > without any separation >> > in develop. >> > >> >> As I said in my >> >> previous email, lets make 1.0 the best we can, fix the major bugs, and >> >> stop trying to make a perfect "1.0" release. >> > Of course we will try to make it the best we can =) But it really strange >> > when on >> > RC stage there are a lot of new code in trunk. It will make new bugs more >> > and more. >> >> Something we've been lacking since the beginning is a good regression >> testing framework. The good news is that Rapid7 will contribute to the >> project with several hours a week of a QA tester that will implement a >> regression testing framework for both w3af and NeXpose. With that, >> we're going to be able to identify old bugs, fix them, and make sure >> that introducing a new feature doesn't break what we already have. >> >> This tester, together with the power of the community, will enhance >> the quality of the framework. > > Separate QA tester is of course good news and I like it! :)
:) > But in the root (I hope there is such expression in English:) hehe, I don't think so, but we all get the idea! > it is not enough to solve problem of release stability. This tester will find > a lot of bugs after new code will be added to the trunk and then we will need > to fix them on RC stage. It is bad > practic to add new features on RC stage. I think that we should follow the scrum methodology, in which each sprints delivers a piece of software / enhancement that's ready to ship and adds value to the product. With this in mind this is how it will work: - Sprint starts - Developers think how to solve the problem - Tester thinks how to test the developers solution - Developers create code - Tester creates tests - Developer commits code to the trunk (or a branch if the change is too big) - Tester gets the code from the trunk and runs scans against his test pages - Tester gets the code from the trunk and runs regression scans - Developer fixes regressions and bugs - Sprint ends [2 weeks after starting] > New code especially when it touches the core or simply has a lot of lines in > most > cases will bring bugs. It is the bad truth of development. I think that if we really stick to the above procedure, we shouldn't have any issues :) > From Wikipedia: > "The term release candidate (RC) refers to a version with potential to be a > final product, ready to release unless fatal bugs emerge. In this stage of > product *stabilization*, *all product features have been designed, coded and > tested through one or more beta cycles with no known showstopper-class bug.*" > > -- > Taras > http://oxdef.info > -- Andrés Riancho Founder, Bonsai - Information Security http://www.bonsai-sec.com/ http://w3af.sf.net/ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ W3af-develop mailing list W3af-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/w3af-develop
