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?
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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: +44 (0) 870 8368770 f: +44 (0) 870 8368701
Registered in England No 4760795
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
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-
Aleksey Bragin -
Alex Ionescu -
Ged -
Gregor Brunmar -
Timo Kreuzer