All,
We (Jeff, Vijay, Amye, and Myself) have been in conversations with FB
folks over upstreaming their work and also around helping them catch
upto 3.8 (as they are on 3.6.3 + large number of patches (say ~300)).
Towards this, to ease their movement to the 3.8 release, considering the
large number of patches etc. it was proposed that we create a special FB
branch in our git repo, and enable them to maintain the same.
The whole intent and purpose of this can be found in the attached document.
We discussed this off-list with maintainers and did not have any
objections that were noted, moving this to the respective lists, to get
it on record and proceed with the branch creation.
Thanks,
Shyam
# Request for special FB development branch against 3.8
FB wants to move to release 3.8 and have quite a few patches that they
need to upstream and port into the 3.8 branch for them to move to this release.
They also want to be in a better position to do upstream first work, so that
they can easily absorb the latest LTM releases for their use, that contains
their work. This requires them to catch up to master first, and vice versa.
Towards this, to reduce the initial turnaround for FB to get into regular
upstream cadence, it is proposed that they would work from a special 3.8 FB
branch.
## How this helps:
This branch will give FB engineers the ability to forward port their changes
into a **static** branch, making it easier for them to move their code upstream.
Further, commits here would go through regular forwarding porting to master
and later pulled down to 3.8.next releases, thereby reducing the gap between the
FB branch and the actual release 3.8 branch.
Features that appear in the FB branch would be forward ported to master, and
appear in the next STM or LTM release. This again reduces what FB is tracking
as features in their special branch.
The end goal of this exercise, is that FB would have all their code in master
and also in the latest LTM release of Gluster, and hence would become first
class citizens, from then on, in driving their changes upstream.
## Point of branch creation:
Create the FB branch at release-3.8
## Branch name:
- release-3.8-fb
## Branch needs:
- FB folks would need full merge rights on their branch
- The exact account IDs will be shared subsequently
- Gerrit integration would be useful, and is possibly a given
- Regression test integration would be useful, but not a must
- IOW, even if regression fails, they would have full rights to merge into
their branch
## Workflow envisaged:
1) FB forward ports their changes to release-3.8-fb branch
- Ensures their tests pass
- Merges the changes as needed in this branch
- Takes assistance from Gluster members in possibly forward porting some
broader changes that, either needs some assistance, or has a strong mutual
interest in terms of functionality provided
2) FB and Gluster members forward port bug fixes from the FB branch to master
3) FB and Gluster members backport accepted bug fixes on master to release-3.8
branch
- Thereby reducing the effort for FB to catch up with the next 3.8.y release
2.1) As in (2), same applies for features from the FB branch
3.1) As in (3), but features (unless there is a strong exception) are backported
to the next Gluster STM or LTM release.
4) A couple of such cycles later, it should be the case that FB no longer needs
to maintain a special branch and can work from the release branches for their
needs. Thus, moving their work to master first, and getting it backported to the
appropriate release point.
- A possible point when this is not needed anymore is when 3.10 LTM is
released (give a sense of the calendar being sought for this)
- Also a possibility is that we still retain a 3.8+-fb branch for their needs
on resolving production needs ASAP, rather than waiting on upstream resolution
_______________________________________________
Gluster-infra mailing list
Gluster-infra@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-infra
