Re: [BuildStream] 1.4 Release timeline

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

On Fri, 2018-12-07 at 13:43 +0100, Sander Striker wrote:
> Hi,
[...]
>  
> > Lets take the time to really nail down all of the breaking command line
> > changes we wanted to land, so we don't need to have any more breaking
> > changes next cycle, and iron out what to do with buildtrees and
> > optionality of them.
>
> And let's have that drive the schedule then? :)

I honestly agree with this.

On the one hand, we need to have a release cycle otherwise the software
is always going to be in a state of flux (at least under present
conditions where a lot of new features are being added), but on the
other hand we should not release prematurely.

If we are late with one cycle, that should just inform us that we were
overly ambitious and we should readjust expectations for the next
cycle.

[...]
> We should separately have the conversation again how we do not have
> the release process cause this friction altogether.

Agree again.

This is not an easy problem to solve.

In a traditional sense, we should block branches from landing until
they really are solid and ready - with this approach the release cycle
is hardly even needed, we could technically release at any time from
master. We had this approach at first and it turned out to be untenable
as a lot of work was blocked behind pending branches.

The converse approach of landing things early and perfecting them
after, unblocking parallel work at the earliest opportunity I think was
a good one, but I think the "perfecting them after" part has failed to
take priority over the development of yet more features, leaving us in
a difficult situation as we approach end of cycle.

I am honestly not sure what the best answer to this is and hope we can
have an open and productive conversation and find a better approach.

Cheers,
    -Tristan