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
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.
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.
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 (e.g. INF-Files, Timezones, Geographical Positions aso). The interface has to ensure that users can't break build.
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 inderectly maintained by wine or another contributer outside the project)
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).
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 automtically.
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?
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.