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
[email protected]
http://www.reactos.org/mailman/listinfo/ros-dev

Reply via email to