On Thu, 07 Apr 2016 18:20:53 +0200, Jan Engelhardt wrote:
On Thursday 2016-04-07 17:12, Takashi Iwai wrote:
In general, we have "upstream-first" policy
The UF paragraphs you find on https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Upstream_polic... are an *option* to (a) expedite patches when maintainers are the same, (b) soothe upstream's worry that there is an incompetent downstream at work.
That, of course, does not invalidate the goal of least-patches-possible - sometimes you just have to try out a patch on your distro folks (this is where the "test mass" is) before upstreaming. :)
That said, the best route would be to submit the patches to upstream, then we backport them once when they are accepted. Otherwise wild patches may be a big PITA.
Wild patches, at least if properly documented per Type 2 Markup, are not as bad as you make them out to be.
The PITA in packaging is wielding a big patch stack (irrespective of wild or backported), because you have to rerun quilt setup whenever there was a fuzz/reject, which increases with the number of total patches.
Yes, and the kernel is *exactly* the big patch stack. We have more than 12,000 patches on SLE12 kernel, for example. However, ironically, the amount of patches doesn't correspond to the difficulty of the maintenance straightforwardly. Rather keeping a wild patch in an enterprise kernel is easier than keeping in Tumbleweed kernel. Since TW kernel is a moving target, and as you know well, the Linux kernel is one of the fastest evolving code tree, keeping the out-of-tree patch is a really burden while following the development of the kernel tree. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org