Releasing

[Aleksey Bragin]

Hi,
recently amount of new features added to the trunk decreased, and  
there were quite a lot of bugfixes coming in. In my opinion, it is a  
very good time for a release. After release is branched, it would be  
possible to sync wine shared code and continue with other changes.

If there are no objections, let's start the work right away. Testers  
being the first team working, and Colin - when/if you have time for  
this release?


WBR,
Aleksey Bragin.

[Pierre Schweitzer]

Hi,

>   recently amount of new features added to the trunk
> decreased, and  
>  there were quite a lot of bugfixes coming in. In my opinion, it is a  
>  very good time for a release. After release is branched, it would be  
>  possible to sync wine shared code and continue with other changes. 
Agreed.

Regards,
P. Schweitzer

[Olaf Siejka]

Please dont expect any work on ReactOS testing of me, at least for the next
month. Tough time at work/school plus switching to new lappy, plus short
schedule of returning the old one (which i used for ReactOS related tasks
extensively) plus few more things. Remnants of my spare time are going into
Buildbot scripting and basic bugzilla maintenance.

It would be nice if at least Heap asserts are fixed for the new release. If
i may ask for one more miracle - then it would be the registry corruption,
that we noticed on testcd running, with Smiley's crash window closing
patch.

Regards

2011/2/11 Aleksey Bragin <aleksey(a)reactos.org>

>   Hi,
>  recently amount of new features added to the trunk decreased, and there
>  were quite a lot of bugfixes coming in. In my opinion, it is a very good
>  time for a release. After release is branched, it would be possible to sync
>  wine shared code and continue with other changes.
>
>  If there are no objections, let's start the work right away. Testers being
>  the first team working, and Colin - when/if you have time for this release?
>
>
>  WBR,
>  Aleksey Bragin.
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Samuel serapion]

Hey all, just would like to remind everyone that we have a very critical
regression afecting the installation of msvcrt 2005 runtime
http://www.reactos.org/bugzilla/show_bug.cgi?id=5809

[Ged Murphy]

Sounds great, you definitely need to start building up publicity again.

Ged.

On 11 February 2011 22:02, Samuel serapion <samdwise51(a)gmail.com> wrote:
>   Hey all, just would like to remind everyone that we
> have a very critical
>  regression afecting the installation of msvcrt 2005 runtime
>  http://www.reactos.org/bugzilla/show_bug.cgi?id=5809
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Colin Finck]

Aleksey Bragin <aleksey(a)reactos.org> wrote:
>   Colin - when/if you have time for this
>  release? 
Sure, I have time.
We need a new release anyway for CLT in mid-March :-)


- Colin

[Timo Kreuzer]

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

[Aleksey Bragin]

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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Ged Murphy]

I don't get it, Timo suggests some correct procedures to follow and it gets
dismissed?



-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] 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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 

_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[Michael Martin]

For some reason I didn't get Timo's or Aleksey's emails to mailing list.
Anyway Timo's suggestions sound good. Ill should have time starting tomorrow 
for looking at bugs.

mike

>   From: gedmurphy(a)gmail.com
>  To: ros-dev(a)reactos.org
>  Date: Tue, 15 Feb 2011 10:04:14 +0000
>  Subject: Re: [ros-dev] Releasing
>  
>  I don't get it, Timo suggests some correct procedures to follow and it gets
>  dismissed?
>  
>  
>  
>  -----Original Message-----
>  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] 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(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Aleksey Bragin]

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-bounces(a)reactos.org [mailto:ros-dev- 
>  bounces(a)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(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Javier Agustìn Fernàndez Arroyo]

i would suggest to start testing in real hardware too....

On Tue, Feb 15, 2011 at 5:38 PM, Aleksey Bragin <aleksey(a)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-bounces(a)reactos.org [mailto:[e-mail]] 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(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev
> > >  
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Timo Kreuzer]

Ahh, it cannot be, what must not be?

<sarcasm>
Lets not apply patches now, so that when we enter the regular 
development phase everyone can deal with them as usual: happily ignore 
them. I'm sure they'll be outdated sooner or later anyway, so we don't 
need to apply them at all.
Lets not fix high priority bugs, because if they are not fixed already, 
they can't be of high priority, amirite?
And about regressions: When they are not fixed by now, they are probably 
worth keeping them for the next release.
Lets instead do nothing, branch and release right away, because trunk 
boots, that should be enough.
Or lets do some wine syncs before, maybe that fixes some of ours bugs.
</sarcasm>

Seriously, the situation simply isn't the way you'd like it. That means 
we need to encourage devs in certain phases to do bugfixing and patch 
comitting instead of the stuff that they would usually prefer working 
on. Before a release is probably the best time, since open development 
aka rewrites & co should be on hold anyway.

But as you like it. I can go on with MSVC fixes for the rest of the 
month ;-)

Timo

[Olaf Siejka]

"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."

I stopped submitting new bugs some time ago, because i`m fed up while
observing them being starved to death in bugzilla. I might not have as much
time as others, hence i prefer to spend it on something that will provide
any added value to the project, like buildbot.

I`m glad the PATCH situation is bit better than through most of last year,
but still, as you can observe:

http://www.reactos.org/wiki/Bug_Filters#Patches

[Ged Murphy]

I still agree with my original email, but since

a) There's no 3 month release schedule anymore
b) Many patches in bugzilla get ignored
c) Bugs in bugzilla aren't dealt with as priority
d) It isn't stable at the moment, it asserts for me too.

then I don't think my email is tangible.

In an ideal world (as per the email) the points which Timo raised
would be dealt with on a day to day basis, but since that isn't the
case then I think Timo's mail is the next best method:
Stop heavy development (aka feature freeze), address
instabilities/patches/regressions, release, profit.


In honour of the Renminbi, just my 2 fēn's worth

Ged.



On 15 February 2011 16:38, Aleksey Bragin <aleksey(a)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-bounces(a)reactos.org [mailto:[e-mail]] 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(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev 
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Olaf Siejka]

This wasn't a proper feature freeze. Bugfixes were present, but in highly
specific areas, without the proper path:  bug reported->bug list
prioritized->tested-> passed to dev->fixed

We still suffer from system-wide regressions, heap and registry-related.

Best regards

2011/2/15 Aleksey Bragin <aleksey(a)reactos.org>

>   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(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[James Tabor]

On Tue, Feb 15, 2011 at 3:34 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote:
>   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). 
Locking trunk for more than three weeks is unreasonable, but just
stating no new features and only bug fixes without locking is okay.
Someone not on the list may have a bug fix craze and need to commit
ASAP!

>   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! :) 
More profit!
>  
>
>  WBR,
>  Aleksey.
>

[Pierre Schweitzer]

Hi,

>   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
>   
Are you suggesting devs should.... Work?!

Regarding path review, I reviewed patch for bug #5880 with its author, it's incorrect.
So, one less to review.

Regarding regression, bug #5641 has been assigned to me, as my commit revealed the bug.
BUT if the patch revealed the bug, it's not the patch itself which caused the bug.
Function is correct (regarding test cases). So anyone is free to take that bug. Don't
hesitate to bug "Caemyr" about it, IIRC, he looked at it.

For the rest, dont' hesitate to assign me bugs/regression you think I may handle.
I'll try to do my best about it. Can't promise more, sorry.

So, now, lock trunk :D.
And release!

Regards,
P. Schweitzer