Difference between revisions of "Change Task Force"

From ReactOS Wiki
Jump to: navigation, search
(introduce teams and persons in charge)
Line 24: Line 24:
  
 
== introduce teams and persons in charge ==
 
== 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)
+
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:
 +
* description
 +
* contact person/person in charge
 +
* virtual team members
 +
* deviate rules
  
 
== list of hackfix-references ==
 
== list of hackfix-references ==

Revision as of 13:22, 5 March 2009

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)

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)

continuous integration

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, time zones, geographical positions also). 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.

force tests

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:

  • description
  • 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)

cross-reference

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.

code cleanup

I strongly recommend to discuss code cleanup. When, who and how?

file/code templates

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.