what’s the policy around backporting large features? PR #2528 in Credentials is a backport of the entire Badge issuance feature. The feature itself is fine, and I’m assuming the backport is because some Redwood operators want the feature, but I’m uncomfortable backporting an entire large feature without community signoff.
2 Likes
This is a PR that affects many (82) files, includes a very complex migration and a lot of changes in the python requirements. I don’t think we should merge it in open-release/redwood.master. What do other BTR members think about it?
Who is asking for this? What burden does it place on operators going from Redwood.1 to Redwood.2 or .3 (wherever this lands)? What Tutor support is needed?
I think in general I feel that features that miss the cut should be punted to the next release, with only fixes backported. What precedent would this set? What burden is placed on BTR and the release leader?
Under normal circumstances, only fixes are allowed to be backported, but exceptions can be made if necessary. The proposed backport requires testing, which is not feasible given the schedule for redwood.2. In my opinion, such feature backports should be part of our Product WG roadmap, and we must plan the corresponding work accordingly.
If the feature is deemed crucial, let’s ask our Product WG to accept the backport. In this case, the release date may need to be shifted slightly.
1 Like
@Maksim_Sokolskiy, since this is RG work, should I leave the PR open and let you follow up with the WG? Or should I close the PR?
Let’s leave it open for a while - I’ll talk with the credentials team and than discuss with the BTR WG.
1 Like