-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Alex Ionescu Sent: 15. november 2005 22:44 To: ReactOS Development List Subject: Re: [ros-dev] RE: [ros-diffs] [cwittich] 19254: add a checkforSPDRP_CONFIGFLAGSwhich is not working yet
He abandonned his code and it needed a new maintainer. I think you're (purposedly) confusing "maintaining" and "owning" while trying to make a point which doesn't exist. Ge didn't agree with a change I made in Freeldr, and I reverted it. Why? Because he's maintaining it and I don't want to make his life hard. If Magnus spent 6 months writing a DX library from scratch, does that mean I can come in and rewrite half his code because I don't like it? No it doesn't. As the maintainer and guy that wrote 100% of the library he should have a choice in design decisions made with it. That doesn't mean he has to be Hitler, but it does give him some authority over his own code.
Any developer can argue for/against a change, so why make the distinction between owner and non-owner? I would sleep so much better at night if the reason you reverted the freeldr change was that Gé provided a sound technical argument against the change (have to build, test and distribute different .isos for different sub-architectures, only to save a few bytes in the freeldr/setupldr binaries) and not because he was maintaining freeldr. Maintainers come and go. The source code stays.
There is very much a point in reviewing as early as possible. It is to find bugs as early as possible.
I agree and never said anything against this.
Ok, maybe I interpreted it wrong. Maybe you or someone else could explain how the following should be interpreted then?
"It's why I now run a local branch and only commit final code; it lets me do what I want with code that I wrote 100% of, without being criticzed about design choices before the application is complete."
Note that I'm not against local branches at all. What I care about is what and how changes get into the ReactOS repository.
Casper
Sometimes I think you like to invent things just to have something to say. I never said that "I'm afraid to answer questions" or that "Reviewing is only about critiquing". I pointed out that I find it stupid and wasteful to make community decisions on something that the writer hasn't done yet! Imagine a program or DLL as being a book. It starts out in 3 phases
And I argue that it is not stupid and wasteful. It gives more developers a chance to comment on other developers work. Other developers may have experience that may be beneficial in the development of that particular feature. Other developers may have knowledge of another corner of ReactOS where similar code exists and code could be shared. Other developers may see problems with the direction the developer is going and could bring it to the attention of the developer before going a thousand miles in a "bad" direction. Other developers may have experience that could add to achieving a better solution. Holding off the commit/review, decreases the usefulness of the distributed nature of the development of ReactOS.
- Manuscript being written. At this moment, entire sentences are added
and removed, sometimes 3, 4 times in a row until the author decides what to do. Entire chapters can disappear. Plot twists can be removed or added. 2) Manuscript is written. The author is happy with his work and thinks its mostly complete. His editor and publisher will now do reviews, which can still result in modifications present in the book, sometimes even major. Sometimes the author might not agree, but usually they are team decisions, and many times it's mistakes that the author himself hadn't noticed 3) Published book.
Maybe if the editor was brought in from the start, he could have prevented wasting time on writing those sections just to remove them later.
you're a top-down developer. It might only work for people that have already thought of the design for entire months, and start out with their DllMain and then write the 100 stubs they know they will need. But most developers don't do that; some are not aware of the potential issues which might arise.
There is no need to think about the entire design. You just set a goal for each commit that will bring the software one step closer to where you want it to be. Be it preparing for something by refactoring the existing code, adding or deleting code or something entirely different. The important thing is to try to have it work better or at least just as good as before the commit.
You can have developed your whole program, only to realize it fails miserable on MP platforms because you never tested. And this kind of mistake happens even to the best programmers, sometimes years later. Look at the Audio subsystem in NT. It was rewritten THREE times, going from 2/3 user mode 1/3 kernel mode to 1/2 user mode 1/2 kernel mode to 100% user mode in Vista. And we're talking about a company with dedicated teams and years of experience to find these kinds of design flaws. But it still took them 15 years to realize it. So don't tell me that a coder can't realize a mistake after only a month of testing.
I don't see what you are arguing for/against here.
Casper