[ros-kernel] New development model

[Casper Hornstrup]

> -----Original Message-----
> From: ros-kernel-bounces at reactos.com 
> [mailto:ros-kernel-bounces at reactos.com] On Behalf Of KJK::Hyperion
> Sent: 18. marts 2004 18:03
> To: ReactOS Kernel List
> Subject: Re: [ros-kernel] New development model
> 
> 
> >Making changes
> >--------------
> [...]
> 
> This is the part I don't understand a lot. And what I do 
> understand looks very complicated to me. Let me see: what we 
> currently do on HEAD, in this model should be done on a 
> branch, right?

HEAD is an ordinary branch like any other branch. So there is
no difference there. HEAD in CVS is analogous to trunk in
Subversion.

> And before changes are allowed into the trunk, 
> they must first be moved to the equivalent check-in branch, 
> yes?

Yes. The changes should be checked into a branch that is a mirror
of trunk (almost).

> How is this done by the developer, in practice?

We'll have to do some experiments to figure out the best way to do
this.

> can we have a test server? because it's quite a jump

Sure. I was thinking we could have a separate repository during
development of this system that interrested developers could try
To find out what works and what does not work.

> 
> Another question: are branches supposed to be permanent (e.g. 
> "GUI", "Networking", etc.) or volatile? because if they were 
> permanent they could be associated to mailing lists, so all 
> developers interested in the branch would get messages on 
> commits, regressions, etc. in said branch

We don't use multiple branches now, but they could certainly benefit
us in the future, so the model should support multiple branches.

> 
> >   A) Commits are serialized. No other commits are allowed 
> during the 
> > time it takes for the continuous integration system to checkout, 
> > build, run tests and revert a change or merge it to a 
> stable branch. 
> > This solution does not scale very well and may frustrate developers.
> 
> wouldn't more granularity in defining branches fix this?

I'm not sure what you mean. Please elaborate.

> 
> >All further commits that will modify one or more read-only files or 
> >directories will be aborted and the developer will have to 
> commit his 
> >change later when the continuous integration system has finished 
> >processing the previous change.
> 
> couldn't the system parallelize integration of unrelated 
> (i.e. applying to disjoint sets of files) changes and 
> serialize the others?

Yes it could. Since the changes would not touch the same files and
directories, the changes could be processed in any order and thus in
parallel.

Currently a 2.4GHz linux machine can build ReactOS in about 10 minutes.
Fetching ReactOS from the repository is about 10 - 15 minutes, but an
integration machine could fetch only deltas. Running tests is currently
a few minutes. Of course it takes longer if integration is to be
performed for several configurations of ReactOS. Say it takes 30 minutes
to complete integration. Then one machine could process 48 changes in 24
hours. To speed it up the integration system could use oportunistics. If
there are 20 changes on a checkin branch then a machine could try
combining the 20 changes and integrate them all. If successful, the
integration system just saved itself about 9.5 hours of work. If not,
then it could try with only 10 changes out of the 20 changes. If the
integration system is unlucky and we feed it many bad changes then it
could actually take longer to integrate the 20 changes this way than 
doing it one at a time. Some experiments will need to be done to figure
the best way to do this.

> I can also see a web-based (or 
> RPC-based, as IIRC Subversion is based on SOAP) interface 
> with informations about the wait queue for the test queue as 
> an useful addition to monitor the progress of check-ins (and 
> maybe cancel them too) in real time 

Subversion use DeltaV + WebDAV for it's network protocol. It also
use it's own alternative protocol when using it's standalone
daemon. See http://www.webdav.org/deltav/ for more information.

Casper