[ros-dev] [Vote] Top-level source header

[michael at fritscher.net]

Hmm, can't we put the license in a svn property, too?
The project should be clear from the directory it is, and the copyright
should be clear from the SVN-History, if not, e.g. imports/vendor drops
from another projects, we could add a COPYRIGHT-file in these directories.

So we wouldn't need a header at all...
Or the header could be autogenerated on commit or on a checkout...

I would vote for d (further discussion), too.

>
>
>> -----Original Message-----
>> From: ros-dev-bounces at reactos.org [mailto:ros-dev-bounces at reactos.org]
>> On Behalf Of Royce Mitchell
>> III
>> 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
> <----------------------------------------------------------->
>  Chaos/inconsistency                       order/consistency
>
> 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.
>
> Casper
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>