Open Stack

On 2020-09-10 13:10:44 +0200 (+0200), Radosław Piliszek wrote:
> The subject is the question I am posing. The general
> recommendation is to use Storyboard for new projects [1].

I agree that recommending a service without context is likely to
cause problems. StoryBoard is a service provided within OpenDev, and
I don't think we anticipate stopping to provide that service to
projects who wish to make use of it. Its use is not at all
mandatory. The deployment of it in OpenDev is at least minimally
functional and sufficient for light duty, though I understand people
who are in a situation of needing to interact with their defect and
task trackers constantly likely find some aspects of it frustrating.

> However, Storyboard does not seem to be receiving enough love
> recently [2] [3].

Yep, nobody works on it full-time and it could use some additional
developers, reviewers and sysadmins to help regain momentum. For
example, I could use some help figuring out fine-grained user
permissions for Rackspace's Swift-like object store, which is
currently blocking more effective vetting of the proposed
client-side support for Adam's story attachments work. We would also
love assistance getting the current Puppet module we're managing our
deployment with replaced by Ansible/docker-compose orchestration of
the container images we've started publishing to DockerHub. Even
just helping us triage and tag new stories for opendev/storyboard
and opendev/storyboard-webclient would be appreciated.

> It's generally deemed as slow [4]

Preliminary testing suggests https://review.opendev.org/742046 will
increase performance for the queries behind most common views by an
order of magnitude or more.

> and is missing quite a few usability enhancements [2]. Considering
> the alternative, and the actual previous recommendation, is
> Launchpad, I find it no-brainer to revert to recommending
> Launchpad still, even paving a way for projects wishing to escape
> the Storyboard nightmare. :-)

The smiley doesn't particularly soften the fact that you just rudely
referred to the product of someone's hard work and volunteered time
as a "nightmare."

One problem we were hoping to solve which Launchpad doesn't help us
with is that we have a number of potential contributors and users
who have balked at collaborating through OpenDev because our
services require them to have an "Ubuntu" login even though they're
not users of (and perhaps work for rivals/competitors of) that
distro. Once our Central Auth/SSO spec reaches implementation, being
able to offer some sort of cross-project task and defect tracking
integrated with our Gerrit code reviews, and using the same
authentication, gives projects who want to not require members of
their communities to have an UbuntuOne account that option.

> Don't get me wrong, I really like the Story/Task orientation but
> Storyboard results in a frustrating experience. In addition to
> being slow, it has issues with search/filter, sorting and
> pagination which make issue browsing an utter pain. I know
> Launchpad is not without issues but it's certainly a much better
> platform at the moment. And many projects are still there.

Again, I think Launchpad is a fine platform for some projects. It's
designed around bug tracking for packaging work targeting various
Ubuntu releases, but that doesn't mean it can't also be used
effectively for other sorts of activities (as evidenced by the many
software projects who do). They've recently improved their
development environment setup and build instructions too, so working
on a patch to fix something there isn't nearly as challenging as it
once was. If you use Launchpad and want to improve some aspect of
it, I wholeheartedly encourage you to try to collaborate with its
maintainers on that. And if projects want to move to (or back to)
Launchpad, I don't have a problem with that and am happy to get them
database exports of their SB stories and tasks... I think we can
just set the corresponding project entries to inactive so they can't
be selected for new tasks, though that will need a bit of testing to
confirm.

> The Launchpad-Storyboard split is also introducing confusion for
> users [5] and coordinability issues for teams as we need to
> cross-link manually to get proper visibility.

I'm not entirely convinced. Users are going to be confused and
sometimes open bugs in the wrong places regardless. Back when the
OpenStack Infra team existed and had a catch-all LP project for
tracking infrastructure-related issues and incidents, users often
got equally confused and opened Nova bugs under that. They also
still constantly wander into the #openstack-infra IRC channel asking
us how to run OpenStack. Turning off StoryBoard won't solve that.
Honestly, I doubt anything will (or even can) solve that. As for
cross-linking, you have to do that today if someone mistakenly opens
a Nova bug which turns out to be a Qemu or KVM issue instead. It's
unrealistic to expect all F/LOSS projects to use one common tracker.

> All in all, I ask you to consider recommending Launchpad again and
> encourage OpenStack projects to move to Launchpad.

I agree we shouldn't be recommending StoryBoard over other platforms
without providing some context as to when projects might consider
using it. I also won't attempt to dissuade anyone who wants to move
their tracking to other open source based services like (but not
necessarily limited to) Launchpad. Different projects have different
needs and no one work management tool is going to satisfy everyone.

> Extra note: I find it in a similar spot as ask.o.o - nice it has been
> tried, but unfortunately it did not stand the test of time.
> 
> [1] https://docs.opendev.org/opendev/infra-manual/latest/creators.html
> [2] https://storyboard.openstack.org/#!/project/opendev/storyboard
> [3] https://opendev.org/opendev/storyboard/commits/branch/master
> [4] https://storyboard.openstack.org/#!/story/2007829
> [5] https://storyboard.openstack.org/#!/story/2000890

I don't personally think it's quite the same situation as Ask
OpenStack, though I can see where you might draw parallels.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200910/a4c57162/attachment.sig>