Hi fellow OpenStackers,
The subject is the question I am posing. The general recommendation is to use Storyboard for new projects [1]. However, Storyboard does not seem to be receiving enough love recently [2] [3]. It's generally deemed as slow [4] 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. :-)
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.
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.
All in all, I ask you to consider recommending Launchpad again and encourage OpenStack projects to move to Launchpad.
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
-yoctozepto
On Thu, 2020-09-10 at 13:10 +0200, Radosław Piliszek wrote:
Hi fellow OpenStackers,
The subject is the question I am posing. The general recommendation is to use Storyboard for new projects [1]. However, Storyboard does not seem to be receiving enough love recently [2] [3]. It's generally deemed as slow [4] 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. :-)
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.
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.
All in all, I ask you to consider recommending Launchpad again and encourage OpenStack projects to move to Launchpad.
some porjects like nova and neutron never left launchpad and personally i had hopped they never would so that is still my preference but as far as i know there is notihgn preventing any project form move too or moving from launchpad as it stands.
if kolla* waht move they can without needing to change any other policies the cookie cutter templeate for seting up new repo also support both you can select it when you create the repo. im not sure what the default is currently but you are given the choice if i recall correctly.
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
-yoctozepto
Hi Sean,
On Thu, Sep 10, 2020 at 2:06 PM Sean Mooney smooney@redhat.com wrote:
On Thu, 2020-09-10 at 13:10 +0200, Radosław Piliszek wrote:
Hi fellow OpenStackers,
The subject is the question I am posing. The general recommendation is to use Storyboard for new projects [1]. However, Storyboard does not seem to be receiving enough love recently [2] [3]. It's generally deemed as slow [4] 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. :-)
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.
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.
All in all, I ask you to consider recommending Launchpad again and encourage OpenStack projects to move to Launchpad.
some porjects like nova and neutron never left launchpad and personally i had hopped they never would so that is still my preference but as far as i know there is notihgn preventing any project form move too or moving from launchpad as it stands.
Kolla did neither. We only have Kayobe that's on Storyboard (due to recommendation).
I did not want to sound like it was enforced. It is not - as far as I understand it.
The thing is: recommending a perceivably worse solution does not seem like a good idea to me. It also does not benefit the scene to split it between two worlds.
-yoctozepto
if kolla* waht move they can without needing to change any other policies the cookie cutter templeate for seting up new repo also support both you can select it when you create the repo. im not sure what the default is currently but you are given the choice if i recall correctly.
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
-yoctozepto
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.
Hi Jeremy,
First of all, thank you for the writeup, it is really helpful and contributes a lot to the discussion.
On Thu, Sep 10, 2020 at 5:59 PM Jeremy Stanley fungi@yuggoth.org wrote:
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.
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. :-) I feel this might be due to the audience Storyboard tries to cater to (larger cross-project work) which is not a common requirement (or rather just hard to organise for oneself).
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.
That would be awesome.
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."
Ouch, you are right. I should have picked my words more responsibly. I guess this was caused by one of longer sessions on Storyboard. I sincerely apologise and hope nobody was offended. As I wrote further below that line, I really appreciate Storyboard otherwise. It's just that it does not really shine compared to <insert practically any other competing issue tracking software here> these days.
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.
I know this issue a bit. Hard to make everyone like each other. As for Storyboard, since it still uses Ubuntu One for now, I could not obviously see that as counting in favour of Storyboard. :-)
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.
You are right there that we can't necessarily solve this for everyone. But at the moment it's confusing in that projects are partially there and partially elsewhere *because of the recommendation*. Obviously one can't do anything about escalation to libvirt/qemu/kernel bugzillas but those are external projects. For OpenStack projects we can have better guidelines.
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.
I could not express it better.
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.
I see how that could sound harsh as well. I meant its confusing effect rather than the need to disable Storyboard altogether and make it disappear, no.
All in all, I'd love to see Storyboard flourish as the approach appeals to me, just the UX is far from ideal at the moment. I meant this thread to be against the recommendation, not the software/instance itself. The recommendation introduced a feeling that Storyboard *should* be used, Launchpad is not really mentioned any longer either. To reiterate, I don't think it sounds like it *must* be used (and surely is not a requirement) but *should* is enough to cause bad experience for both sides (users trying to report and teams trying to keep track of reported issues).
-- Jeremy Stanley
On 2020-09-10 18:45:20 +0200 (+0200), Radosław Piliszek wrote: [...]
You are right there that we can't necessarily solve this for everyone. But at the moment it's confusing in that projects are partially there and partially elsewhere *because of the recommendation*. Obviously one can't do anything about escalation to libvirt/qemu/kernel bugzillas but those are external projects. For OpenStack projects we can have better guidelines.
Also, while maybe not the perfect solution, the code browser at https://opendev.org/openstack/nova has a prominent Issues link which takes you directly to their https://bugs.launchpad.net/nova page (for example).
[...]
I meant this thread to be against the recommendation, not the software/instance itself. The recommendation introduced a feeling that Storyboard *should* be used, Launchpad is not really mentioned any longer either. To reiterate, I don't think it sounds like it *must* be used (and surely is not a requirement) but *should* is enough to cause bad experience for both sides (users trying to report and teams trying to keep track of reported issues).
Yes, perhaps part of the disconnect here is that StoryBoard is one of the services provided by OpenDev so the OpenDev Manual is of course going to describe how to make use of it. We do also provide some Launchpad integration which warrants documenting, but as we don't actually run Launchpad we aren't going to maintain extensive documentation for the platform itself. On the other hand, the OpenStack Contributor Guide, OpenStack Project Teams Guide, or similar OpenStack-specific documentation certainly *can* document it in much greater detail if that's useful to the OpenStack community at large.
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.
If the project was to take such direction as to use this kind of non-free services, I probably would reconsider my involvement (which soon will reach 10 years of Debian packaging...).
Cheers,
Thomas Goirand (zigo)
On 2020-09-13 20:46:38 +0200 (+0200), Thomas Goirand 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.
[...]
To be fair, Launchpad is F/LOSS, just not that easy to run a copy of it yourself. Technically so is GitLab's community edition (not their enterprise edition nor their cloud SaaS), but yes the "open-core" situation there concerns me enough to not consider it.
On Sun, Sep 13, 2020 at 8:46 PM Thomas Goirand thomas@goirand.fr 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.
If the project was to take such direction as to use this kind of non-free services, I probably would reconsider my involvement (which soon will reach 10 years of Debian packaging...).
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.
-yoctozepto
Cheers,
Thomas Goirand (zigo)
On 9/14/20 8:59 AM, Radosław Piliszek wrote:
On Sun, Sep 13, 2020 at 8:46 PM Thomas Goirand thomas@goirand.fr 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.
The fact that many projects are using these non-free services to produce free software is actually a problem, not a solution. 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.
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.
Cheers,
Thomas Goirand (zigo)
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@goirand.fr 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. https://github.com/MichaelMure/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 ectra.
Cheers,
Thomas Goirand (zigo)
On 2020-09-14 11:47:59 +0100 (+0100), Sean Mooney wrote: [...]
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 :) )
[...]
https://pypi.org/project/boartty/
Also, I agree. Using Git as a database (maybe like Gerrit does with its NoteDB) and base data exchange protocol is an intriguing idea, though makes me wonder how private stories would be handled if the idea is to be able to clone/fetch the stories and tasks.
well the programing lanugages that it is written in provides an impediment to that if it was python based
StoryBoard (the actual API service) is written entirely in Python.
or used a maintained framework then contibuting would be a lot simpler.
[...]
The Web framework used for the StoryBoard Web Client is indeed showing its age. It was originally chosen to coincide with a proposed Horizon revamp years ago, but hasn't been updated (we'd love some help there if people familiar with AngularJS are interested in pitching in on it).
participants (5)
-
Jeremy Stanley
-
Radosław Piliszek
-
Sean Mooney
-
Thomas Goirand
-
Thomas Goirand