2009/7/18 Jose Catena <span dir="ltr"><<a href="mailto:jc1@diwaves.com">jc1@diwaves.com</a>></span><div class="gmail_quote"><span dir="ltr"><br></span></div><div class="gmail_quote"><span dir="ltr"><br>>But after studying the code a bit and following the mailing lists for a while, the perception of organization and progress is >poor, what introduces the doubt: there is a lot of work to be done, would my effort be wasted?</span></div>
<div class="gmail_quote"><span dir="ltr"><br></span></div><div class="gmail_quote"><span dir="ltr">The only case your effort might be wasted is if you`d writing bad/incorrect code.<br></span></div><div class="gmail_quote">
<span dir="ltr"><br></span></div><div class="gmail_quote"><span dir="ltr">Its a pity your criticizm is not a constructive one. Its easy to point out things in this project that are not really capable. You dont need to be a developer to point those, more or less correctly. The real deal is thinking of solutions.<br>
</span></div><div class="gmail_quote"><span dir="ltr"><br></span></div><div class="gmail_quote"><span dir="ltr">>1) Documentation. I know most devs like me hate having to write it. But complex projects can’t progress well without a >minimum well structured documentation. Someone has to define a basic hierarchy and rules. Whenever someone knew or >learned anything that is undocumented, update the docs, so that others can work coherently. Maybe some of you think there >is some, but to me (please remember my outsider point of view) it seems very poor.</span></div>
<div class="gmail_quote"><span dir="ltr"><br></span></div><div class="gmail_quote"><span dir="ltr">In simple words, we should force writing docs via commit rules? You are right to say that documenting is really despised of. What can we do? Developers here code for fun/knowledge, they arent paid. How can we force anyone to write docs if that person doesnt want to do it? Introducing such rules would quickly result in simple equation: undocumented code or no code at all. Now that`s a great idea.<br>
</span></div><div class="gmail_quote"><span dir="ltr"><br></span></div><div class="gmail_quote"><span dir="ltr">>2) Drivers installation. The drivers needed to run ReactOS in any hardware or VM are already available. It is prioritary, at least, >to have .inf parsing and adv/setup api working well. If developers can’t start the OS in the platform they need to test hardly will >anyone be efficient, if does not leave the effort at all. Of course drivers can fail after succesfully installed, as so many things, >but bugs in .inf installation are first time stoppers and need to be addressed asap.</span></div>
<div class="gmail_quote"><span dir="ltr"><br></span></div><div class="gmail_quote"><span dir="ltr">Surprise... it actually works. Please see Supported Hardware wikipage. Its not simple, it doesn`t work ootb and it would need serious improvements, but you can actually install ANY driver apart from the one for I/O controller, as UNIATA is currently hardcoded into registry and not using hdc.inf as it should be (/me looks at Fireball). I`m not a programmer, yet i managed test several devices using XP drivers successfully. Anyone could be doing it. The howto is on our wiki and you can just ask on #reactos for assistance.<br>
</span></div><div class="gmail_quote"><span dir="ltr"><br></span></div><div class="gmail_quote"><span dir="ltr">>3) Bug reporting and tracking database. I’m sure you all agree regarding the necessity of a well designed one. Someone has >to do it, a project like this can not progress far without it.<br>
</span></div><div class="gmail_quote"><span dir="ltr"><br></span></div><div class="gmail_quote"><span dir="ltr"><a href="http://www.reactos.org/bugzilla/">http://www.reactos.org/bugzilla/</a><br></span></div><div class="gmail_quote">
<span dir="ltr"><br></span></div><div class="gmail_quote"><span dir="ltr">Regards<br></span></div><div class="gmail_quote"><span dir="ltr"><br></span></div>