> > I think so, as long as the terms are clear. In particular, it should be > clear how the experimental features would move to stable (perhaps just a > time limit on the stress test, or some more specific condition). > how about this? Lets say , during 4 weeks of bug-squishing period , all expermental features will be also tested for bugs , if they exist they will be report to the contributor of that feature , if the contributor or anyone send the patch(and if contributor statify the patch if some other fixed) , that feature will be included in main-stream , else they will tagged exprimental.
how about that sounds? it should be exercised at every Stability level versions. lets say every x.x5 (1.85 for example but any number that massimo wish) . As web2py is aimed for Enterprise level , this should make development look and feel "Enterprise". On Sat, Aug 21, 2010 at 9:15 PM, Jonathan Lundell <jlund...@pobox.com>wrote: > On Aug 20, 2010, at 2:40 PM, mdipierro wrote: > > > I see a lot of value in > > > > - bug-squishing-contest , > > - Stress test, Test everything , try to crash web2py etc. > > - fix bugs, fix performance issues , improve performance > > - code cleanup , documentation. > > > > we can set deadlines for that. This means we would stress test and > > improve features existing at a certain date and we would only add new > > features tagged as "experimental" that do not interfere with parts > > that are being stress tested. Makes sense? > > I think so, as long as the terms are clear. In particular, it should be > clear how the experimental features would move to stable (perhaps just a > time limit on the stress test, or some more specific condition). > > Perhaps in going through an exercise like this, we could also think about > something like it could be incorporated into the normal development cycle, > on an ongoing basis rather than as a one-shot project.
