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(a)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(a)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