kubuntu patches and backtraces

[Michael Stemle]

Wouldn't we want to do it with all changes until they made their way
upstream and came back down?
On Dec 12, 2013 10:26 AM, "Scott Kitterman" <ubuntu at kitterman.com> wrote:

> Harald Sitter <apachelogger at ubuntu.com> wrote:
> >alohas,
> >
> >I just realized that currently when we have to introduce a kubuntu
> >specific patch these are not immediately obvious in backtraces, which
> >is bad.
> >
> >What does everyone think about introducing a policy that
> >a) all patches of upstream code must isolate their logic into a
> >separate function
> >b) that function must be prefixed with kubuntu_
> >
> >Benefits are:
> >1) if our stuff crashes upstream knows that our stuff crashes
> >2) if a crash appears deeper in the stack they know that somewhere we
> >made changes
> >
> >Disadvantage:
> >1) requires more code
> >2) if upstream changes code we *modify* it may be less obvious that
> >our modification requires updates
> >
> >For example in kde-workspace we have
> >kubuntu_avoid_zic_and_deep_copy_timezone_data.diff which currently
> >looks like this:
> >
> >+        } else if (!QFile::symLinkTarget(tz).isEmpty()) {
> >+          if (!QFile::copy(QFile::symLinkTarget(tz),
> >"/etc/localtime")) {
> >+            ret |= TimezoneError;
> >+          }
> >
> >with the new policy this would be
> >
> >+        } else if (!QFile::symLinkTarget(tz).isEmpty()) {
> >+          kubuntu_avoidZic(tz);
> >+          }
> >
> >HS
>
> But only for long term, not upstreamable changes, right?
>
> Scott K
>
> --
> kubuntu-devel mailing list
> kubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20131212/4ff40729/attachment.html>