6 Jul
2009
6 Jul
'09
11:49 p.m.
Ok, I'll comment on this:
I agree that the committer of the faulting revision must be tried to be
contacted before reverting / hacking and given time to fix it himself,
but I don't like the idea of broken trunk for 24h. I remember times when
trunk was broken regularly. And yes it was reasonable at that time as we
gained more than we lost. But now we have a much more stable trunk and
if we want to get ready for beta and want to have more devs working on
our code, we need a stable trunk.
If someone complains about his code being reverted after breaking trunk
(major loss of functionality), he should be slapped with something
large, since he violated the most important rule in the first place: DO
NOT BREAK TRUNK.
I also find it quite impolite to not answer, when a dev posts a mail on
ros-dev that a commit broke something. Every developer should be able to
send an email to acknowlegde that he's aware of it, even if he hides
behind anonymousity.
In RL, when you damage someone's parking car, you better leave a message
with your name / adress / phone. Going away and ignoring it can get you
into big trouble. Trunk is every developers parking car. Treat it as such.
When you commit code that is likely to cause regressions, you should be
available and watch buildbot and sysreg. If you are too proud/impatient
to have your stuff being tested for regressions by other people before
committing and also ignore any contact attempts, you should IMO better
not break anything or be prepared to be reverted.
Yes, being reverted sucks (because it tells you "you fail!"). But if
someone can't cope with it he should probably not be coding on OSS.
Regarding my commits: if I break trunk and you cannot contact me for
like 1h via irc / ros-dev, please feel free to hack or revert. I don't
want to be responsible for any longer breakages. I can deal with it.
Just my 0,002 cents per kilobyte,
Timo
Aleksey Bragin schrieb:
I decided to make this as a separate post, though
it's a follow up to
the previous one.
I would like to set, officially, a couple of simple code hacking
rules, which are going to apply immediately for the NTOSKRNL module,
and to other modules after discussion/acceptance. They apply only to
committers (which commit their own or someone else's patches).
1. If you change someone's code, and believe it's a correct change -
go ahead and commit.
2. If you need to add a hack to someone's code, and:
2.1. you want to either hack or revert the offending commit which
breaks booting: This is allowed only after 24hrs after trying to
contact the author / posting to the ros-dev mailing list about the
problem.
2.2. you want to either hack or revert the offending commit which
contains a certain regression but doesn't cause important
consequences like inability to install the OS, or major loss of
functionality: This is allowed only from permission of author of the
code which you want to hack or, as alternative, from my permission.
I think this way we can get some order into the coming commits flow,
which is hard to track.
Also, please comment on this, so that we can alter those rules and
maybe accept them for all modules.
Thanks for understanding,
Aleksey Bragin.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev