> > I think whatever solution we find, Massimo needs to be relieved and > not aggravated with more tasks :D >
Yeah thats true , but all the bug hunting , stress and stability testes should be focused by us(community) On Sun, Aug 22, 2010 at 1:45 AM, Michele Comitini < [email protected]> wrote: > 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. > > >
