[ros-dev] RE: [ros-diffs] [cwittich] 19254: add a checkforSPDRP_CONFIGFLAGSwhich is not working yet

[Casper Hornstrup]

> -----Original Message-----
> From: ros-dev-bounces at reactos.org [mailto:ros-dev-bounces at 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.

> 1) 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