[Bf-committers] Release cycle idea

[Brecht Van Lommel]

SCHEDULE

This is missing a cut-off date for major new features or risky
changes, which should more than one month before the release date.
There is no way we can for example merge Mantaflow at the end of
September and then release a month later. This is important
information for developers working on such projects.

We should stop calling tests builds release candidates. That
terminology is confusing, and should be reserved for a build that
might become the actual release, not one where we know there will be
more bug fixes. Making RC builds is not ideal in general, the only
good reason to do that is to detect issues that are not in the
buildbot. If we can get the buildbot to make our final releases we can
just have daily builds of the stable branch for testing.

We should target releases to explicitly _not_ be near events like
Blender Conference or SIGGRAPH. Otherwise the people handling the
release will often be busy or travelling.

BRANCHES

I'm a proponent of having a separate master and stable branch. I think
it's important to not block all developers whenever we get towards a
release, and instead have a smoother system where all developers can
work at their own pace. However this does require good management and
discipline, so that developers who add new features take
responsibility to fix issues in the stable branch, rather than moving
on to the next thing.

A downside is testing, it's likely that the majority of buildbot users
will continue to test master with all the new features rather than the
stable branch. I think it will be ok in practice, but it's still
something to be aware of. The extra work of merging branches and the
fact that some developers are not comfortable with git merging can
also be a problem. It wasn't a huge issue when we did something
similar with blender 2.7 and 2.8, but still resolving merge conflicts
was generally done by a handful of few core developers.

An advantage of multiple branches is that we can increase the testing
time for major changes. Even with a 2 month release cycle, a feature
can be tested for 3 months before it ends up in a release. Or 4 months
in a 3 month release cycle.

TASK FIELDS

Why add a new task field rather than using Phabricator milestones?
Task fields get added to all projects, some of which are not tied to
Blender releases. If it's a field it should at least have a None
value, but I'm not sure why it should be a field.

I think it's fine to have a list of bugs or other tasks that must be
fixed before the next release. If something is really broken or we
can't release without it, then we must have an overview of that.
However I believe attaching features ahead of time to specific
releases is actively bad. It leads to rushed implementations and bad
priorities. It is notoriously hard to estimate how long development of
a feature takes. Trying to organize development around a planning that
does not reflect reality is more harmful than helpful. Instead we
should prioritize tasks by importance, and when they are finished they
go into the next suitable release, whatever it is, early or late. I
think we have to really resist trying to plan what will be in each
release. It does not scale for a complex open source project like
Blender with a lot of people involved with their own unpredictable
schedules.

If we were to go ahead with this, how would this be done exactly? We
have thousands of tasks, would they all default to "Future" or "None"?
Would bug triagers be expected to estimate when a bug will be fixed
by, and developers estimate when they will complete each task? Who
would be responsible for ensuring this information stays up to date?
Would these numbers be considered like a promise by users, which we
then keep breaking regularly?

Further, I think the idea of major releases needs to be abandoned and
no tasks should be targeted for them. We should be able to to do major
improvements in regular releases and not delay them until some major
release. Major releases like 2.5 and 2.8 have been quite bad for
external contributors and a nightmare to organize for us, I do not
want a repeat of this.

 A blender:released-in field is useful information. But it needs to
solve a problem to be worth the bookkeeping overhead, and it's not
clear to me what that problem is. Auto-generating bugfix lists from
this can be convenient, but it also requires discipline to tag
everything correctly and retitle bug reports, whereas "git log" is a
list that is automatically complete. Triaging bugs and keeping tasks
on developer.blender.org up to date is a lot of work already. We have
to be careful when adding even more things to maintain there.








On Mon, Aug 12, 2019 at 12:35 AM Nathan 'jesterKing' Letwory
<nathan at blender.org> wrote:
>
> Hi,
>
> I've typed my thoughts on the release cycle over at
>
> https://wiki.blender.org/wiki/User:JesterKing/ReleaseCycleNotes
>
> (also contains a pretty picture) but here in short the high-lights:
>
> * if we go for a release just with Blender Conference (24th of October)
> * we could do a three week stabilizing:
>   RC dates could be
>   - 30th September (cut-off date - 2.81 stabilizing branch created, RC1)
>   - 7th (RC2), 14th (RC3), 21th (RC4) October
>   - After RC4 there should be no show-stoppers, meaning the RC4
>     could be rereleased as official 2.81 (proper tagging in repos)
> * blender:release-target custom field for Maniphests in use during
>    week 33
> * weeks 33-39 (2019.08.12-2019.09.29) time to work on new stuff
>    and improving existing
>
> After 2.81 (Blender Conference) we could settle into 3-month cycle
> that would allow for targetting releases around SIGGRAPH and
> Blender Conference.
>
> Nothing has been set in stone regarding dates, but this week I want
> to implement at least the basic custom field for maniphests. There
> should be no changes to how we all type code in the coming weeks.
>
> Have a good week!
>
> /Nathan
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers