Use forks instead of static commits for GStreamer

[ikonst]

In relation to e497c4e:

I want to fork gst-plugins-good and gst-plugins-bad on my own GitHub for work-in-progress. The natural next step is to fork cerbero and change some of the recipes to point to my repos.

• I fork off GStreamer upstream.
• I fork cerbero off EricssonResearch/cerbero.
• I need to change the repo to mine, and change commit to "master".
• When I want to take latest GStreamer (that don't break OWR), I have to carefully rebase against the "commit" that's current in each and every recipe.
• When I want to take latest Cerbero, it always conflicts cause "master" != recipe-commit.
• ALTERNATIVELY: I could give up on having my own repo and work with recipe patches (very cumbersome)

If we maintained our GStreamer forks (e.g on GitHub):

• You wouldn't need to maintain the recipe "commit" properties – just naturally rebase the forks against upstream.
• Instead of maintaining recipe patches, simply push into the fork.
• I fork cerbero off EricssonResearch/cerbero, and change the repos to my repos. (The "repo" property doesn't change often, so rebasing against latest cerbero wouldn't be a problem.)
• I'd fork GStreamer off the OWR forks, and once in a while, I simply git pull --rebase owr without worrying.

What do you think?

[superdump]

The commit hashes give a clear indication in the cerbero repo when and what updated. This is then THE central location for seeing any updates.

Patches against gstreamer and other dependencies should be kept to an absolute minimum. If we start maintaining a fork, there is a risk that we will drift away from gst upstream which is not at all a good thing. I think it's good that this be deterred.

Patches should always be submitted to the upstream project and go through their review process because they very probably know better than we do about their own code.

So basically I disagree with this idea. I think it should not be easy to stray long distances from gstreamer upstream and that should be deterred. We should work to get all of our patches upstream.

[sdroege]

I agree with @superdump here

[superdump]

Upstream projects are also generally good at giving advice about how to fix things properly so they should even be consulted before making non-trivial changes for advice about how to do it.

[ikonst]

I agree in principle, and I can see the situation when our forks stray way off upstream as a negative thing. My only worry is the current method's frailness, as we do have to stray long distances currently to stabilize GStreamer for our use.

Here's the individual developer's workflow as of now:

1. For individual developers, maintaining a fork of gst* is the best way to develop patches and rear them into maturity before submitting upstream.
2. To facilitate day-to-day work on openwebrtc and gstreamer, an individual developer can either:
   1. cd sources/.../gst...; git remote add foo ...; git pull --rebase foo —over and over again.
   2. Fork cerbero and modify recipes to change 'origin' (to personal repo) and 'commit' (to "origin/master")
   3. Proposal: Add a feature to cerbero (is there one already?) to support a custom configuration (e.g. in $HOME) overriding certain repos' origins and commits. This will do away with the need to maintain a personal fork of cerbero, and spare the conflicts trying to merge it (after the individual developer tweaked the recipes).
3. To rebase against openwebrtc, an individual developer can either:
   1. Look at (upstream) cerbero recipes, take manual note of the current "head" commits, and git pull from those commits into his personal repo
   2. Proposal: Write a Python script to automate that.

[nirbheek]

So, I think this problem would be solved by fixing the Cerbero development workflow, and @alessandrod has been working on that (starting with GstHackfest 2015).

If you use the patches from #9, you can happily work inside ~/cerbero/sources/.../gst... and whatever changes you make there will be rebased automatically by the recipe on top of whatever is upstream. There won't be a need to maintain a separate fork and constantly rebase manually.

The intention is to upstream this, but I'd like us to test it within OWRTC for a bit first to avoid breaking things upstream for everyone in the world.

[ikonst]

Yay!

[nirbheek]

@ikonst could you please test that PR when you can and tell us what your workflow looks like? Then we can close this issue. :)

[superdump]

I think we'll close this anyway and open issues for improving the other patches to cerbero to improve the workflow as necessary.