-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
| I think perhaps we can find a better way to proceed on at least some of | these philosophical disagreements by providing choices. | | I propose that OM create a debug branch that tracks the stable branch, | which would be a place for patches or defconfig changes who's purpose is | to facilitate debugging sorts of activities (ask "is this change going | to be removed in the released kernel?"). I cloned current andy, which has your patches into "debug". It also has the Cesar stuff, not sure if this what you have in mind for the use of that branch. | This would offer distros (and ultimately users) a choice of kernels to run. | | This would also offer developers with different opinions about changes | to choose to work on a branch that best suits their needs. Less time | spent arguing and reworking patches can only improve productivity, and | ultimately the distros (and users) will choose which kernel they prefer. It doesn't fix the problem that an invasive patchset outside our stable makes trouble for you same as me. We can't simply put those patches at the bottom of the stack and forget about it since then any other patches that touch on those changes won't apply cleanly to stable. We can keep the most invasive patches at the top all the time, pop them when adding other patches and then when we push them back, rebase against any changed code. That'll work but it's not exactly zero hassle to do it every patch. If they have something longer term than a throwaway context, as does your nspy stuff, best solution is to implement them in stable, made configurable in Kconfig. Then we only rebase anything when we rebase against mainline. I realize this can cause braindeath going over it the nth time, so I can imagine to help out with Kconfig side for example. On "Give me Upstream or Give Me Death" I care about it at all mainly because upstream tends to have higher standards, which we should not easily turn our face against considering, and if we take on maintainence of stuff our side, we don't want to have to maintain difficult stuff either. Anyway, answer was "yes". - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh0cCkACgkQOjLpvpq7dMp1kwCgjEICK6juvvQ8k7mXeL+h1fXD VNgAn24fO702eo/+Hqt9OLXF8cA7JgJy =pXsk -----END PGP SIGNATURE-----
