Storyboard Needs and Alternatives
Clark Boylan
cboylan at sapwetik.org
Tue Nov 29 01:14:20 UTC 2022
On Tue, Oct 25, 2022, at 10:19 AM, Clark Boylan wrote:
> Hello,
>
> There have apparently been disparate discussions among different
> projects on whether or not they want to continue using Storyboard and
> what alternatives they should consider. Having these discussion is
> healthy, but I think we should try to have them in the open with a
> broad audience to ensure we've considered all the various moving parts
> involved. I'll do my best to kick start that discussion here in this
> thread.
>
snip
>
> The goal here isn't to try and convince anyone they should use
> Storyboard. Instead we're trying to understand if there are those that
> would like to keep using Storyboard, and if so, what effort would be
> necessary to make that possible. Once we've sorted this out we can have
> a followup discussion on what would be necessary to support projects
> that don't want to use Storyboard any longer.
Its been a month since I kicked this discussion off. Since then we've had good feedback on struggles with using Storyboard. We've also heard from some projects that consistency of tooling is useful to them which is part of their motivation for migrating away from Storyboard.
What we haven't heard from is anyone motivated to help maintain the deployment of Storyboard or the Storyboard software itself. I think this puts OpenDev in an awkward position. Storyboard was built to try and address OpenStack's specific needs around issue tracking. Unfortunately, it also seems clear that Storyboard isn't currently meeting those needs for various reasons, and OpenStack isn't stepping up to try and address that. Currently that means OpenDev is an adoptive parent for the project and is clearly not doing a good enough job to keep the service happy.
Where does that leave OpenDev? I think we have a few potential options for improving the status quo:
* Properly adopt storyboard. Make updating the deployment of storyboard
a priority and take on maintenance of the software itself to try and
address the issues that have been called out that are not already fixed.
This option is unlikely to be successful without help, and we haven't seen
any new interest in helping. We would also likely need to help those
looking to move regardless of this changes of focus. Which creates
an overlap with the next option.
* Migrate Storyboard users to another tool and shutdown Storyboard. This
option is not without costs either. We'll have to determine how much data
preservation is necessary either by creating some sort of read only
archive or migrating data from Storyboard into whatever new system is
chosen. We would also need to determine what to migrate to and do any
necessary work to ensure that service is running.
* Many of our users continue to use launchpad and a number of the
discussions at the PTG were around moving from stroyboard to LP.
This may be an easy option, and possibly the desired option for many
given the discussion at the PTG.
* Some have suggested using Gitea. While this is theoretically possible
there needs to be investigation, testing, and planning to update our
Gitea deployment properly to support this. In particular our Gitea
deployment is actually 8 independent read only Giteas. Because issues
would require authentication and writing content to Gitea we would
need to sort that out with a Gitea cluster via updating deployment.
Also, we can fairly easily get away with disabling Gitea functionality
that we do not want enabled (pull requests, packages, etc) when it
is installed as a read only system, but that is potentially more difficult
once users can write to the system. Theoretically possible but
will require someone to do a fair bit of engineering work.
* Insert your ideas here.
None of these options are going to make everyone happy, and all of them present non zero effort on our part. I don't have a strong opinion yet on what our best option is and would love to hear thoughts from those who may have other ideas or interest in a specific option.
Clark
More information about the service-discuss
mailing list