Rearchitect / Refactor MR Widget [Discovery]
What's this issue all about? (Background and context)
There is a proposal open to rearchitect the MR Widgets mergeability logic. Doing so will accomplish many goals, but we need to understand the best path forward technically.
The initial proposal suggests:
- Run mergeability checks one after the other with a success or failure response with details, which may require refactor work
- Different teams own these different checks, empowering code ownership
- Return this object to the frontend to display the errors, versus the method we use today
What hypotheses and/or assumptions do you have?
The assumption is that this work can be iterated upon so as to not introduce risk and/or breaking changes to the current way we have today. An additional assumption is that the proposal outlined is the best solution, and we are outlining what work that will entail.
What questions must be answered?
- Is the proposal the best solution for the problem? Should work begin on this topic?
- If this is not the best solution, what is?
- What technical work will need to happen in order to start iterating? In what order?
- What are the risks that we need to be aware of if we move forward?
What things will you need to investigate during the course of this issue?
-
... -
...
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.