Skip to content

GStreamer 1.0: Fix pipedot import via a gstlal patch

Timothy Davies requested to merge tdavies__fix_gstlal_pipedot_import into gstreamer_python_upgrade

This is a small change to fix a gstlal import. It's likely a code path they haven't tested, since it requires using an appsink and outputting a gstreamer graph.

The change has been in my local gstlal install for a while, so it's thoroughly tested. But I now have much larger gstlal changes that will require a thorough review & design discussions, so we should consider how we want to track gstlal changes & review.

We've got a few options:

  • Create MRs for gstlal
    • This should be the end goal of our changes.
    • We can't rely on this for O4. There are practical reasons why our changes might not be merged in in time. (e.g. #70 relates to a 1 year old issue in gstlal. There are multiple possible solutions, that each require a design discussion, and gstlal's priorities would compete with ours for the preferred solution for O4. It only fixes code paths that SPIIR uses, and couldn't be merged in without further changes and approval on gstlal's end.)
  • Fork gstlal's repo and add it as a submodule for Spiir.
    • The fork would need to be hosted somewhere.
    • The fork would be shortlived, as eventually we want any necessary changes in gstlal proper
    • Tracking development history may be difficult, since a given spiir commit would depend on a particular version of our gstlal fork. Besides which, the gstlal fork's repo may contain MR discussion and comments relevant to corresponding spiir change (as in #70).
  • Add patches for gstlal in Spiir
    • The patches would have to be applied to a local clone of gstlal before build
    • We would create MRs in spiir (as in this MR) and review them in this gitlab repo.
    • Patch files aren't easy to read, and we'll have to jump outside of gitlab to read and review the code changes in context.

On the whole, my preference is to use patches.

Merge request reports