I’ve been feeling for a while that tutor-contrib-grove has become a dumping ground for any customization that we need to make to our instances without any relevance or reliance on Grove.
Often times I feel like there is a small part of the grove plugin I want to use, for instance to override some config, but it comes with a tonne of additional stuff that I don’t want to set up. The reason I’ve been reluctant to post so far is that it’s still a pretty small package, and any migration is going to come with a cost; however, I might have a solution for an easier migration path.
I propose we split the grove tutor plugin into the following:
We could do all this in the existing grove tutor plugin repo by adding additional entrypoints so that the code is all together, however, each part of it can be individually enabled or disabled. The current grove entrypoint can be used to enable everything, while other entrypoints like grove-scaling, grove-mfes, grove-config etc can be individual enabled if only parts of the functionality are needed.
This way, existing deployments should continue working, while for local use you can enable the grove-config plugin to just override config and generally, you can enable only the bits of the plugin a client needs.
Does this seem like a worthwhile task? Does anyone else have the same issue?
I think too that it would be a great step forward. Either Bebop could do that in batches under the umbrella of a client task/epic (if it fits the scope/has a reason) or we could do it as part of SE-5827. However, SE-5827 is on hold as we have many more higher priority tasks.
@tikr from sustainability point of view, depending on the size of the task, would it be feasible for Bebop to execute this?
I agree with each of these points, in addition to these, there might be plugins that are doing these already so we might want to pay attention to that we shouldn’t do yak shaving, having said that I agree with the point you are putting forward. Kudos on that.
I started doing a bit of it to just use config overrides, and I’d say it would be roughly 10 hrs of work total at most, including review. It’s just refactoring, but we just need to make sure the grove wrapper continues working so no existing deployments break
Certainly, however that will require updating each deployment so it’s best to coordinate during an upgrade. As of now I’d want to make minimal changes just so we can do a refactor and be sure things work like before. Then we can deprecate and replace smaller bits in the future if needed.
@kshitij I think this can be a part of the task as well to figure out clients who are using these features and at least raise a PR for them. Some of them which have timely deployment can take time but others can be done as a part of the task. This will help us in situations where we have moved something from the contrib plugin and the client owner doesn’t know.
We ended up talking about this on Mattermost. The outcome was that:
We’ll temporarily put the Grove Maintenance epic (SE-5827) in progress and add tickets for completing this work to it.
Serenity will manage the epic while it’s in progress and Bebop will be doing the technical work. This will allow the work to get done sooner rather than later (Serenity doesn’t have capacity for the work right now while Bebop needs more work).
Once the work is complete we’ll put SE-5827 on hold again so Serenity can continue to focus on work that is higher priority than the remaining tasks from that epic.
Regarding sustainability:
Over the course of Q1-Q3 of this year, Serenity stayed on budget almost every month in terms of non-billable hours logged. So the cell has some spare hours from previous months that it can use to delegate some SE tickets to other cells.
Bebop also has some unused non-billable hours from the first three quarters of the year. So if necessary, some of the work that would be in scope here could be completed via BB tickets.