[Starlingx-discuss] Cores meeting minutes 8/16/18

[Jones, Bruce E]

Let's go ahead and pull a branch for this.  Dean, can you enable Saul and/or Yong to do this?

         brucej

-----Original Message-----
From: Dean Troyer [mailto:dtroyer at gmail.com] 
Sent: Thursday, August 16, 2018 11:45 AM
To: Jones, Bruce E <bruce.e.jones at intel.com>
Cc: starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] Cores meeting minutes 8/16/18

On Thu, Aug 16, 2018 at 10:04 AM, Jones, Bruce E <bruce.e.jones at intel.com> wrote:
> ·         Centos 7.5 upgrade status and plan
[...]
> o    Do we pull a branch for this?   Only Brian (sniff) and Dean have the
> ability to create branches right now.  Dean to ramp Scott and Saul to 
> that list.

For the record, this is controlled by the starlingx-release group in Gerrit.

> o    Issues with branching (in general)
>
> They tend to hang around and create technical debt.  Can fall behind 
> mainline development - needs to be periodically rebased to master (weekly).
>
> If we do this on mainline all reviews are highly visible.  On a branch 
> less so.
>
> There might be hundreds of checkins for this upgrade
>
> People tend to ignore and not review feature branches, but the changes 
> do need active review.
>
> o    Dean to start a thread on the mailing list to continue the discussion
> there.  Given the above he thinks a feature branch is an easier sell.

[Much of this was written yesterday before the meeting so there is overlap with the above; the purpose in writing this down is to start shaping the guidelines we use for this in the future...]

Feature branches are useful things, however they have costs and downsides and I believe the bar for creating them should be higher than things like milestone branches.  I'll outline the things on my mind to consider here

Some of the reasons to create a feature branch is to make it easier to to focus on a set of changes without having other things change out from under you.  This can also be done directly in Gerrit using the repo manifest to control what gets pulled out of Gerrit, pulling code directly from one (or a stack of) review.  Everyone can do this on their own or can coordinate with shared manifest files.

There is also a social benefit in structuring batches of reviews to not make things terrible for other developers in a project.
Coordinating that work requires communication (a good thing) but also timezone overlap is extremely helpful here.  Working in isolation is rarely friendly to the other developers, and sometimes feature branch reviews get de-prioritized by reviews not working on them directly.
This is just something the project team needs to stay aware of and try to minimize.

One of the issues with a feature branch is divergence from master over time.  This must be countered by periodically rebasing the feature branch on master and not just waiting until the feature branch is ready to be merged back in to master.  Doing the work inline will help find merge conflicts as they happen, with the feature branch they are generally only found when doing this rebase.  This also puts the burden of resolving the conflicts on the feature branch and not master.  I would suggest we set a maximum time between master rebases for each feature branch created to try and balance these issues.

Another significant tradeoff is with regards to testing.  A feature branch requires a distinct testing effort for things not covered directly by CI/CD.  This means additional hours spent by QA people.
However when this effort is of a different nature this separation may be desirable, as Brent pointed out on the call this morning in the current case.

In the end I am leaning strongly toward creating the feature branch for the 7.5 work due primarily to a) the testing brought up by Brent, and b) the sheer volume of expected reviews.  Managing a couple hundred stacked reviews with a manifest may be doable but we just do not have that experience to do work on that scale yet.  That said, I would like to see at least weekly rebases with master to keep the divergence to a sane level.

Also, we should only branch in the repos where it is actually needed, not in all 50+.  The list of those repos that have been branched can be extracted from the manifest file, which will have a matching feature branch similar to the milestone branches.

I am sure I've left out in the above some of the things I've mention in conversations earlier this week...

dt

-- 

Dean Troyer
dtroyer at gmail.com