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