Change Task Force
- 1 Change Task Force
- 2 source automatically formatted/beautified
- 3 commit to real repository after build finished successfully
- 4 continuous integration
- 5 outsource things to community
- 6 use checking software
- 7 force tests
- 8 introduce teams and persons in charge
- 9 list of hackfix-references
- 10 cross-reference
- 11 automatic generation of data files
- 12 set of developer tools
- 13 code cleanup
- 14 file/code templates
- 15 continuous compatibilty checks
- 16 new build system
- 17 Double Bugzilla ticketing
- 18 Auditing
- 19 ReactOS contributors beneficts
- 20 University Contacts
Change Task Force
I would like to discuss following things to bring more benefit to the development process of ReactOS. Please bear in mind these are more or less useful ideas, I know some doesn't suit well! Constructive comments/remarks/suggestions are appreciated. Feel free to add your ideas (but don't remove ideas you don't agree).
source automatically formatted/beautified
If we format/beautify our source code automatically on commit we can save the "code-formatting" commits and we ensure readable source code all the time.
- I have been using C:B's autoformatter from time to time, but I always had to manually fix things. I don't know if there's an automatic system that will give really good results all the time. It would also mix formatting into normal commits as soon as it was integrated. I think it would be enough to have some style rules and devs are encouraged to follow them. --ThePhysicist 22:47, 4 March 2009 (UTC)
- The Visual Studio autoformatter works really good, even on completely mixed up code parts. Christoph_vW suggested it some time ago and seems to be satisfied as well --grschneider 22:15, 5 March 2009 (UTC)
commit to real repository after build finished successfully
As long as the build of the whole system takes marked time on most of the developers machines, we should think about a two step model. Each commit to the main repository is made if and only if the build bot was able to create a build successfully. Apart from that we should think about a way to prevent builds for special cases on request.
- I would support either this or auto-revert after built-breakage. --ThePhysicist 22:50, 4 March 2009 (UTC)
We should discuss, if we would like to apply some more steps to make a better release cycle based on the model of continuous integration.
outsource things to community
At the moment the developers have to make some work, that can do almost everyone. I suggest to make some selected things available to the whole community to relieve the developers. In contrast to Klemens Friedl I don't think we should start with a web interface for resource files translation (because the results can break build), but i think we can start with some simple translations and additional data. The interface has to ensure that users can't break build. Examples:
- timezone names, settings (some DST change yearly)
- country names, GeoID, region info
- NLS data
- Device related strings (INF-Files)
use checking software
Maybe we can use automatic checkers to gain the quality (splint or some similar). This needs some research to find proper ones.
Apart from wine, we should force to make more tests. I personally haven't an idea how to do that in an appropriate way, but I think it's necessary to increase the quality and power of the system.
introduce teams and persons in charge
As long as everyone works everywhere, I suggest to define virtual teams. The teams should feel responsible for paths or files. Responsible in the meaning of "contact person". If another developer would like to apply patches or make some changes and has problems then he/she has a person for his/her questions. In fact no file/directory should be left alone (so we can also define which parts are indirectly maintained by wine or another contributer outside the project). Maybe we can add a special file to each directory which contains at least following fields and can be processed by scripts:
- contact person/person in charge
- virtual team members
- deviate rules
list of hackfix-references
Due to the overwhelming task to build a windows compatible operating system we have a lot of hackfixes to make it work "as it is". To get back the overview of outstanding tasks due to hackfixes (in the meaning of "not a proper solution for the problem") I suggest to make lists for dependencies (how to do that needs further discussion). We should be able to find out (quickly) which hackfix needs which unimplemented feature. If we can make such list, we are furthermore able to set a priority for unimplemented things and we can remove the hackfixes step by step (in a more coordinated way).
- Wow... half of win32k is a big hackfix. Or better few hackfixes on top of earlier hackfixes. A stack of hackfixes. I don't know if it even has a design in some places ;-) To make life much easier: "win32k is not yet a proper solution" --ThePhysicist 00:44, 5 March 2009 (UTC)
The doxygen source reference seems to have some problems because some data types and functions are unknown, I strongly recommend to fix this, because we can find things much faster and we can mark deprecated things.
automatic generation of data files
To save more time I suggest to introduce a set of rules how to automatically generate some special data files (e.g. INF-files) or at least parts of it. We should think about an additional script language to create some stuff automatically.
set of developer tools
As mentioned before we should provide at least on supported script language to gather tools from devs for devs (e.g. I use may own autopatch to apply simple patch files directly from bugzilla to working copy). With such tools we can make our life easier and each developer can decide for him-/herself to use it.
I strongly recommend to discuss code cleanup. When, who and how?
What do you think about a template library for recuring tasks?
- What do you want to put into template files? I don't think we have so much code that is the same as other code. If you are writing new code that is similar to some existing code, just copy & paste what you need. --ThePhysicist 23:18, 4 March 2009 (UTC)
continuous compatibilty checks
As part of our testing procedure we should force continuous compatibilty checks for selected programs (but periodically). Maybe this part can transfared to community, we make a simple survey and the testers can fill in the results. This results can help us to decide how to proceed...
new build system
As long as almost all developers think a new build system is a good idea, I strongly agree with the argument: Let's maintain the build system by the community and don't bind human resources of ReactOS developers.
Double Bugzilla ticketing
Actually fulfilling a Bugzilla Report needs advanced skills about Components(Documentation,Drivers,Kernel, Networking..),and skills to obtain a useful debug log. So in Bugzilla you can find now a mix of non-useful reports with really good ones. Maybe having a Double ticketing(a comfortable Bugzilla design for Users and the actual for just Testers/Developers) would increase the number of bug reported and would clean the reports in the second ticketing. (This is a mix of Vicmarcal and KJK ideas) --Vicmarcal 14:47, 5 March 2009 (UTC)
Or we could encourage them to consult us first before filing a report. no effort needed, and most of us who aren't devs don't spend time on much else in the evenings anyway. --Lone Rifle 20:19, 5 March 2009 (UTC)
Problem is that they dont come to forum or to IRC before posting but they directly go to Bugzilla.Also they find an ugly/odd/non comfortable Bugzilla(which can discourage people also)...and they think that a screenshot of a BSOD is enough for us :) --Vicmarcal 22:11, 5 March 2009 (UTC)
Then we should encourage them to get to the forum and other channels first instead. -- Lone Rifle 14:21, 6 March 2009 (UTC)
We encourage them to do that..but with no results.Just look how many Bugzilla reports has the answer: look our wiki before posting bugs.--Vicmarcal 22:11, 5 March
Because people usually do not have the patience to read the wiki in the first place. Talking to somebody is usually seen as easier, since there is less information to digest in one go, as there are delays between people responding to each other. If anything, I would suggest that using a forum as the "Bugzilla staging area" would probably make for a good compromise; you get the benefits of attending to the user in your own free time and you don't need to set up a second Bugzilla. This has the added benefit of absorbing the people who seem to like posting bug reports in the forum. The main Bugzilla can then be used to report the underlying cause of the bug, with the usual additional info such as testcases, debug logs etc. -- Lone Rifle 17:32, 6 March 2009 (UTC)
Auditing code each 5-10 years of a trunk image (without stopping commits to the real trunk) would help to find support from Companies because it will increase our credibility and gives to the Company an argument/shield to support us. --Vicmarcal 14:49, 5 March 2009 (UTC)
ReactOS contributors beneficts
Most of the companies values proactive workers.ReactOS contributors(Devs,Translators,Testers or any other who contributes here) should have the possibility of asking for a ReactOS Foundation Collaboration Certificate which states in a legal way a proactive work in an Open Source Project. Including ReactOS Contribution in the CV is optional but highly recommended. --Vicmarcal 16:27, 5 March 2009 (UTC)
In most of the Universities in Europe all the students in their last year have to make a Project fo finish their careers. ReactOS could provide a list of small tasks (==searching bugs,fixing some of them,making some documentation,implementing easy functions...) to any University interested on helping Open Source projects. This could lead some of these students to become Devs in ReactOS. --Vicmarcal 16:31, 5 March 2009 (UTC)