[ros-dev] [Vote] Top-level source header
ch at csh-consult.dk
Sun Nov 27 22:09:50 CET 2005
> -----Original Message-----
> From: ros-dev-bounces at reactos.org [mailto:ros-dev-bounces at reactos.org] On Behalf Of Royce Mitchell
> Sent: 27. november 2005 20:02
> To: ReactOS Development List
> Subject: Re: [ros-dev] [Vote] Top-level source header
> Casper Hornstrup wrote:
> >By making project rules we can better avoid the "I'll rewrite it this way
> >because my way is better" class of changes. Without project rules, it is
> >the last one to commit that "wins".
> I don't disagree with this, but as I stated before this is an open
> source unpaid project, so we should only have so many rules as are
> strictly necessary. We should take great care about the rules we create.
I agree, but I trust people to use their best judgement. If 90% vote for
something which I think is crazy, who am I to say this shouldn't be how
the project will do it?
> Too many rules - especially frivolous ones, and we'll drive potential
> developers and even existing developers away.
I could say the same about too few rules. Remember that what one person
does, affects the other persons on the project. I suppose I would like
ReactOS to be somewhere on the middle of this line.
No rules Many rules
E.g. having order/consistency where is helps the group function well
and help the group create a better product. I know ReactOS is about
having fun, but I don't think that not being able to do whatever you feel
like with regard to the project implies no fun. Certainly being in the
chaos/inconsistency state (we've been there) won't create a happy team.
I remember times when ReactOS often couldn't be built or booted for weeks
at a time. In the early days, I just spent my time elsewhere when that
happened. ReactOS wasn't useful anyway.
I recently joined a 15 person team who were working on some project.
This project was close to the no rules/chaos end of that line. Of course
the project was more than 100% over budget and half of the team worked
60-70 hours/week for two months. They were of course unhappy about that,
but they really wanted to have this product ready for their customer.
Nobody likes to fail. For those of you who are interested in numbers,
that is a burn-rate of approx. 700 hours/week. I'll leave it as an
exercise to the reader to calculate their salary per week ;-) Hint:
additional hours over 37 hours/week pays 100% extra.
I see similarity in the ReactOS project. I see many desperately waiting
for that 1.0 release. Now since nobody is paid to work on ReactOS, the
project can't go 100% over budget. We can however spend twice or more as
many hours getting there, depending on how we choose to develop ReactOS.
So instead of reaching 1.0 in 2010 we have to wait until 2022. I'm not
a patient person.
> Furthermore, this vote seems to have started in part because you
> complained that a header copied from another file didn't get updated
> properly. I can only assume that means you intend to have removed parts
> of the headers that are in excess of the agreed-upon header in the vote.
Well, the voting is about what the standard should be (e.g. for new files).
It doesn't specify anything about what to do with the existing headers.
They could be replaced over time for instance.
> >That's what comments are for.
> As I just stated, you were complaining about comments in the header
> about the name of the file that you felt shouldn't be there. Where do we
> draw this line of what's an allowed comment?
I argumented that the contents of the FILE fields in the headers tend to
become wrong and thus useless over time. I can point you to at least four
new files added this week for which this is true. I can point you to another
set of files where the PURPOSE and PROGRAMMER fields states "Unknown" just
because "something should be there".
The vote is about how the header should look like and there were three
suggestions. We have no rules for comments so you can put anything you feel
like in a comment below the header. If you put the name of the file in a
comment in the file, then fine. I will however still argument that they
become wrong over time.
> >That you or someone else don't like a change shouldn't prevent someone
> >else from trying to make that change. Which person or persons should
> >decide which changes shouldn't be allowed to be proposed? If you don't
> >like what someone else proposes, then you can use your right to vote to
> >stop that change within the project.
> Even this is a gray area, because if someone is making changes to an
> area nobody else wants to touch... well... maybe I don't like it, but if
> I'm not willing to fix a perceived problem but someone else is, then how
> much right do I have to complain.... it's like the story of the little
> red hen: nobody wanted to help her bake the bread, but they all wanted
> to eat it. All I'm saying is that we should try to limit our complaints
> about other people's changes just because we don't "like" them. We're
> never going to all agree completely on how things should be done. We
> need to agree to disagree and only invoke this kind of policy-setting
> when it's really important. I think at a minimum we need to more
> carefully word the proposals for the top-level source header issue here
> - in order to solve the problem without unnecessarily constraining
> freedom to develop in each of our own styles.
He has every right. If not, who decides that he hasn't the right?
He may not have good reasons to complain, and may just be annoying to
other people, but that's another issue.
More information about the Ros-dev