What about defining some milestones where new features are assigned? Once a milestone completes freeze and branch on that branch bug squeezing is done and tags for stable releases. Meanwhile the trunk starts traveling to the next milestone.
I think whatever solution we find, Massimo needs to be relieved and not aggravated with more tasks :D 2010/8/21 Phyo Arkar <[email protected]>: > So thats mean during 1.84.1 - 1.95.1 new features which will need a patch to > web2py-core will be freezed and those wont need to touch web2py-core will be > put into experimental? > > On Sat, Aug 21, 2010 at 11:44 PM, mdipierro <[email protected]> wrote: >> >> How about we start testing with 1.84.1... and release 1.95.1 and the >> end of the testing period? >> >> On Aug 21, 12:00 pm, Phyo Arkar <[email protected]> wrote: >> > > 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 >> > <[email protected]>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. >
