[agl-discussions] Unified strategy for handling backports

[Martin Kelly]

Hi,

In AGL, we frequently have to do backports from upstream OE or from 
other sources. These can be bbappends, patches, or entire recipes. 
However, we don't currently have a unified strategy for tracking those 
backports, dropping them at the right time, or documenting their 
purpose. Thus we have backports across several layers in different 
places without necessarily mentioning that they are backports or when 
they should be dropped.

It seems to me that we could improve the situation in a variety of ways. 
The way that comes to mind for me is to add a backports layer that is 
structured in such a way as to make it easy to track and manage 
backports. I think such a layer should somehow codify the following:

- Where the backport came from
- The timeline by which we can drop the backport
- The reason why we need the backport
- If the backport is original to AGL (not from some other layer), what 
our plan is for upstreaming it. Of course this means it's not really a 
backport, just a change that applies to some non-AGL code.
- Which AGL release(s) the backport should apply to
- All backports are in one place (a single layer) rather than scattered

Steve Lemke, I recall that you mentioned at ALS this year that your 
company had some sort of similar layer. Do you have any thoughts about 
how to best handle backports?

There are a variety of ways we could structure such a layer to achieve 
these goals, so I am curious what others' thoughts on this are. If you 
think this is a good idea, I would be happy to help out with it. I am 
already maintaining such a layer outside of AGL, and it seems to be 
working pretty well.