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" <[email protected]> wrote:
> Harald Sitter <[email protected]> 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel >
-- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
