Difference between revisions of "Change Task Force"

From ReactOS Wiki
Jump to: navigation, search
m (fixed some typos)
(new build system: remove section)
Line 67: Line 67:
 
== continuous compatibilty checks ==
 
== 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...
 
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.
 
* I agree once again, but it looks like there is no very suitable one. Rbuild sucks less now, so I'm more or less ok with using it. Not sure about other --[[User:Fireball]]
 
  
 
== message board ==
 
== message board ==
Line 143: Line 139:
 
http://www.kumailht.com/blog/linux/10-features-ubuntu-should-implement/
 
http://www.kumailht.com/blog/linux/10-features-ubuntu-should-implement/
 
--[[User:Vicmarcal|Vicmarcal]] 22:18, 24 March 2009 (UTC)
 
--[[User:Vicmarcal|Vicmarcal]] 22:18, 24 March 2009 (UTC)
 
  
 
== ReactOS and Social Support ==
 
== ReactOS and Social Support ==

Revision as of 12:20, 27 February 2012

Change Task Force will be used to discuss the following things to help benefit the development process of ReactOS. Please bear in mind that these are more-or-less useful ideas, and some are not well suited for discussion. Constructive comments are appreciated. Feel free to add your ideas, but do not remove ideas you do not agree with.

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)
  • almost good, we have very good config options for indent, but still manual interaction needed, plus some modules should be kept intact (like drivers totally owned by one person who wrote them, like hpoussin's example) --User:Fireball

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)
  • double repo system, not stable, it's better with branches, as Alex suggested numerously. At least you won't have to submit info between repos via patches (which are lossy) --User:Fireball

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.

  • yes of course, but there are no good tools. Franz is researching this problem too for his work too --User:Fireball

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)
  • generic approach is that indeed community should do as much as possible, especially in promotion / PR area --User:Fireball

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.

  • yes, we do already (coverity), but we need more checking inside reactos itself (heap corruption detector, pool corruption detector) --User:Fireball

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)
  • this is per dev / per maintainer / per module --User:Fireball
  • but what will happen if a dev wants to take a break/leave/choose another part of the os to work on? IMO the biggest problem in Reactos are ancient hacks that take very much time to find. It could be possible to add hacks as bugs in bugzilla. In this way hacks won't get forgotten and other people may help to find and solve the real issue of the hack. Another solution would be to maintain a file in each folder that could describe all the hacks that exist in the module (however it could become outdated very easy) Smiley 19:04, 17 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?

  • this is per module thing, we can't cleanup 10 MLOC at once --User:Fireball

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...

message board

Beside reporting bugs sometimes developers skim over other parts (which aren't focused at the moment) and find some issues/problems they aren't worth submit to bugzilla, but you would like to drop a note for the next person, which is working on that file/module or whatever. So i suggest a message board where you can leave messages/ideas/hints (usually without solutions - otherwise you can fix it yourself or submit a patch to bugzilla). Maybe on the other hand we could find a way to do that with bugzilla... --maku 13:38, 12 March 2009 (UTC)

Uhmm maybe a message board Sticky notes(post-it notes) based?I have heard about Sticky notes for Desktop...does Sticky notes exist for websites? --vicmarcal 15:38, 12 March 2009 (UTC)

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)

no, I disagree --User:Fireball

if you disagree, at least provide some grounds for disagreeing -- Lone Rifle 17:00, 11 March 2009 (UTC)

Why can't we add a big red note blinking that links to: how to file bugs & debugging in bugzilla -> new bug? User:gabrielilardi

The question is WHERE we should add that big red note blinking?BTW a Big Red doesnt solve some issues: Most of the Bugzilla reports arent good enough. Maybe reporters arent skilled enough, or maybe they dont want to waste time making a BT with a raddress2line.This leads to waste our Devs Gold Encoding Time just because opening non-useful bugreports.The Double ticketing,or 2 Bugzillas will filter and add more Info to them, so Devs will fight with Real-NonDuplicate-Full Info Reports instead (as i have seen sometimes) a 2 Megapixels Photo of a BSOD.--Vicmarcal 22:37, 11 March 2009 (UTC)

Well there's an alternative (or better an add on to the red note), only selected users can confirm bugs (amine, skilled testers, etc.), so new bugs are unconfirmed, and devs should just search for confirmed ones. User:gabrielilardi

