Proposal: "debug" branch for the kernel

[Andy Green]

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