Re: [ros-dev] Development process - once again

[Alex Ionescu]

Yes well, if you had listened to my idea, you would've avoided all this:

1) Magnus would've had to create a bugzilla bug report for the 'issue'  
he was 'fixing'
1<- At this step, someone responsible for win32k should've gotten the  
bug report, and maybe had time to reject the patch
2) Magnus would've had to commit his patch to the PR-xxx branch (Which  
would've been created automatically server-side, behind Magnus' back)
2<- At this step, trunk would still be fine
3) At the end of the day, the integration suite would find the  
regression in PR-xxx, and remove it from the mergeset
3<- At this step, everyone is aware that Magnus' patch caused a  
regression, and the patch was removed from the mergeset
4) The integration suite commits the latest mergeset
4<- At this step, everyone's patches are in, trunk still boots, and  
Magnus's patch is to be reviewed.

But of course, you stubbornly continue to go forward without any sort  
of codebase management...

On 7-Jun-08, at 6:45 AM, Aleksey Bragin wrote:

>   Hi,
>  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
>  0.3.5 release.
>
>
>  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,
>  Aleksey Bragin.
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 
Best regards,
Alex Ionescu