i would suggest to start testing in real hardware too.... On Tue, Feb 15, 2011 at 5:38 PM, Aleksey Bragin <alek...@reactos.org> wrote:
> You don't get it, because the procedures are incorrect and it's a drift > away from the actual topic: I suggested starting our usual release process > from the current trunk now, because otherwise there will be no fresh release > for the coming CLT-2011 event in March. > > Quoting Ged's email from 11 Oct 2011 to this list ("Re: [ros-dev] ReactOS > development cycle"): > > A stable trunk should be an ongoing battle, not something reserved for > release time. > > There shouldn’t be more than a weeks worth of release work required (the > release itself is no more than a few hours work). > > ... It’s a tried and proven method used in most large open source > projects and reactos is no exception > I fully agree with that, because it makes it easier for the opensource > project to progress. > > Now to the actual proposed procedures, which I can't find being anywhere > near correct, and I explain why: > Patches should be applied as soon as possible, there is no need to wait for > a feature freeze announcement (points 1 and 2 in the Timo's list). Then, if > a patch adds some feature, it contradicts with the point 1 of the list. > Point 4 is also contradictive, high-priority bugs should also be fixed > right away, without waiting for lower priority patches to be reviewed and > regression solved in points 1-3. > Point 5 - "usability testing" is fully valid, yes, our testers do a very > good job at that. > > > WBR, > Aleksey. > > > > On Feb 15, 2011, at 1:04 PM, Ged Murphy wrote: > > I don't get it, Timo suggests some correct procedures to follow and it >> gets >> dismissed? >> >> >> >> -----Original Message----- >> From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On >> Behalf Of Aleksey Bragin >> Sent: 15 February 2011 09:35 >> To: ReactOS Development List >> Subject: Re: [ros-dev] Releasing >> >> Yeah sure, this is quite important, however as I said, we just had a >> "natural" feature freeze when only bugfixes were committed to trunk >> for about 2 or 3 weeks, and all new features went to the branches >> (with some exceptions, but still). >> Also, patches were reviewed and committed and as for regressions, >> previous release had even more, so there is a progress and positive >> view of the newcoming release. >> Usability test is also something which our testers do all the time >> when preparing a release, this includes testing golden apps etc. >> Victor could explain more on this topic, and I would really like >> testers to manage this kind of stuff and do some minimal quality >> assurance. >> >> Profit! :) >> >> >> WBR, >> Aleksey. >> >> >> On Feb 15, 2011, at 12:43 AM, Timo Kreuzer wrote: >> >> >>> I'd like to come back to this and suggest a procedure: >>> >>> 1. Officially announce feature freeze. >>> 2. Address patches in bugzilla. we have 31 patches in bugzilla and >>> we should have each of them reviewed and hopefully a lot comitted. >>> 3. Address regressions. We have 47 (!!!) bugs marked as regressions >>> in bugzilla. We should go through each of them and check if its any >>> reasonable to fix them. >>> 4. Address bugs with high severity / high priority. (5 blockers, 9 >>> critical, 50 major... doh!) >>> 5. Do a "usability test". This means installing and doing the usual >>> stuff, a user would do and note all problems, annoyances. Currently >>> ros crashes very often with failed assertions and other stuff. If >>> we ship this in a release, people will be very disappointed. so we >>> seriously need to improve the situation. >>> 6. ??? >>> 7. profit >>> >>> Timo >>> >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > 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