[ros-kernel] new patch

[Jason Filby]

Actually the two situations are not identical. The first case
involved, as Mike has said, a commit from a contributor were a change
of logic was made by the committer - with the contributor's name on
it.

Ge, I'm sure you are allowed to modify the code, I don't think we
have any rule against that. However, our good neighbour policy says
that the issue has to be talked out - and please, on the mailing list
- not everyone's on IRC all the time.

Following a breakdown in the failure for the two parties to agree on
what code should eventually be the latest in CVS, Vizzini as Kernel
Coordinator would have the right to decide. BUT we should all work
hard to make sure that such rulings almost never happen - it just
leaves a bad taste in one's mouth really (although if there's
breakdown it is necessary).

Regards
Jason

--- Mike Nordell <tamlin at algonet.se> wrote:
> Ge van Geldorp wrote:
> 
> > A few months ago, we had a situation where someone without CVS
> > access sent a patch to the list. The patch worked as submitted,
> > but the committer saw room for improvement and made a small
> > change to the patch before committing it.
> 
> Actually, if you're thinking of the same incident as I am, there
> were a
> number of changes. Some good, some bad.
> 
> > The original poster didn't like this.
> 
> <rethoric>
> If you provide a patch, someone changes it to work neither as
> expected nor
> intended and then committs it in *your name*, would you be pleased?
> </rethoric>
> 
> > There was something of a heated debate about
> > it and the end conclusion was that the committer shouldn't have
> > changed the patch and in fact the change was rolled back.
> > Atm we have the same situation.
> 
> As for the general conclusion it's somewhat similar, but the
> reasons and
> (the little I have followed this thread) the proposed changes,
> which in this
> case is discussed and AFAIK not just silently made and committed,
> in my mind
> makes a world of difference.
> 
> > Jonathan submitted a patch which
> > works, no doubt about that. I think there is room for
> improvement,
> > so I talked to Jonathan about it. He thinks the patch is fine as
> > it is. Now the funny thing is if I commit it I can't optimize it
> > anymore, according to the rules established earlier,
> 
> Then those "rules" are plain silly. Because one person with committ
> access
> made a mistake once and getting a slap on the wrist for his
> *mistakes* (not
> the *good* changes, but the *bad* ones), does that somehow imply
> everyone
> for ever and ever should be disallowed to improve that code? Of
> course not!
> 
> IMHO, if this has turned into such an important matter as it seems
> to have,
> that committers shouldn't even be allowed to change formatting, add
> missing
> braces and so on, I think it'll be pretty darn hard to both submit,
> accept
> and committ patches. Please note that I intentionally didn't
> mention logic
> changes.
> 
> But perhaps this is a non-issue because of CVS history; committer
> committs
> unmodified patch in patch submitters name. That way the patch is in
> CVS
> history and the patch submitter can only be blamed for his/hers
> changes -
> not the changes of anyone else. If there after this are room for
> improvements, it works just like any ol' code in CVS - any and all
> are
> (obviously) allowed to improve the code. Sure, it perhaps sometimes
> "wastes"
> a revision on the file(s) affected and it add a little more
> disk-usage, but
> it also keeps both copyright and honor of all affected parties - a
> quite low
> price to pay for keeping the integrity of all involved, IMHO.
> 
> Just my 0.02.
> 
> /Mike
> 
> _______________________________________________
> Ros-kernel mailing list
> Ros-kernel at reactos.com
> http://reactos.geldorp.nl:8080/mailman/listinfo/ros-kernel


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree