Some good points. We have had a dev coordination meeting since. Dalai already sent the notes with the updated release cycle info, but to quickly sum up:
* 2.81 release in November * Use project milestones instead of custom field * cut-off date for major work early enough (2019.09.13) * no releases too close to big events I'll be updating my wiki page on release cycle in a bit to reflect what we discussed. /Nathan On Mon, Aug 12, 2019, 12:05 Brecht Van Lommel <[email protected]> wrote: > 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 > <[email protected]> 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 > > [email protected] > > https://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ > Bf-committers mailing list > [email protected] > https://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
