On Tue, Jun 25, 2019 at 10:58:40AM -0400, Neal Gompa wrote:
On Tue, Jun 25, 2019 at 5:39 AM Michal Kubecek <mkubecek@suse.cz> wrote:
I might partly agree with this if OBS were used only for Factory packages. For those packages, we should indeed try to minimize the number of patches. I said "partly" because there are packages where the discussion with upstream is... difficult. You mentioned systemd - that's one illustrative example, glibc used to be another. Then there are packages where upstream is effectively dead etc.
You say upstream is difficult, I say downstream doesn't talk to upstream much. Admittedly, my patch load as systemd maintainer in Mageia is nowhere near as big as openSUSE's is now, it was worse when I started. I've upstreamed useful changes from Mageia into systemd upstream (including our improvements to the upstream rpm macros, which openSUSE still doesn't use...)
Honestly, this is your own (openSUSE's) fault. I've seen little evidence of communication with upstreams until *very* recently. At least the situation with dracut is improving.
Well, my experience is exactly the opposite. *Any* systemd problem I was interested in ended up in the same way: our engineers described the problem, explained why is it a problem, proposed a solution and the answer from systemd upstream was always the same: no way, we did it like this, it's The Right Way(TM), you have to live with it. Unlike you, I can't blame our developers that they stopped trying after such experience.
Or perhaps I'm more influenced by my beginnings... To me, maintenance of a package begins with introducing myself to upstream and sending fixes/suggestions there to make it better. That was a consequence of how I started out as a Fedora packager. I realize that most other communities don't value that and don't have a directive to try to work with upstream.
That's pure nonsense. Our developers work with upstream closely - where the upstream is open to cooperation. Unfortunately, systemd is a schoolbook example of a project where it's not the case. Another example that comes to my mind was glibc in the times of Ulrich Drepper autocracy but that has become much better since that era ended.
However, the main problem with your vision is that OBS is not used only for Factory packages. It's also used for Leap packages and for SLE packages. For these we cannot simply wave hand and say "patching should be hard" (because we need those fixes) or "talk to upstream" (because most of the patches are upstream backports).
And you know what? Those backports should be visible. Hiding them behind git snapshot things rather than declaring the patch set just means you're trying to dodge the auditing process. If the process for handling backport patching in changelogs is too onerous, then let's fix that.
It is so frustrating trying to figure out how openSUSE has broken something because they've forked packages and done weird things without any way to figure out what's going on. If I could, I'd ban this practice.
Are you sure you know what you are talking about? Please take a closer look at our kernel-source git repository, at the way it works, at the way each patch is annotated. Do you really think tracking changes in that repository is somehow "hidden", "dodging the auditing process" or less transparent than if we tried to use standard "Patch" and "%patch" machinery? (If that were feasible at all, that is.) When I was working in L3, I've been handling issues with various packages and for kernel, it was usually much easier to find out where does a patch come from, who, when and why added it or its upstream status. And this was thanks to the way kernel packages are maintained. Getting the same level of efficiency was impossible for packages maintained only in OBS, even if the patch count was way lower. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org