[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Is Storyboard really the future?

On Mon, 2020-09-14 at 09:22 +0200, Thomas Goirand wrote:
> On 9/14/20 8:59 AM, RadosÅ?aw Piliszek wrote:
> > On Sun, Sep 13, 2020 at 8:46 PM Thomas Goirand <thomas at> wrote:
> > > 
> > > On 9/10/20 6:45 PM, RadosÅ?aw Piliszek wrote:
> > > > I feel you. I could not so far convince anyone to support me to work
> > > > on it, mostly because
> > > > Jira/GitHub/GitLab/Launchpad exists.
> > > > Not to mention many small internal projects are happy with just Trello. :-)
> > > 
> > > Did you just try to list all the non-free services you could in this
> > > thread? Seriously, don't you care a little bit? You probably don't
> > > realize it, but that's shocking, at least for me, and hopefully I'm not
> > > the only one.
> > 
> > I feel offended by the accusations.
> > I *do* care about open source.
> > 
> > Jeremy has already answered regarding GitLab and Launchpad.
> > Let's not forget GitHub actually *is* the largest, diverse open source
> > community,
> > even though the service itself is not. It hurts me as well so please don't just
> > randomly attack people mentioning non-free software.
> > It can support open source software as well.
> You're the one mentioning Jira, GitHub, Trello as possible solution to
> solve the fact that you don't like Storyboard. This is IMO very far from
> the spirit of free software. Sorry if you took it as a personal attack:
> there's nothing personal here, just a strong opposition to using this
> kind of services.
for what its worth i read it as a personal attack or at least a very agressive stance
openstack has used github as a mirror and marketing vector for a very long time.
we still use launchpad for many project which is opensouce even if other have mentioned it
is also hard to run.  jira and trello are solution that many ues even redhat uses both
and we also use gilab, github and bugzilla. the fact is that there ofteen isnt one tool that 
works for everyone.  that said one tool that is opensouce that i have been wanting to try for
a while which might be another alternitive is git-bug.
unfortunetly the webui is basically non existant and it would force eveyoen to use a git workflow
submit bugs which is not ideal given the userbase and our gerrit workflow.
but one day it would be nice to have a terminal interface and git workflow for this 
( and everything, life in the terminal is less scary then on the web :) )
> The fact that many projects are using these non-free services to produce
> free software is actually a problem, not a solution.
that is a stance that easily offends and alienates contibutors.
a tool is something the helps you complete a task. we can use opensouce or free
or paid tools, im fine with a preference for using opensouce tools when it becomes
religious and the only morally accptable thing to do i think that is problematic.
part fo the reason i still work on openstack is its apach2 licene and the fact
it has never taken and extreamist everything we use and touch must be opensouce approch.

we practice open dev and the 4 opens is an important part of openstack cluture but
branding all proprity software as evil is not part of that culture. we support integrations
with hyperv, vmware and more propitroy storage and network backends then i can count.
openstack is an example of open core done right where everything is open by default and then
you can as a thirdparty vendor replace exsiting compents with your closed impementation
but all feature are provided in the core and in the opensource release.

anyway i think this is proably going a little more off topic.

>  Same for Github
> being (probably) the largest repository of free software: that's a huge
> problem, as huge as the number of projects hosted. Lucky, many just
> think of it as just free hosting and nothing more.
> Gitlab being open-core, as Jeremy pointed out, is also a problem (anyone
> that knows about the beginning of OpenStack and Eucalyptus knows why
> open core is problematic).
> > I did not propose that in any part. Launchpad is FLOSS and that is my proposal.
> > The general idea behind my mail was to emphasise that Storyboard has
> > great aspirations
> > and assumptions but is far from delivering its full potential so
> > should not be recommended without
> > giving background and other possible solutions.
> Launchpad is hardly installable, and is tightly connected to
> Canonical/Ubuntu. It is a very good thing that the OpenStack community
> has made efforts to get out of it. It is IMO counter-productive to push
> projects to either go back to launchpad, or not migrate to Storyboard.
well as someone that previously worked at intel and now works at redhat i have
no porblem using launchpad, in fact i prefer it stongly over storyboard and bugzilla
which is what we use for many downstream products. if  i was forced to use storyboard
for the project i contibute too i would not do any bug triage and i would avoid interacting
with it for my own work as much as possible. the only way to improve storyboard to be a useful
tool from my usecases is to rewrite it to provide a similar work flow to launchpad and jiria.
maybe not exclviely but it really need to have a set of dashboard and a non search driven workflow
like launchpad.
> The only viable solution is to contribute and make Storyboard better, or
> switching to another existing free software. There are many out there
> that could have done the job.
well the programing lanugages that it is written in provides an impediment to that
if it was python based or used a maintained framework then contibuting would be a lot simpler.
i think the orginal intent of the email was to stop recommending that new project adopt a tool
that has a different paridam of interaction then  most people are used too. the story task approch
works in project where features and bugfixes can land at any time in the cycle or are more interupt driven
it a challanging user experince for project like nova that have a more tradtional propose (blueprint/bug)
design resoltion then implement code workflow with fixed milestoens and different cut offs to for spec vs code

> Cheers,
> Thomas Goirand (zigo)