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.
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).
- 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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.
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.
-
Aleksey Bragin -
Sylvain Petreolle -
Timo Kreuzer