The only time I've ever seen this work is with OpenBSD - but that's because they do a strict six-monthly release schedule, with set periods of time hacking away, set periods of time testing things, and set periods of time finalizing the release. Any new features that doesn't make it into the (I think it's 4 months?) hacking period just doesn't make it. In other words, auditing is very strict there; that's hardly what I could say for other projects. And fair enough; it's a huge job!
And some of the big rewrites aren't even enabled/in the main tree until years later! Quick releases work the way you are talking about *in theory* - while in practice (at least, here in ReactOS that is) I have noticed a lot of "Oh we're waaaay past the deadline dude. Let's like, you know, leave this big regression till the next release, man." - in other words, great in theory, but rarely practical and benefits are either negative, or negligible. The MM rewrite was an example. Now that's been pushed to the next release. (correct me if I am wrong) - it was going to be released with 0.PI before. On Sat, 25 Feb 2012 11:57:57 +0000 Andrew Faulds <ajf...@googlemail.com> wrote: > Quicker releases have the benefit that it forces us to fix lingering > regressions and release. Otherwise regressions and significant bugs > pile up until release and we have to spend months fixing them. > > On 25 February 2012 04:00, Adam <geekdun...@gmail.com> wrote: > > "Faster release cycle is better" is what a bunch of idiots at > > Mozilla Corporation said. > > And now their browser has begun the process of becoming more > > bloated, much slower, and contains more and more useless rubbish and > > "features" with every release, while the competition (including > > Internet Explorer) is excelling on simple and useful things, such > > as a UI that doesn't randomly freeze solid every five minutes. > > > > I strongly oppose this "faster release cycle" unless it means simply > > tagging a TRUNK build that "just works" as a release and releasing > > without doing anything further, apart from maybe the occasional > > bootscreen/login screen change to reflect the version number. > > > > If you want to try new features, use a trunk build. > > > > Quick release may actually *reduce* the interest in ReactOS when > > people try the "stable" builds only to find that it is a lot > > buggier because of the absurdly limiting deadlines, and so few > > final fixes could be made. > > > > On Fri, 24 Feb 2012 16:31:52 +0000 > > Andrew Faulds <ajf...@googlemail.com> wrote: > > > >> Good! Let's proceed with 0.3.15... a faster release cycle is > >> better, and will help interest in ROS as people will be able to > >> see clearly that progress is being made (as opposed to appearing > >> to be stagnant to those who do not look at trunk). > >> Plus, I want a "stable" release to try some new features ;P > >> > >> On 24 February 2012 11:49, Amine Khaldi <amine.kha...@reactos.org> > >> wrote: > >> > February 2012 Meeting Minutes > >> > > >> > 2012-02-23 > >> > 19:45 UTC > >> > Fezile, #meeting > >> > > >> > Proceedings > >> > =========== > >> > * Meeting started at 19:45 UTC by Aleksey Bragin. > >> > > >> > * Point 1: Release status: 0.3.15 > >> > --------------------------------- > >> > * Aleksey Bragin proposed that we prepare trunk and release > >> > 0.3.15, as it is now, before anything major happens. Several > >> > members then wondered about the status of USB and the "mshtml > >> > bug". Jerome Gardou explained a bit about how the mshtml bug is > >> > far from completely being fixed, because if you look at > >> > testbot's results, there are still some problems with ASSERTs > >> > hit and some bad pagefaults happening when paging out. > >> > * A lengthy discussion occurred, about how ready trunk is, > >> > whether it's in a better state than 0.3.14, the state of the > >> > theme to be bundled with ros, the plan for CLT, whether we > >> > should go 0.4<something> or 0.3.15... This was settled through a > >> > voting: "Do you agree to release 0.3.15 with current trunk > >> > features, before CLT?". > >> > * The total number of votes was 21, with 11 votes as Yes, 5 as > >> > No, and 5 abstentions. As a result, we will be having a 0.3.15 > >> > release with CLT being the deadline. > >> > > >> > * Point 2: New website status and migration plans > >> > ------------------------------------------------- > >> > * Amine Khaldi gave a quick summary on the state of the website > >> > revamp: > >> > - Quite some progress has been made in the theming department, > >> > and it's visible from the playground. It's starting to look a lot > >> > like the current one, which means it's almost done (only some > >> > issues are left). > >> > - Maciej Bialas has been investigating how to import users from > >> > the RosCMS. We will most likely need to compromise: members will > >> > have to reenter passwords when we migrate, but we'll see. > >> > - Amine Khaldi then mentioned that we need help from web devs > >> > familiar with Drupal. Alexander Rechitskiy mentioned that he has > >> > a guy that wants to be part of the web team, and he passes his > >> > info to Amine to establish the contact. > >> > - He also mentioned that Maciej is very busy, so the progress > >> > will slow down, and that the current short term plan is to > >> > continue the theming work, provide a way to import users, import > >> > the rest of data from wiki/bugzilla...etc and finally add the > >> > phpbb bridge. > >> > * He then summarized the summary by saying: We needs skillful > >> > drupal guys, we're almost there, and that's it. > >> > > >> > * Point 3: CMake migration and finally abandoning RBuild > >> > -------------------------------------------------------- > >> > * Amine Khaldi suggested that it's time to ditch rbuild, as he > >> > suspects most of our members have migrated already. Agreement on > >> > that, from ours members, was unprecedented as *everyone* were on > >> > favor of this :) > >> > * We agreed on doing the necessary commits/infrastructure changes > >> > ASAP, ie "tonight" (relative to the meeting of course), but that > >> > didn't happen just yet so it's just a matter of time. Amine > >> > Khaldi wants to do the honors (the commit that will remove > >> > rbuild and its related files). > >> > * Amine Khaldi also mentioned that he's preparing a nice little > >> > surprise for major build performance boost, on many levels, so > >> > stay tuned guys ;) > >> > * Jerome Gardou explained that he'll be handling the PCH support > >> > to get it to a much better state than it is right now. > >> > > >> > * Point 4: Added per Amine Khaldi's request: GSoC preparations > >> > -------------------------------------------------------------- > >> > * Amine Khaldi explained that he created a Google Doc and invited > >> > the interested members. He asked the members to collaborate and > >> > shape up an excellent ideas list, projects that fit in GSoC at > >> > both the time and complexity levels. > >> > * Colin suggested building up on the last year in terms of > >> > informative content (wiki pages from last year), covering > >> > questions about how we deal with students, our application > >> > form... etc. > >> > > >> > * Meeting closed at 21:45 UTC by Aleksey Bragin. > >> > * Minutes written by Amine Khaldi. > >> > > >> > _______________________________________________ > >> > Ros-dev mailing list > >> > Ros-dev@reactos.org > >> > http://www.reactos.org/mailman/listinfo/ros-dev > >> > >> > >> > > > > > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev@reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > > > _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
