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.
+1.
[...]
> 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.
Feature velocity and releases do not have to bite each other per se.
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.
I think that for this cycle it's honestly mostly you and me butting heads over how a feature should work (specifically: build trees). We should have ironed that out earlier in the process, but didn't. Since I'm conscious now that releases cement behavior I am set on getting our differences resolved before it makes it into a release.
The other feature we had some discussion on was remote execution. I think that had we set the expectation early that it was an [experimental] opt-in feature for now, there would have been less discussion about it.
All that said, while we should think about how to make the release process simpler we should still introduce another release gate: performance benchmarks. We should not be regressing against a previous release without good reason.
Cheers,
-Tristan
Cheers,
Sander
