3 Oct
2007
3 Oct
'07
1:08 p.m.
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