You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is analogous to the autobisect feature but will also be useful for other issues.
Specifically what I have in mind is running the test against
[ last N stable branches ] x [ first nightly release, first stable release, latest stable release ]
Use cases:
It's sometimes unclear branches will need a fix backported. By testing against each supported branch, the answer to this can be automated and the baton can be handed to trop via labels. Human maintainers will not have to guess for the answer or spend time confirming the answer.
This operation could be re-run each time a new major branch goes stable s.t. all pre-existing issues could be updated (via a bugbot comment + labels) to reflect how the pre-existing issues fare under the new version.
bisect and autobisect assume that Electron's code flows in a linear path from older to newer releases, but this is not the case. Since we backport code to previous versions, it's possible that we could also backport a regression. Thus, a bug might not be present in 10.0.0, but exist in 10.2.0, not exist in 11.0.0, and exist in 11.1.0... if we ever hit this situation, bisection is going to bite us. Including the first version of a branch in the results will flag this situation if it arises.
TBD what N should be here. At a minimum it should be supported versions. Arguably it should be a few majors more than that to see when a regression was introduced. If we really want to get fancy we could even take the age of the bug into consideration, e.g. what version was the bug originally reported against. That policy outside of Fiddle's domain & would be decided in bugbot, so maybe N should be a command-line option.
The text was updated successfully, but these errors were encountered:
This is analogous to the autobisect feature but will also be useful for other issues.
Specifically what I have in mind is running the test against
[ last N stable branches ] x [ first nightly release, first stable release, latest stable release ]
Use cases:
It's sometimes unclear branches will need a fix backported. By testing against each supported branch, the answer to this can be automated and the baton can be handed to trop via labels. Human maintainers will not have to guess for the answer or spend time confirming the answer.
This operation could be re-run each time a new major branch goes stable s.t. all pre-existing issues could be updated (via a bugbot comment + labels) to reflect how the pre-existing issues fare under the new version.
bisect and autobisect assume that Electron's code flows in a linear path from older to newer releases, but this is not the case. Since we backport code to previous versions, it's possible that we could also backport a regression. Thus, a bug might not be present in 10.0.0, but exist in 10.2.0, not exist in 11.0.0, and exist in 11.1.0... if we ever hit this situation, bisection is going to bite us. Including the first version of a branch in the results will flag this situation if it arises.
TBD what
N
should be here. At a minimum it should be supported versions. Arguably it should be a few majors more than that to see when a regression was introduced. If we really want to get fancy we could even take the age of the bug into consideration, e.g. what version was the bug originally reported against. That policy outside of Fiddle's domain & would be decided in bugbot, so maybe N should be a command-line option.The text was updated successfully, but these errors were encountered: