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