Re: [ros-dev] ReactOS Development Process

[Aleksey Bragin]

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?

[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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Ged]

Alex Ionescu wrote:

>   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). 
Just to note, the only reason the MmInit1 changes wern't quick to find was
that buildbot was down for some obscure reason.
If buildbot had been running (as it normally is), we would have imediatley
spotted that 2nd stage was broken via the system regression tool, which is
now incorporated into buildbot.

As it happens, the first time our sysreg tool was required, buildbot was
down so we couldn't make use of it.
Sods law .... or maybe we could blame Christoph ;)

Ged.


















This message contains confidential information and is intended only for the individual
named. If you are not the named addressee you should not disseminate, distribute or copy
this e-mail. Please notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be
guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does
not accept liability for any errors or omissions in the contents of this message, which
arise as a result of e-mail transmission. If verification is required please request a
hard-copy version. 

Amteus Secure Communications Ltd
57 Cardigan Lane,
Leeds, 
LS4 2LE
t: [phone]
f: [phone]

Registered in England No 4760795

http://www.amteus.com

[Timo Kreuzer]

Ged schrieb:
>   If buildbot had been running (as it normally is), we
> would have imediatley
>  spotted that 2nd stage was broken via the system regression tool, which is
>  now incorporated into buildbot.
>     
The problem is the regression testing also doesn't work ...

Timo

[Gregor Brunmar]

I just wanted to share what we did at my previous company:

We had a trunk branch, an intermediate branch and 5-10 different sub 
branches, each with its own sub focus of the code base (graphics, ai, 
etc). Ever developer submitted his/her change to a sub branch. Then on a 
round robin schedule, the lead developer from each branch took a day to 
merge the sub branch with the intermediate branch and sync the two and 
get it up and running.

Once a sub branch was merged with the intermediate branch, the testers 
began to test it. If the tests passed, intermediate was merged with trunk.

Problems that occurred was that some changed in the different sub 
branches was needed in another sub branch right away. Often this was 
circumvented by merging the specific change list into the sub branch 
that needed it. The whole system felt a little bit clumsy, but was there 
to not interrupt everyones work if someone made a commit that crashed 
the build.

Maybe too complicated, but just a real life example...

-G

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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>   
>
>