[ros-dev] ReactOS Development Process

[Alex Ionescu]

Herve's model perfectly models my solution.

However, you (and him) modified it by suggesting to delete the  
branches. I see no need to do this. This is SVN, not CVS, so those  
branches will barely take up any place (Deleting them will take up  
MORE space). It's also important to keep them around for accounting   
and replay-retest purposes.

I'd like to outline a bit more of what's behind my proposition (with  
or without Herve's automated improvements).

The first part is to use a bug tracking system (such as Bugzilla or  
Trac) as the core driving force behind each commit. Instead of making  
random commits and patches, everything must be accounted through  
BugZilla/Trac. I shall start with the case where you want to  
implement a new feature.

A new feature is still a bug, because it's something that ReactOS is  
missing. Therefore, file a bug on it, and attach the patch for your  
feature.

Then commit your patch to (what you believe is) trunk, along with the  
BZ reference number. At this point, the hook will create BZ-XXXX and  
this will be your branch with the patch.

You now go to Bugzilla, edit the bug report, add the URL to the  
branch, and mark the bug as RESOLVED FIXED.

This also means if anyone has any issues with the feature, or  
problems using it, they can chain off that bug and leave a paper trail.

Now, every developer will also do this on their own. At the end of  
the day, we'll have, let's say, 20-30 average branches. Trunk itself  
will still be the old trunk. At this point, someone, or something,  
needs to go through each branch, one by one, and attempt applying to  
trunk. If there's any problems whatsoever, just drop the patch.

This is a major improvement over going through trunk entirely at the  
end of the day, because once that's done, it's extremly hard to find  
a broken revision, and requires going through each one by hand (just  
like the MmInit1 changes this week, for example). By doing it branch- 
by-branch, it allows someone/something to easily know what's  not  
working, and to simply skip it so that patch can be fixed later. It's  
very rare that someone's patch would work on its own, but break once  
another patch is in the system.

Once a break is detected, except from not being integrated, the  
Bugzilla bug report should be reset to REOPENED along with relevant  
information/logs about the broken patch.

At the end of the day, trunk is now the sum parts of everyone's  
commits which work.

The only job the developers have to do is start using BugZilla, which  
really, is like saying "Humans now have to breathe". I know for a  
project like ReactOS this may seem like heresy, but it's time to  
"grow up".

It's important to realize under this model there should be NO commits  
without a bug report attached to them! I outlined the scenario for a  
new feature, but for a bug fix, the same applies. You notice a bug,  
you file a report, etc.

In my next e-mail, I will outline the plans for release management,  
once Aleksey has sent his.

--
Best regards,
Alex Ionescu

On 3-Oct-07, at 5:28 AM, Aleksey Bragin wrote:

> Herve suggests using a kind of a continuous integration system,
> describing it this way:
>
> * precommit hook
> if commit not to trunk, abort precommit hook
> create a REV-abc branch from trunk and do the commit here
>
> * regularly
> go through all REV-abc branches (increasing ABC numbers)
> test it
> if not, inform user or whatever that test failed and go to next branch
> try to merge to trunk
> if not, inform user or whatever that merge failed and go to next  
> branch
> commit to trunk
> delete the branch
> go to next branch
>
> * pros:
> devs and users will have new version to trunk once they are tested
> devs and users only have to know trunk
> * cons:
> changes are not immediatly available for everyone, except in REV-abc
> branch
>
>
> On Oct 3, 2007, at 12:50 PM, Aleksey Bragin wrote:
>
>> 	Hello,
>> recently, different people raised a question: How should development
>> process evolve with time, when ReactOS has more (much more)
>> developers willing to contribute code?
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev