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

[Dean Troyer]

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