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