New committer policy / unblocking feature branches

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

Hi all,

    This is a general announcement following some discussion which has
occurred in and around GUADEC. In some ways this is also a follow up to
discussion around the project being under heavy load[1], a situation
which has unfortunately not improved.

After much discussion and some compromise, we're going to take the
following two actions to improve the situation at this time.


Aggressive granting of commit access to contributors
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
During the 1.1 cycle I have been overly protective in terms of granting
commit access. There had been a series of breaking changes which were
not easy to catch with CI at the time, and putting out fires with users
having to use the development branch certainly put me on the defense.

This was the wrong approach. We want to empower our contributors and we
want our contributors to have a greater sense of ownership and pride in
the code base; the way to do this is let them break things occasionally
and let them share in the responsibility and fun of fixing unexpected
breakages, rather than to try to ensure that things are safe to land
first.

So at this time we will be handing out commit access to anyone who has
successfully landed a single patch to the code base, which will be the
criteria for handing out commit access going forward.

Starting with the 1.3 development branch (more on this in the next
point below), we don't want to be overly strict about unexpected
breakage in development branches, so long as contributors are
responsive and show willingness to address problems after landing
branches there should not be any problems here.

What we are expecting of committers here in general is basically to
escalate the review in cases of uncertainty:

  o If the patch/branch is very trivial (obvious few line changes
    or typos etc), and you are confident of the change, there
    is no need for review.

  o If the patch/branch is non trivial, please obtain a review
    from another committer who is familiar with the area which the
    branch effects.

  o Architectural changes worry me more than temporary functionality
    breakages in the development branches; as these effect long term
    maintainability and also how orthogonal ongoing branches will be
    developed - there is no CI for this.

    Ideally architecture should be clarified enough in the feature
    proposal process on the mailing list, however it is often not
    enough due to discoveries in the implementation phase of complex
    features.

    If you are reviewing and are uncertain about the architectural
    approach, then please run these changes by a committer who is
    familiar with the overall architecture and is confident of the
    architectural change.

    This should be in the form of a simple conversation about
    the architecture, not an escalation of the entire technical
    patch review.

A side effect of this is going to be that contributors may be asked
to make changes after having landed a branch, or we might make changes
to the code and do a post-merge review. These occurrences should not be
taken as personal criticism, but rather an effective mechanism for
communicating details that we hope will be considered in future patches
and reviews.

I don't expect to need any detailed policy for "bad actors" as I don't
think we will have any. Suffice to say that we will handle things on a
case by case basis - commit access should not result in commit wars or
be used as a tool to subvert the project when disagreements arise, such
incidents (if any) would surely lead to temporary suspension of commit
rights.

I should point out that all of the above applies equally to stable and
development branches in general - except that breaking a stable branch
should not be acceptable in any circumstances.


Unblocking features / early branching
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At this time we have a few large and risky branches which are either
ready to land or are very close, and an upcoming feature freeze in two
weeks from now leading up to our 1.2 stable release.

In order to cater to the healthy development of the bigger and more
risky features, we will be branching the `bst-1.2` branch early this
week, unblocking master for the landing of 1.3.x material immediately.

A couple of unlanded features have been marked for `bst-1.2`, these
will either land on master before branching in the next days, or we
will take care of backporting them to the `bst-1.2` branch before
feature freeze on July 30th.

In case it is not clear: Feature freeze will of course only effect the
`bst-1.2` branch, not the master branch which will effectively be 1.3.x
development.

Since 1.3.x will effectively be the first unstable series which does
not affect existing users, this will afford us much more liberty within
the cycle, so we will have a more relaxed policy and allow for more
technical debt which should be paid off before 1.4.

As a specific example, the infamous git history issue #376[2] will no
longer block issue #311[3], instead we will work around it with
#455[4]. This will break the builds of the flatpak runtimes in
BuildStream 1.3.x, but we will have 6 months to pay off this debt in
"some way" before 1.4.


In closing, we have a lot of exciting features to land and scenarios to
test in the upcoming cycle, so I bid you all a happy 1.3.x development
cycle !

Cheers,
    -Tristan


[1]: https://mail.gnome.org/archives/buildstream-list/2018-April/msg00021.html
[2]: https://gitlab.com/BuildStream/buildstream/issues/376
[3]: https://gitlab.com/BuildStream/buildstream/issues/311
[4]: https://gitlab.com/BuildStream/buildstream/issues/455