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?
There are many possibilities, however all of them assume more or less an overhead, and need additional human resources. I will outline one suggested method, and want you (developers) to "constructively criticize it", improve it, or offer a better method. Even if it involves changing current version control system, or anything - suggest the method.
So, the suggestion I've already got is this: Trunk is writable only by a so-called Integrator person (maybe a few persons). Branches are writable by a big amount of developers. Typical development process is as follows: 1. A developer creates a ticket in issue-tracking system (currently Bugzilla), where he describes what's wrong and what his change fixes/ improves. 2. He creates a branch with a name BZ-XYZ (where XYZ is ticket's number), and commits his changes there. 3. An integrator, daily, goes through all BZ-... branches, does svn merge to trunk of each branch, test it, if no regression occurs, he commits changes to trunk and svn deletes the respective BZ-... branch.
Some kind of integration system is definitely needed, so please avoid fast answers like "Let's stay as we do now". Better approach is needed, and I'm looking for it. If you can offer something - do so.
With the best regards, Aleksey Bragin.
Hi I think we should have something call stable trunk and devloping trunk
The stable trunk getting all changes that are ready and stable and it will be the release version of trunk.
the devloping trunk is where everyone working in
But the main problem is we do not have any good tools for regress testing and we are missing testcase for each api. I am working at moment writing testcase for gdi32, I hope this will make lest gdi32 allot more stable at end then I will start making testcase for win32k later maybe for user32 then start fixing the real bugs and implement things. or working with everthing same times. we should need a test kit for each api and test for evertging invaild param, pointers, and real data in all case I known it is not fun todo but that is what we need to make ReactOS more stable and less bugs. Testcase for everthing.
It would seem to me that a distributed version control system would be a much better solution. You could have the main ReactOS trunk and branches for releases etc... for the main tree you could control access however you like and individual devs could have whatever branches they like.
As for integration, you could have one test trunk which all the developers commit to, then each commit is tested and if it passes then the commit is merged with main trunk, failing commits have their revs removed (Bazaar has this functionality at least) from the test trunk along with a bug being opened and the patch sent to the bug.
This way you don't have all these branches to manage and a bug is only opened on a broken commit and devs really don't change anything about how they work.
There are a number of projects that could facilitate this fairly easily.
Anyway, just a couple of thoughts Regards Peter Ward
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?
There are many possibilities, however all of them assume more or less an overhead, and need additional human resources. I will outline one suggested method, and want you (developers) to "constructively criticize it", improve it, or offer a better method. Even if it involves changing current version control system, or anything - suggest the method.
So, the suggestion I've already got is this: Trunk is writable only by a so-called Integrator person (maybe a few persons). Branches are writable by a big amount of developers. Typical development process is as follows:
- A developer creates a ticket in issue-tracking system (currently
Bugzilla), where he describes what's wrong and what his change fixes/ improves. 2. He creates a branch with a name BZ-XYZ (where XYZ is ticket's number), and commits his changes there. 3. An integrator, daily, goes through all BZ-... branches, does svn merge to trunk of each branch, test it, if no regression occurs, he commits changes to trunk and svn deletes the respective BZ-... branch.
Some kind of integration system is definitely needed, so please avoid fast answers like "Let's stay as we do now". Better approach is needed, and I'm looking for it. If you can offer something - do so.
With the best regards, Aleksey Bragin. _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-
Aleksey Bragin -
Magnus Olsen -
Peter Ward