I think two separate bugzillas/double ticketing is a bad idea, same for the idea that bug reporters should come to irc first. The bug database should contain all bugs and should encourage people to enter bug reports, not occupy them with things to do before adding a bug. Leaving the bug cofirmations to certain ppl sounds better imo. Another idea is a test environment that raddr2line's automatically. That part usually takes a lot of time because it's often done wrong. Same problem for backtraces - quite a lot in bz are useless, because they show useless information. --grschneider 00:13, 12 March 2009 (UTC)

The main problem with only restricting confirmation of bugs and for that matter, setting of other attributes is that the Bugzilla is still occupied. While it may not affect the devs, it would affect the testers and Bugzilla maintainer who would probably wade through both pending and firm bug reports within the same environment. Double ticketing or otherwise creating a buffer between Bugzilla and users is probably an improvement that would benefit testers more than it would benefit the devs, since like grschneider said, the devs can simply search for confirmed reports. -- Lone Rifle 12:00, 12 March 2009 (UTC)

Auditing

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)

  • yes, and I have a long-term thing being planned about this - will share soon --User:Fireball

University Contacts

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)

Renaming 0.4.X as Pre-Beta

ReactOS has a "Marketing" issue right now: The "Alpha" word is damaging our speed spreading.

1) Old users who tested ReactOS old ALPHA versions are discouraging other new users to try ReactOS. You can find a lot of Forum Guys saying: "They have been in Alpha since a lot of years. I tried 0.2.X and it sucks. They are still in Alpha so they are still sucking." Of course we know we sucks  ;)....but not as much as when ReactOS was in 0.2.X. So the "Alpha" word is stopping New Users to test and Old Users to retest.

2) It´s unfair calling 0.4.X an "Alpha Serie". Now we are a little far way of 0.4.0 and ReactOS behaviour is nearer Beta than Alpha. So in 0.4.0 will be much nearer.

3) 0.2.X was called pre-Alpha, 0.3.X was called Alpha, so it has sense to call 0.4.X a pre-Beta.

I know it´s just a Marketing problem, but we are "selling" a product.--Vicmarcal 16:08, 11 March 2009 (UTC)

Adding New Icons in 0.4.0 release

IMO ReactOS should make a big jump between 0.3.X and 0.4. One could be the change of the "Alpha" word,but also maybe we could change the Icon Tango set with the new Icon Set,thanks to the work in the graphics.http://www.reactos.org/wiki/index.php/Icon_set/Candidates. --Vicmarcal 12:18, 17 March 2009 (UTC)

Spreading ReactOS Info: Linux-Open Source Magazines

In each country there are 4 or 5 Linux-Open Source Magazines. Maybe we should try to create(/update) an English Reactos overview, which could be translated by the Translators group(maybe adding to RosCMS?).Then we can try to find these Magazines in each country and send them the Info translated. We are 124 IRC users from more than 15 Countries, so this small action could be a nice way to spread ReactOS info. This action hits directly to potential developers or skilled people: ReactOS targets. --Vicmarcal 12:18, 17 March 2009 (UTC)

Small Ideas for Explorer.exe

Sometimes good ideas to improve the user(good)experience are "easy" to implement.Others,of course, arent so easy... Here there are a mix of them.. http://www.kumailht.com/blog/linux/10-features-ubuntu-should-implement/ --Vicmarcal 22:18, 24 March 2009 (UTC)

ReactOS and Social Support

ReactOS has been refused from Gsoc... ReactOS maybe could try to point itself to Social Support. Social Support is really valuable nowadays (just look Gsoc accepted a Women Developer Association proposal), so sending proposals as:

  • "Developing ReactOS to support NVDA synthesizer for Blind People".

(NVDA->NonVisual Desktop Access (NVDA) is a free and open source screen reader for the Microsoft Windows operating system. This software can enable blind or vision impaired people to access computers running Windows for no more cost than a sighted person.NVDA allows the user to find out what is happening on the screen by querying the Operating system and using a speech synthesizer to output the information. )

  • "Developing ReactOS to support NVDA USB portable app for Blind People"

The objective is supporting NVDA project (or any other Social projects) in order to help people with problems. This work would also lead to improve our general compatibility.

Also we can put NVDA in our releases, so we were fulfilling a big gap that MS Windows doesnt cover.

Indeed we can begin finding some support from Social associations, so they can change they non-useful MS Windows PCs with ReactOS+NVDA Pcs. --Vicmarcal 22:18, 24 March 2009 (UTC)