[ros-kernel] New development model

[KJK::Hyperion]

>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? And before changes are allowed 
into the trunk, they must first be moved to the equivalent check-in branch, 
yes? How is this done by the developer, in practice? can we have a test 
server? because it's quite a jump

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

>   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?

>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? 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