Community
Participate
Working Groups
This ticket is for tracking discussion and work related to hosting git repositories for Long Term Support (LTS). Capacity metrics from today's community infrastructure should be used to estimate capacity needed for LTS.
A likely scenario for LTS is the following: 1) A change is made in an LTS version (call this version A-LTS) of a project 2) The change is noticed and picked up for the next community version (call this version B-Community) of that project 3) B-Community goes into LTS, creating B-LTS 4) LTS Steering Committee/Change control committee review what's in B-LTS that should go to A-LTS and vice versa. Potential problem: If #2 was done by hand, or done by applying a patch, this would likely cause a false positive report that change #1 is not in B-LTS and change #2 is not in A-LTS. This would be very bad. A committer doing #2 would have read access to A-LTS and B-Community. The best/easiest way to solve this would likely be for them to cherry pick change #1 to B-Community. This should ensure sufficient meta data describes the change so that git in LTS can recognize #1 and #2 are actually the same change thus not conflict or report a false positive missing change. Soliciting feedback on this from others. Thanks in advance.
As background, we plan to shadow versions of projects gearing up for the annual simultaneous release in the LTS forge. Work won't start in LTS until SR0 for that release so these will be automated trivial rebases.
The command: git format-patch ... Can be used to generate a patch that can by imported into another repo easily. It contains the commit metadata in addition to the diffs. You can even use it to get a collection of commits that can be zipped up as a set.
We'll have to be proactive to make this doing this very easy so people gravitate to that rather than other techniques that could cause needless conflicts and false positive when reporting. For example, automate creation of such patches via. a post commit hook and communicate well so that people use them when pulling changes made in LTS-land.
Andrew, is there anything left to do here?
(In reply to comment #5) > Andrew, is there anything left to do here? I think we can declare victory on this one. Closing. Naturally we'll create new repositories for new projects as they arrive but can & should use a distinct bug for each.
Moving to the Working Groups section.
