Re: [Bf-committers] Committing fixes for releases in stabilizing branch.
On Wed, 2019-10-16 at 10:23 +0200, Brecht Van Lommel wrote: > There were 2 mailing list topics about it, and it was mentioned in > meeting > notes 5 times. The wiki page explains it in detail, there was a > code.blender.org blog post and developer.blender.org front page links > to > information about it. > > I also find it worrying that some active devs were unaware of this, > and I > think those devs should start paying more attention to bf-committers > emails. > > https://lists.blender.org/pipermail/bf-committers/2019-August/050136.html > https://lists.blender.org/pipermail/bf-committers/2019-August/050153.html > https://lists.blender.org/pipermail/bf-committers/2019-August/050126.html > https://lists.blender.org/pipermail/bf-committers/2019-August/050173.html > https://lists.blender.org/pipermail/bf-committers/2019-August/050178.html > https://lists.blender.org/pipermail/bf-committers/2019-September/050182.html > https://lists.blender.org/pipermail/bf-committers/2019-October/050218.html > https://wiki.blender.org/wiki/Process/Release_Cycle > https://code.blender.org/2019/10/blender-release-cycle/ > https://developer.blender.org/project/view/88/ mea culpa then! While I do read meeting minutes, having missed the original mail on this topic I didn't realize the implications for the stable branch. Now I'm left wondering why Nathan said he needs to communicate better :| > On Wed, Oct 16, 2019 at 2:52 AM Campbell Barton > > wrote: > > > On Mon, 2019-10-14 at 11:37 +0300, Nathan 'jesterKing' Letwory > wrote: > > > On Mon, 14 Oct 2019 at 11:24, Campbell Barton < > ideasma...@gmail.com> > > > wrote: > > > > On Mon, 2019-10-14 at 11:15 +0300, Nathan 'jesterKing' Letwory > > > wrote: > > > > Some fixed change behavior, were it's disputable weather we > would > > > want > > > > such changes in a release - its not just a question of > fix/broken > > > > state. > > > > > > If a fix is unclear then this should be addressed indeed. That is > > > what this work > > > is for. > > > > > > > Again, there is still no justification for this change. > > > > Who wanted this? Why? > > > > > > The motive here is to separate out stabilizing work from the work > > > done > > > on new features in master. This has been discussed since August. > > > > This is still fuzzy to me, it seems this didn't go via regular > > development communication channels? > > > > This is turning into a meta-topic, since I don't mean to focus on > > _this_ particular issue, it's more an example of something I think > we > > shuold avoid repeating, > > I find it worrying that a significant change the the release > process > > which it seems multiple active devs (including admins) where > unaware of. > > Without a clear outcome or statement about what will happen > differently in > > the future. > > > > I'd suggest all non-trivial changes to the release process be > submitted > > as proposals to developer.blender.org, > > as well as being listed in the meeting minutes, allowing some time > for > > feedback before they're implemented. > > > > > > Currently the branch fails to merge into master. > > > > Who is responsible for tracking down & poking people to merge > their > > > > work? > > > > > > Whoever notices such a case should feel free to notify the author > > > whose > > > commits fail to merge, failing that poke Brecht, Dalai or me to > > > ensure it > > > gets handled. > > > > > > /Nathan > > > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Committing fixes for releases in stabilizing branch.
There were 2 mailing list topics about it, and it was mentioned in meeting notes 5 times. The wiki page explains it in detail, there was a code.blender.org blog post and developer.blender.org front page links to information about it. I also find it worrying that some active devs were unaware of this, and I think those devs should start paying more attention to bf-committers emails. https://lists.blender.org/pipermail/bf-committers/2019-August/050136.html https://lists.blender.org/pipermail/bf-committers/2019-August/050153.html https://lists.blender.org/pipermail/bf-committers/2019-August/050126.html https://lists.blender.org/pipermail/bf-committers/2019-August/050173.html https://lists.blender.org/pipermail/bf-committers/2019-August/050178.html https://lists.blender.org/pipermail/bf-committers/2019-September/050182.html https://lists.blender.org/pipermail/bf-committers/2019-October/050218.html https://wiki.blender.org/wiki/Process/Release_Cycle https://code.blender.org/2019/10/blender-release-cycle/ https://developer.blender.org/project/view/88/ On Wed, Oct 16, 2019 at 2:52 AM Campbell Barton wrote: > On Mon, 2019-10-14 at 11:37 +0300, Nathan 'jesterKing' Letwory wrote: > > On Mon, 14 Oct 2019 at 11:24, Campbell Barton > > wrote: > > > On Mon, 2019-10-14 at 11:15 +0300, Nathan 'jesterKing' Letwory > > wrote: > > > Some fixed change behavior, were it's disputable weather we would > > want > > > such changes in a release - its not just a question of fix/broken > > > state. > > > > If a fix is unclear then this should be addressed indeed. That is > > what this work > > is for. > > > > > Again, there is still no justification for this change. > > > Who wanted this? Why? > > > > The motive here is to separate out stabilizing work from the work > > done > > on new features in master. This has been discussed since August. > > This is still fuzzy to me, it seems this didn't go via regular > development communication channels? > > This is turning into a meta-topic, since I don't mean to focus on > _this_ particular issue, it's more an example of something I think we > shuold avoid repeating, > I find it worrying that a significant change the the release process > which it seems multiple active devs (including admins) where unaware of. > Without a clear outcome or statement about what will happen differently in > the future. > > I'd suggest all non-trivial changes to the release process be submitted > as proposals to developer.blender.org, > as well as being listed in the meeting minutes, allowing some time for > feedback before they're implemented. > > > > Currently the branch fails to merge into master. > > > Who is responsible for tracking down & poking people to merge their > > > work? > > > > Whoever notices such a case should feel free to notify the author > > whose > > commits fail to merge, failing that poke Brecht, Dalai or me to > > ensure it > > gets handled. > > > > /Nathan > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Committing fixes for releases in stabilizing branch.
On Mon, 2019-10-14 at 11:37 +0300, Nathan 'jesterKing' Letwory wrote: > On Mon, 14 Oct 2019 at 11:24, Campbell Barton > wrote: > > On Mon, 2019-10-14 at 11:15 +0300, Nathan 'jesterKing' Letwory > wrote: > > Some fixed change behavior, were it's disputable weather we would > want > > such changes in a release - its not just a question of fix/broken > > state. > > If a fix is unclear then this should be addressed indeed. That is > what this work > is for. > > > Again, there is still no justification for this change. > > Who wanted this? Why? > > The motive here is to separate out stabilizing work from the work > done > on new features in master. This has been discussed since August. This is still fuzzy to me, it seems this didn't go via regular development communication channels? This is turning into a meta-topic, since I don't mean to focus on _this_ particular issue, it's more an example of something I think we shuold avoid repeating, I find it worrying that a significant change the the release process which it seems multiple active devs (including admins) where unaware of. Without a clear outcome or statement about what will happen differently in the future. I'd suggest all non-trivial changes to the release process be submitted as proposals to developer.blender.org, as well as being listed in the meeting minutes, allowing some time for feedback before they're implemented. > > Currently the branch fails to merge into master. > > Who is responsible for tracking down & poking people to merge their > > work? > > Whoever notices such a case should feel free to notify the author > whose > commits fail to merge, failing that poke Brecht, Dalai or me to > ensure it > gets handled. > > /Nathan ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Committing fixes for releases in stabilizing branch.
On Mon, 14 Oct 2019 at 11:24, Campbell Barton wrote: > On Mon, 2019-10-14 at 11:15 +0300, Nathan 'jesterKing' Letwory wrote: > Some fixed change behavior, were it's disputable weather we would want > such changes in a release - its not just a question of fix/broken > state. If a fix is unclear then this should be addressed indeed. That is what this work is for. > Again, there is still no justification for this change. > Who wanted this? Why? The motive here is to separate out stabilizing work from the work done on new features in master. This has been discussed since August. > Currently the branch fails to merge into master. > Who is responsible for tracking down & poking people to merge their > work? Whoever notices such a case should feel free to notify the author whose commits fail to merge, failing that poke Brecht, Dalai or me to ensure it gets handled. /Nathan ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Committing fixes for releases in stabilizing branch.
On Mon, 2019-10-14 at 11:15 +0300, Nathan 'jesterKing' Letwory wrote: > On Mon, 14 Oct 2019 at 07:37, Campbell Barton > wrote: > > > What kind of backfire are you talking about? > > > > A fix that needs to be removed from the stable branch > > (typically because it causes unforeseen problems). > > Naturally the goal is to have fixes that actual fix something. A fix > that causes > problems isn't really a proper fix. Reverting sounds like a good > approach there, then > apply a proper fix. But we'll have to deal with such things on a case > by case basis. > > /Nathan Some fixed change behavior, were it's disputable weather we would want such changes in a release - its not just a question of fix/broken state. Again, there is still no justification for this change. Who wanted this? Why? Currently the branch fails to merge into master. Who is responsible for tracking down & poking people to merge their work? ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Committing fixes for releases in stabilizing branch.
On Mon, 14 Oct 2019 at 07:37, Campbell Barton wrote: > > What kind of backfire are you talking about? > > A fix that needs to be removed from the stable branch > (typically because it causes unforeseen problems). Naturally the goal is to have fixes that actual fix something. A fix that causes problems isn't really a proper fix. Reverting sounds like a good approach there, then apply a proper fix. But we'll have to deal with such things on a case by case basis. /Nathan ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Committing fixes for releases in stabilizing branch.
On Mon, 2019-10-14 at 07:32 +0300, Nathan 'jesterKing' Letwory wrote: > On Mon, 14 Oct 2019 at 03:39, Campbell Barton > wrote: > > - How to handle fixes that are first made to master, > > and later on we find should be applies to the stable branch > > (merge? cherry pick?). > > To make merging process as clean as possible I would say revert in > master, > apply to stable, merge down to master. > > > > - How to handle fixes that backfire > > (eg, a fix we make in the stable branch, then cause issues, > > then we want to remove from the stable branch but keep in > master). > > What kind of backfire are you talking about? A fix that needs to be removed from the stable branch (typically because it causes unforeseen problems). > > > - How strict are we on merging immediately after committing > > to the > > stable branch? > > So far there has been some accumulation of multiple commits > > to the stable branch which then get merged. > > > > Is it discouraged to push multiple fix commits, > > then a merge afterwards? > > Since the assumption is a commit per fix it'd be ideal to merge down > to > master once the fix is in stable. > > /Nathan > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Committing fixes for releases in stabilizing branch.
On Mon, 14 Oct 2019 at 03:39, Campbell Barton wrote: > - How to handle fixes that are first made to master, > and later on we find should be applies to the stable branch > (merge? cherry pick?). To make merging process as clean as possible I would say revert in master, apply to stable, merge down to master. > - How to handle fixes that backfire > (eg, a fix we make in the stable branch, then cause issues, > then we want to remove from the stable branch but keep in master). What kind of backfire are you talking about? > - How strict are we on merging immediately after committing > to the > stable branch? > So far there has been some accumulation of multiple commits > to the stable branch which then get merged. > > Is it discouraged to push multiple fix commits, > then a merge afterwards? Since the assumption is a commit per fix it'd be ideal to merge down to master once the fix is in stable. /Nathan ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Committing fixes for releases in stabilizing branch.
This change in branch usage doesn't cover... - How to handle fixes that are first made to master, and later on we find should be applies to the stable branch (merge? cherry pick?). - How to handle fixes that backfire (eg, a fix we make in the stable branch, then cause issues, then we want to remove from the stable branch but keep in master). - How strict are we on merging immediately after committing to the stable branch? So far there has been some accumulation of multiple commits to the stable branch which then get merged. Is it discouraged to push multiple fix commits, then a merge afterwards? Also, it would be good if there was some context around why changes like this are made. On Thu, 2019-10-10 at 10:34 +0300, Nathan 'jesterKing' Letwory wrote: > Hey all, > > Soon the stabilizing branches will be created. While not much will > change, but there are a couple of things to keep in mind. > > Any bug fix planned for the upcoming release should go to the > corresponding branch (e.g. `blender-v2.81-release`), followed by a > merge to `master`. > > Take your time to verify your fixes are correct and the commits look > good (as per usual). > > More detailed guidelines can be found on the wiki at: > https://wiki.blender.org/wiki/Process/Using_Stabilizing_Branch > > There will be a message to this list once the stabilizing branches > have been created. > > Cheers, > > /Nathan > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Committing fixes for releases in stabilizing branch.
thanks. On 11/10/2019 21:53, Brecht Van Lommel wrote: * Announcement email sent * source/tools now has blender-v2.81-release * Autoclose on release branch hopefully fixed, but it might not retroactively close tasks that were fixed already. That last point still needs some work I think? Did not have the opportunity to try in main repo, but commit https://developer.blender.org/rBA2476c0b4b2789e65f1ef95989d4e42dfd784be45 on addons should have shown on https://developer.blender.org/T69554, still no sign of it there after 2 hours… We accidentally had a merge of master into the release branch. I reverted that now, but we should add code on git.blender.org to prevent this. On Fri, Oct 11, 2019 at 8:25 PM Bastien Montagne wrote: Also, looks like phabricator needs some tweaking, it’s not catching bug fixes and other phab object references from commits to the release branch (e.g. https://developer.blender.org/rB1e5e65fa9f142440689c474dd6d924ab884c7efb for https://developer.blender.org/T70695). I know phab is sometimes slow to parse commits in new/quiet branches, but after 1h30 I think there is something else at play here. ;) On 11/10/2019 18:45, Bastien Montagne wrote: This has been very badly communicated so far! This mail is fine as "preparation", "warning" one. But now the branch has actually be created, without **any** message here? Seriously? We need an official "We entered BCon3 NOW, branch blender-v2.81-release has been created, all bug fixes whould now go to that branch" type of mail! Also, the tools sub-repo did not get its blender-v2.81-release branch, when it had one for 2.78, 2.79 and 2.80, any reason to break things here? The process is already pretty confusing, if communication is not handled properly we are going to get some really hectic moments… Confused cheers, Bastien On 10/10/2019 09:34, Nathan 'jesterKing' Letwory wrote: Hey all, Soon the stabilizing branches will be created. While not much will change, but there are a couple of things to keep in mind. Any bug fix planned for the upcoming release should go to the corresponding branch (e.g. `blender-v2.81-release`), followed by a merge to `master`. Take your time to verify your fixes are correct and the commits look good (as per usual). More detailed guidelines can be found on the wiki at: https://wiki.blender.org/wiki/Process/Using_Stabilizing_Branch There will be a message to this list once the stabilizing branches have been created. Cheers, /Nathan ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Committing fixes for releases in stabilizing branch.
* Announcement email sent * source/tools now has blender-v2.81-release * Autoclose on release branch hopefully fixed, but it might not retroactively close tasks that were fixed already. We accidentally had a merge of master into the release branch. I reverted that now, but we should add code on git.blender.org to prevent this. On Fri, Oct 11, 2019 at 8:25 PM Bastien Montagne wrote: > Also, looks like phabricator needs some tweaking, it’s not catching bug > fixes and other phab object references from commits to the release > branch (e.g. > https://developer.blender.org/rB1e5e65fa9f142440689c474dd6d924ab884c7efb > for https://developer.blender.org/T70695). > > I know phab is sometimes slow to parse commits in new/quiet branches, > but after 1h30 I think there is something else at play here. ;) > > On 11/10/2019 18:45, Bastien Montagne wrote: > > This has been very badly communicated so far! This mail is fine as > > "preparation", "warning" one. > > > > But now the branch has actually be created, without **any** message > > here? Seriously? We need an official "We entered BCon3 NOW, branch > > blender-v2.81-release has been created, all bug fixes whould now go to > > that branch" type of mail! > > > > Also, the tools sub-repo did not get its blender-v2.81-release branch, > > when it had one for 2.78, 2.79 and 2.80, any reason to break things here? > > > > The process is already pretty confusing, if communication is not > > handled properly we are going to get some really hectic moments… > > > > Confused cheers, > > Bastien > > > > On 10/10/2019 09:34, Nathan 'jesterKing' Letwory wrote: > >> Hey all, > >> > >> Soon the stabilizing branches will be created. While not much will > >> change, but there are a couple of things to keep in mind. > >> > >> Any bug fix planned for the upcoming release should go to the > >> corresponding branch (e.g. `blender-v2.81-release`), followed by a > >> merge to `master`. > >> > >> Take your time to verify your fixes are correct and the commits look > >> good (as per usual). > >> > >> More detailed guidelines can be found on the wiki at: > >> https://wiki.blender.org/wiki/Process/Using_Stabilizing_Branch > >> > >> There will be a message to this list once the stabilizing branches > >> have been created. > >> > >> Cheers, > >> > >> /Nathan > >> ___ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> https://lists.blender.org/mailman/listinfo/bf-committers > >> > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Committing fixes for releases in stabilizing branch.
Also, looks like phabricator needs some tweaking, it’s not catching bug fixes and other phab object references from commits to the release branch (e.g. https://developer.blender.org/rB1e5e65fa9f142440689c474dd6d924ab884c7efb for https://developer.blender.org/T70695). I know phab is sometimes slow to parse commits in new/quiet branches, but after 1h30 I think there is something else at play here. ;) On 11/10/2019 18:45, Bastien Montagne wrote: This has been very badly communicated so far! This mail is fine as "preparation", "warning" one. But now the branch has actually be created, without **any** message here? Seriously? We need an official "We entered BCon3 NOW, branch blender-v2.81-release has been created, all bug fixes whould now go to that branch" type of mail! Also, the tools sub-repo did not get its blender-v2.81-release branch, when it had one for 2.78, 2.79 and 2.80, any reason to break things here? The process is already pretty confusing, if communication is not handled properly we are going to get some really hectic moments… Confused cheers, Bastien On 10/10/2019 09:34, Nathan 'jesterKing' Letwory wrote: Hey all, Soon the stabilizing branches will be created. While not much will change, but there are a couple of things to keep in mind. Any bug fix planned for the upcoming release should go to the corresponding branch (e.g. `blender-v2.81-release`), followed by a merge to `master`. Take your time to verify your fixes are correct and the commits look good (as per usual). More detailed guidelines can be found on the wiki at: https://wiki.blender.org/wiki/Process/Using_Stabilizing_Branch There will be a message to this list once the stabilizing branches have been created. Cheers, /Nathan ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Committing fixes for releases in stabilizing branch.
This has been very badly communicated so far! This mail is fine as "preparation", "warning" one. But now the branch has actually be created, without **any** message here? Seriously? We need an official "We entered BCon3 NOW, branch blender-v2.81-release has been created, all bug fixes whould now go to that branch" type of mail! Also, the tools sub-repo did not get its blender-v2.81-release branch, when it had one for 2.78, 2.79 and 2.80, any reason to break things here? The process is already pretty confusing, if communication is not handled properly we are going to get some really hectic moments… Confused cheers, Bastien On 10/10/2019 09:34, Nathan 'jesterKing' Letwory wrote: Hey all, Soon the stabilizing branches will be created. While not much will change, but there are a couple of things to keep in mind. Any bug fix planned for the upcoming release should go to the corresponding branch (e.g. `blender-v2.81-release`), followed by a merge to `master`. Take your time to verify your fixes are correct and the commits look good (as per usual). More detailed guidelines can be found on the wiki at: https://wiki.blender.org/wiki/Process/Using_Stabilizing_Branch There will be a message to this list once the stabilizing branches have been created. Cheers, /Nathan ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
