On Tue, 16 Jul 2013, Jiri Kosina wrote: > (*) For me personally, the best mode of operation would actually be to > have for-stable/3.x branches in my git tree, cherry-pick from other > topic branches once the patches are in Linus' tree, and send you pull > request for stable regularly (for each stable branch separately of > course) > > This model would make maintainers clearly responsible for the contents > of stable tree, wouldn't cause any extra work for you (quite the > contrary, I'd say), and it'd follow the development model we have for > Linus' tree. ... and it will actually have a nice self-regulatory feature (in case maintainers who are pushing too much stuff your way are part of the problem). Preparing a proper pull request requires much more care, "stopping and thinking for a while", formulating the pull request, than just blindly tossing "Cc: stable" everywhere in a headless-chicken mode. To sum it up: - if the maintainers really do care about their patches being in the -stable tree, this wouldn't cost them too much extra time - if they are just randomly pushing everything to -stable because "hey, why not", this will be an extra hurdle for them to overcome, and they will be revealed easily by poor pull request justification - if the maintainers are lazy and don't care about preparing stable branches, it's their responsibility (and their shame) that -stable will be missing the code they are responsible for - it offloads the work from single point of failure (you) to the maintainers, which makes a lot of sense to me - it aligns the workflow with the workflow that's in place for Linus' already (and not only there) to be more or less a proper git workflow -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html