Hi folks,
our recent heated debate with Jiri Z. reminds me that our mainline
merging policy is only in the heads of the people who have mainline
commit access. It is not written down anywhere and this might create
false expectations both for the contributors and for the core team (not
even speaking about inconsistent decisions among the core team).
Similarly to the coding style, I don't believe that something so
delicate and with such an amount of subjective human aspects as the
merging policy can be put into an exhaustive set of formal rules.
However, having some basic guidelines might help. Here are some first
drafted suggestions from me:
1) If you work on your feature A and start thinking that some of our
existing shared code (abstract data structure, synchronization
primitive, public API, etc.) is totally crappy and stupid, don't try
to convince us by implementing your own local variants of the shared
stuff. Instead, propose an improvement to the shared code that
everybody would benefit from (in a separate branch, ideally) and
after we accept it start using it happily ever after.
2) If your feature A is isolated, optional or easy to avoid for the
"common user", people with probably not nitpick about details.
However, if you are touching some fundamental building block that is
tightly integrated into the working system and virtually cannot be
avoided (*), be prepared for extreme scrutiny and nitpicking.
3) The more conservative and gradual you make your changes, the more
likely it is that someone merges your branch into mainline. Wildly
"progressive" branches can sometimes be chosen for cherrypicking by
someone (**), but it might also linger for a long time. It is
possible to achieve even very radical ideas by gradual changes that
get consensual approval (***).
4) Don't put orthogonal or independent changes into a single feature
branch you want to get merged.
(*) most parts of the kernel (especially those affecting major platforms
such as ia32 and amd64), widely used libc APIs, NS, VFS, loader, etc.
(**) usually if the someone has eminent interest in your features; still
be prepared for the fact that the cherrypicked code might diverge
substantially from your branch
(***) in other words: don't bother anyone enough to fight against them
M.D.
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
