[ros-dev] Development process - once again
aleksey at reactos.org
Sat Jun 7 12:45:15 CEST 2008
this question seems to arise periodically, so let's have a
constructive discussion again about the issue once again.
The issue is being that a lot of people have direct commit access to
the repository, and sooner or later some of them commit patches which
introduce a regress in functionality.
I will use Magnus (GreatLord) again as an example. He was doing a
good thing (as usual), but then somehow lost focus, and along with
good fixes committed a breakage for FF2.0 installer (and all other
apps using PatBlt functions). I had to (as usual!) spend the whole
morning reviewing all his diffs, then regress-testing by bisection to
find the guilty revision, then work out a better solution with him,
and then come to agreement that the guilty commit could be just
reverted for now, since it partly works anyway.
This takes up significant amount of my time, which could go into
something more productive than just testing patches, finding way to
unregress, and so on.
Especially I'm angry about this happening right when approaching
Ideally (as I explained in #reactos today to blight_), I want the
trunk itself be directly committable only by a very limited number of
persons, and all developers should be committing to "some other
place" at first, and then their patches merged by reviewers/testers
(yes, manually, sometimes just reviewing may be enough to commit/
reject the patch, sometimes a thorough testing must be involved,
maybe additional devs asked for a review).
blight_ called this as a "linux development model" with an
intermediate branch - yes, maybe, why not?.
What I definately don't want to do is to scare developers away and
make their life more complicated by need of sending text patches
(this is just not convinient, and as seen on the example of Wine
makes a lot of possible contributors going away).
I remember what Alex proposed (those who don't, may look up ros-dev
ML archives with a similar topic).
Would there be any new prepositions? Maybe someone discovered a new
CIS for SVN, or a decentralized VCS for patch submission and usual
SVN for maintaining HEAD?
With time, developers number is only going to increase, so this
problem will become more and more annoying.
With the best regards,
More information about the Ros-dev