I completely agree, it’s a problem that’s become more apparent in recent years.

You have to wonder whether it’s better to try and fix the root of the problem, or if it’s worth hacking around the problem by introducing less effective development models.

I’ve always been a supporter of the former, even though some of my ideas to tackle it haven’t always been popular with all the devs.

Ged.

From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Olaf Siejka
Sent: 11 October 2010 10:25
To: ReactOS Development List
Subject: Re: [ros-dev] ReactOS development cycle

I am sorry to point out that our devs (no pointing out) still fail to do something as simple as observing their commit on buildbot if it causes any problem. I`m not even talking about things more complicated, like not commiting again without first checking if previous commit was built fine. Also, devs do not check trunk status before commiting, they often commit when tree build is broken. All of this makes subsequent testing considerably harder, taking more time and let me remind you that we still have less active testers than active devs. This is just an example, straight off my mind. If we cant have such little, easy details sorted out, we cannot have an outgoing battle for trunk stability, as this value does not seem to be in any regard amongst ReactOS devs.

Regards

2010/10/11 Ged Murphy <gedmurphy@gmail.com>

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

Anything which jeopardises this should be done in a branch.

http://en.wikipedia.org/wiki/Release_early,_release_often

It’s a tried and proven method used in most large open source projects and reactos is no exception

Ged