Code hacking rules, currently applying for NTOSKRNL

[Aleksey Bragin]

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.

[Timo Kreuzer]

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

[Sylvain Petreolle]

Who should we ask for ros-arm-bringup code then,
like in the "MDL PROBE FAILED" case ?

 Kind regards,
Sylvain Petreolle

----- Message d'origine ----
>   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.

[Aleksey Bragin]

me

On Jul 7, 2009, at 10:47 PM, Sylvain Petreolle wrote:

>  
>  Who should we ask for ros-arm-bringup code then,
>  like in the "MDL PROBE FAILED" case ?
>
>   Kind regards,
>  Sylvain Petreolle
>
>  ----- Message d'origine ----
> > 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.