Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo
Octavia relies heavily on Taskflow and Futurist as well. Personally I agree with basically everything Monty said earlier. The problem here really isn't anything besides relaxing the social review policy, which is as simple as just deciding it as a team and saying "well, ok then". :) I also use a number of openstack libs outside of openstack to great effect and have had no problems to speak of, so I don't really think this should be a concern. I know it can be daunting to first enter the dev/review process because it is so different from the workflow most people are used to, but this is a problem that can be solved by having good docs (I think the existing developer quickstart docs are very effective) and maintaining an open and welcoming community. --Adam On Thu, Oct 18, 2018, 16:32 Dmitry Tantsur wrote: > On 10/17/18 5:59 PM, Joshua Harlow wrote: > > Dmitry Tantsur wrote: > >> On 10/10/18 7:41 PM, Greg Hill wrote: > >>> I've been out of the openstack loop for a few years, so I hope this > >>> reaches the right folks. > >>> > >>> Josh Harlow (original author of taskflow and related libraries) and I > >>> have been discussing the option of moving taskflow out of the > >>> openstack umbrella recently. This move would likely also include the > >>> futurist and automaton libraries that are primarily used by taskflow. > >> > >> Just for completeness: futurist and automaton are also heavily relied on > >> by ironic without using taskflow. > > > > When did futurist get used??? nice :) > > > > (I knew automaton was, but maybe I knew futurist was to and I forgot, > lol). > > I'm pretty sure you did, it happened back in Mitaka :) > > > > >> > >>> The idea would be to just host them on github and use the regular > >>> Github features for Issues, PRs, wiki, etc, in the hopes that this > >>> would spur more development. Taskflow hasn't had any substantial > >>> contributions in several years and it doesn't really seem that the > >>> current openstack devs have a vested interest in moving it forward. I > >>> would like to move it forward, but I don't have an interest in being > >>> bound by the openstack workflow (this is why the project stagnated as > >>> core reviewers were pulled on to other projects and couldn't keep up > >>> with the review backlog, so contributions ground to a halt). > >>> > >>> I guess I'm putting it forward to the larger community. Does anyone > >>> have any objections to us doing this? Are there any non-obvious > >>> technicalities that might make such a transition difficult? Who would > >>> need to be made aware so they could adjust their own workflows? > >>> > >>> Or would it be preferable to just fork and rename the project so > >>> openstack can continue to use the current taskflow version without > >>> worry of us breaking features? > >>> > >>> Greg > >>> > >>> > >>> > __ > >>> > >>> OpenStack Development Mailing List (not for usage questions) > >>> Unsubscribe: > >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>> > >> > >> > >> > __ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo
On 10/17/18 5:59 PM, Joshua Harlow wrote: Dmitry Tantsur wrote: On 10/10/18 7:41 PM, Greg Hill wrote: I've been out of the openstack loop for a few years, so I hope this reaches the right folks. Josh Harlow (original author of taskflow and related libraries) and I have been discussing the option of moving taskflow out of the openstack umbrella recently. This move would likely also include the futurist and automaton libraries that are primarily used by taskflow. Just for completeness: futurist and automaton are also heavily relied on by ironic without using taskflow. When did futurist get used??? nice :) (I knew automaton was, but maybe I knew futurist was to and I forgot, lol). I'm pretty sure you did, it happened back in Mitaka :) The idea would be to just host them on github and use the regular Github features for Issues, PRs, wiki, etc, in the hopes that this would spur more development. Taskflow hasn't had any substantial contributions in several years and it doesn't really seem that the current openstack devs have a vested interest in moving it forward. I would like to move it forward, but I don't have an interest in being bound by the openstack workflow (this is why the project stagnated as core reviewers were pulled on to other projects and couldn't keep up with the review backlog, so contributions ground to a halt). I guess I'm putting it forward to the larger community. Does anyone have any objections to us doing this? Are there any non-obvious technicalities that might make such a transition difficult? Who would need to be made aware so they could adjust their own workflows? Or would it be preferable to just fork and rename the project so openstack can continue to use the current taskflow version without worry of us breaking features? Greg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo
Dmitry Tantsur wrote: On 10/10/18 7:41 PM, Greg Hill wrote: I've been out of the openstack loop for a few years, so I hope this reaches the right folks. Josh Harlow (original author of taskflow and related libraries) and I have been discussing the option of moving taskflow out of the openstack umbrella recently. This move would likely also include the futurist and automaton libraries that are primarily used by taskflow. Just for completeness: futurist and automaton are also heavily relied on by ironic without using taskflow. When did futurist get used??? nice :) (I knew automaton was, but maybe I knew futurist was to and I forgot, lol). The idea would be to just host them on github and use the regular Github features for Issues, PRs, wiki, etc, in the hopes that this would spur more development. Taskflow hasn't had any substantial contributions in several years and it doesn't really seem that the current openstack devs have a vested interest in moving it forward. I would like to move it forward, but I don't have an interest in being bound by the openstack workflow (this is why the project stagnated as core reviewers were pulled on to other projects and couldn't keep up with the review backlog, so contributions ground to a halt). I guess I'm putting it forward to the larger community. Does anyone have any objections to us doing this? Are there any non-obvious technicalities that might make such a transition difficult? Who would need to be made aware so they could adjust their own workflows? Or would it be preferable to just fork and rename the project so openstack can continue to use the current taskflow version without worry of us breaking features? Greg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo
On Mon, Oct 15, 2018 at 04:27:00PM -0500, Monty Taylor wrote: > On 10/15/2018 05:49 AM, Stephen Finucane wrote: > > On Wed, 2018-10-10 at 18:51 +, Jeremy Stanley wrote: > > > On 2018-10-10 13:35:00 -0500 (-0500), Greg Hill wrote: > > > [...] > > > > We plan to still have a CI gatekeeper, probably Travis CI, to make sure > > > > PRs > > > > past muster before being merged, so it's not like we're wanting to > > > > circumvent good contribution practices by committing whatever to HEAD. > > > > > > Travis CI has gained the ability to prevent you from merging changes > > > which fail testing? Or do you mean something else when you refer to > > > it as a "gatekeeper" here? > > > > Yup but it's GitHub feature rather than specifically a Travis CI > > feature. > > > >https://help.github.com/articles/about-required-status-checks/ > > > > Doesn't help the awful pull request workflow but that's neither here > > nor there. > > It's also not the same as gating. > > The github feature is the equivalent of "Make sure the votes in check are > green before letting someone click the merge button" > > The zuul feature is "run the tests between the human decision to merge and > actually merging with the code in the state it will actually be in when > merged". > > It sounds nitpicky, but the semantic distinction is important - and it > catches things more frequently than you might imagine. > > That said - Zuul supports github, and there are Zuuls run by not-openstack, > so taking a project out of OpenStack's free infrastructure does not mean you > have to also abandon Zuul. The OpenStack Infra team isn't going to run a > zuul to gate patches on a GitHub project - but other people might be happy > to let you use a Zuul so that you don't have to give up the Zuul features in > place today. If you go down that road, I'd suggest pinging the > softwarefactory-project.io folks or the openlab folks. > As somebody who has recently moved from a gerrit workflow to a github workflow using Zuul, keep in mind this is not a 1:1 feature map. The biggest difference, as people have said, is code review in github.com is terrible. It was something added after the fact, I wish daily to be able to use gerrit again :) Zuul does make things better, and 100% with Monty here. You want Zuul to be the gate, not travis CI. - Paul __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo
On 10/10/2018 03:17 PM, Ben Nemec wrote: On 10/10/18 1:35 PM, Greg Hill wrote: I'm not sure how using pull requests instead of Gerrit changesets would help "core reviewers being pulled on to other projects"? The 2 +2 requirement works for larger projects with a lot of contributors. When you have only 3 regular contributors and 1 of them gets pulled on to a project and can no longer actively contribute, you have 2 developers who can +2 each other but nothing can get merged without that 3rd dev finding time to add another +2. This is what happened with Taskflow a few years back. Eventually the other 2 gave up and moved on also. As the others have mentioned, this doesn't need to continue to be a blocker. If the alternative is nobody working on the project at all, a single approver policy is far better. In practice it's probably not much different from having a general oslo core rubber stamp +2 a patch that was already reviewed by a taskflow expert. Just piling on on this. We do single-core approves in openstacksdk, although for REALLY hairy patches I try to get a few more people to get eyeballs on something. Is this just about preferring not having a non-human gatekeeper like Gerrit+Zuul and being able to just have a couple people merge whatever they want to the master HEAD without needing to talk about +2/+W rights? We plan to still have a CI gatekeeper, probably Travis CI, to make sure PRs past muster before being merged, so it's not like we're wanting to circumvent good contribution practices by committing whatever to HEAD. But the +2/+W rights thing was a huge PITA to deal with with so few contributors, for sure. I guess this would be the one concern I'd have about moving it out. We still have a fair number of OpenStack projects depending on taskflow[1] to one degree or another, and having taskflow fully integrated into the OpenStack CI system is nice for catching problems with proposed changes early. I second this. Especially for a library like taskflow where the value is in the behavior engine, describing that as an API with an API surface is a bit harder than just testing a published library interface. It's also worth noting that we're working on plans to get the OpenStack Infra systems rebranded so that concerns people might have about brand association can be mitigated. I think there was some work recently to get OpenStack CI voting on Github, but it seems inefficient to do work to move it out of OpenStack and then do more work to partially bring it back. Zuul supports cross-source dependencies and we have select github repos configured in OpenStack's Zuul so that projects can do cross-project verification. I suppose the other option is to just stop CI'ing on OpenStack and rely on the upper-constraints gating we do for our other dependencies. That would be unfortunate, but again if the alternative is no development at all then it might be a necessary compromise. I agree - if the main roadblock is just the 2x+2 policy, which is solvable without moving anything, then the pain of moving the libraries out to github just to turn around and cobble together a cross-source advisory testing system seems not very worth it and I'd be more inclined to use upper-constraints. By and large moving these is going to be pretty disruptive, so I'd personally prefer that they stayed where they. There are PLENTY of things hosted in OpenStack's infrastructure that are not OpenStack - or even OpenStack specific. 1: http://codesearch.openstack.org/?q=taskflow=nope=requirements.txt= If it's just about preferring the pull request workflow versus the Gerrit rebase workflow, just say so. Same for just preferring the Github UI versus Gerrit's UI (which I agree is awful). I mean, yes, I personally prefer the Github UI and workflow, but that was not a primary consideration. I got used to using gerrit well enough. It was mostly the There's also a sense that if a project is in the Openstack umbrella, it's not useful outside Openstack, and Taskflow is designed to be a general purpose library. The hope is that just making it a regular open source project might attract more users and contributors. I think we might be intertwining a few things that don't have to be intertwined. The libraries are currently part of the OpenStack umbrella, and as part of that are hosted in OpenStack's developer infrastructure. They can remain "part of OpenStack" and be managed with a relaxed core reviewer policy. This way, should they be desired, things like the release management team can still be used. They can cease being "part of OpenStack" without needing to move away from the OpenStack Developer Infrastructure. As I mentioned earlier we're working on rebranding the Developer Infrastructure, so if there is a concern that a git repo existing within the Developer Infrastructure implies being "part of
Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo
On 10/15/2018 05:49 AM, Stephen Finucane wrote: On Wed, 2018-10-10 at 18:51 +, Jeremy Stanley wrote: On 2018-10-10 13:35:00 -0500 (-0500), Greg Hill wrote: [...] We plan to still have a CI gatekeeper, probably Travis CI, to make sure PRs past muster before being merged, so it's not like we're wanting to circumvent good contribution practices by committing whatever to HEAD. Travis CI has gained the ability to prevent you from merging changes which fail testing? Or do you mean something else when you refer to it as a "gatekeeper" here? Yup but it's GitHub feature rather than specifically a Travis CI feature. https://help.github.com/articles/about-required-status-checks/ Doesn't help the awful pull request workflow but that's neither here nor there. It's also not the same as gating. The github feature is the equivalent of "Make sure the votes in check are green before letting someone click the merge button" The zuul feature is "run the tests between the human decision to merge and actually merging with the code in the state it will actually be in when merged". It sounds nitpicky, but the semantic distinction is important - and it catches things more frequently than you might imagine. That said - Zuul supports github, and there are Zuuls run by not-openstack, so taking a project out of OpenStack's free infrastructure does not mean you have to also abandon Zuul. The OpenStack Infra team isn't going to run a zuul to gate patches on a GitHub project - but other people might be happy to let you use a Zuul so that you don't have to give up the Zuul features in place today. If you go down that road, I'd suggest pinging the softwarefactory-project.io folks or the openlab folks. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo
I'm ok with trying this move out and seeing how it goes (maybe it will be for the better, idk). -Josh On 10/10/2018 10:41 AM, Greg Hill wrote: I've been out of the openstack loop for a few years, so I hope this reaches the right folks. Josh Harlow (original author of taskflow and related libraries) and I have been discussing the option of moving taskflow out of the openstack umbrella recently. This move would likely also include the futurist and automaton libraries that are primarily used by taskflow. The idea would be to just host them on github and use the regular Github features for Issues, PRs, wiki, etc, in the hopes that this would spur more development. Taskflow hasn't had any substantial contributions in several years and it doesn't really seem that the current openstack devs have a vested interest in moving it forward. I would like to move it forward, but I don't have an interest in being bound by the openstack workflow (this is why the project stagnated as core reviewers were pulled on to other projects and couldn't keep up with the review backlog, so contributions ground to a halt). I guess I'm putting it forward to the larger community. Does anyone have any objections to us doing this? Are there any non-obvious technicalities that might make such a transition difficult? Who would need to be made aware so they could adjust their own workflows? Or would it be preferable to just fork and rename the project so openstack can continue to use the current taskflow version without worry of us breaking features? Greg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo
On 10/10/18 7:41 PM, Greg Hill wrote: I've been out of the openstack loop for a few years, so I hope this reaches the right folks. Josh Harlow (original author of taskflow and related libraries) and I have been discussing the option of moving taskflow out of the openstack umbrella recently. This move would likely also include the futurist and automaton libraries that are primarily used by taskflow. Just for completeness: futurist and automaton are also heavily relied on by ironic without using taskflow. The idea would be to just host them on github and use the regular Github features for Issues, PRs, wiki, etc, in the hopes that this would spur more development. Taskflow hasn't had any substantial contributions in several years and it doesn't really seem that the current openstack devs have a vested interest in moving it forward. I would like to move it forward, but I don't have an interest in being bound by the openstack workflow (this is why the project stagnated as core reviewers were pulled on to other projects and couldn't keep up with the review backlog, so contributions ground to a halt). I guess I'm putting it forward to the larger community. Does anyone have any objections to us doing this? Are there any non-obvious technicalities that might make such a transition difficult? Who would need to be made aware so they could adjust their own workflows? Or would it be preferable to just fork and rename the project so openstack can continue to use the current taskflow version without worry of us breaking features? Greg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo
On Wed, 10 Oct 2018, Greg Hill wrote: I guess I'm putting it forward to the larger community. Does anyone have any objections to us doing this? Are there any non-obvious technicalities that might make such a transition difficult? Who would need to be made aware so they could adjust their own workflows? I've been on both sides of conversations like this a few different times. Generally speaking people who are not already in the OpenStack environment express an unwillingness to participate because of perceptions of walled-garden and too-many-hoops. Whatever the reality of the situation, those perceptions matter, and for libraries that are already or potentially useful to people who are not in OpenStack, being "outside" is probably beneficial. And for a library that is normally installed (or should optimally be installed because, really, isn't it nice to be decoupled?) via pip, does it matter to OpenStack where it comes from? Or would it be preferable to just fork and rename the project so openstack can continue to use the current taskflow version without worry of us breaking features? Fork sounds worse. I've had gabbi contributors tell me, explicitly, that they would not bother contributing if they had to go through what they perceive to be the OpenStack hoops. That's anecdata, but for me it is pretty compelling. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo
On Wed, 2018-10-10 at 18:51 +, Jeremy Stanley wrote: > On 2018-10-10 13:35:00 -0500 (-0500), Greg Hill wrote: > [...] > > We plan to still have a CI gatekeeper, probably Travis CI, to make sure PRs > > past muster before being merged, so it's not like we're wanting to > > circumvent good contribution practices by committing whatever to HEAD. > > Travis CI has gained the ability to prevent you from merging changes > which fail testing? Or do you mean something else when you refer to > it as a "gatekeeper" here? Yup but it's GitHub feature rather than specifically a Travis CI feature. https://help.github.com/articles/about-required-status-checks/ Doesn't help the awful pull request workflow but that's neither here nor there. Stephen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo
On 10/10/18 1:35 PM, Greg Hill wrote: I'm not sure how using pull requests instead of Gerrit changesets would help "core reviewers being pulled on to other projects"? The 2 +2 requirement works for larger projects with a lot of contributors. When you have only 3 regular contributors and 1 of them gets pulled on to a project and can no longer actively contribute, you have 2 developers who can +2 each other but nothing can get merged without that 3rd dev finding time to add another +2. This is what happened with Taskflow a few years back. Eventually the other 2 gave up and moved on also. As the others have mentioned, this doesn't need to continue to be a blocker. If the alternative is nobody working on the project at all, a single approver policy is far better. In practice it's probably not much different from having a general oslo core rubber stamp +2 a patch that was already reviewed by a taskflow expert. Is this just about preferring not having a non-human gatekeeper like Gerrit+Zuul and being able to just have a couple people merge whatever they want to the master HEAD without needing to talk about +2/+W rights? We plan to still have a CI gatekeeper, probably Travis CI, to make sure PRs past muster before being merged, so it's not like we're wanting to circumvent good contribution practices by committing whatever to HEAD. But the +2/+W rights thing was a huge PITA to deal with with so few contributors, for sure. I guess this would be the one concern I'd have about moving it out. We still have a fair number of OpenStack projects depending on taskflow[1] to one degree or another, and having taskflow fully integrated into the OpenStack CI system is nice for catching problems with proposed changes early. I think there was some work recently to get OpenStack CI voting on Github, but it seems inefficient to do work to move it out of OpenStack and then do more work to partially bring it back. I suppose the other option is to just stop CI'ing on OpenStack and rely on the upper-constraints gating we do for our other dependencies. That would be unfortunate, but again if the alternative is no development at all then it might be a necessary compromise. 1: http://codesearch.openstack.org/?q=taskflow=nope=requirements.txt= If it's just about preferring the pull request workflow versus the Gerrit rebase workflow, just say so. Same for just preferring the Github UI versus Gerrit's UI (which I agree is awful). I mean, yes, I personally prefer the Github UI and workflow, but that was not a primary consideration. I got used to using gerrit well enough. It was mostly the There's also a sense that if a project is in the Openstack umbrella, it's not useful outside Openstack, and Taskflow is designed to be a general purpose library. The hope is that just making it a regular open source project might attract more users and contributors. This may or may not bear out, but as it is, there's no real benefit to staying an openstack project on this front since nobody is actively working on it within the community. Greg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo
On 10/10/2018 12:41 PM, Greg Hill wrote: > I've been out of the openstack loop for a few years, so I hope this > reaches the right folks. > > Josh Harlow (original author of taskflow and related libraries) and I > have been discussing the option of moving taskflow out of the openstack > umbrella recently. This move would likely also include the futurist and > automaton libraries that are primarily used by taskflow. The idea would > be to just host them on github and use the regular Github features for > Issues, PRs, wiki, etc, in the hopes that this would spur more > development. Taskflow hasn't had any substantial contributions in > several years and it doesn't really seem that the current openstack devs > have a vested interest in moving it forward. I would like to move it > forward, but I don't have an interest in being bound by the openstack > workflow (this is why the project stagnated as core reviewers were > pulled on to other projects and couldn't keep up with the review > backlog, so contributions ground to a halt). > > I guess I'm putting it forward to the larger community. Does anyone have > any objections to us doing this? Are there any non-obvious > technicalities that might make such a transition difficult? Who would > need to be made aware so they could adjust their own workflows? The PowerVM nova virt driver uses taskflow (and we love it, btw). So we do need to be kept apprised of any movement in this area, and will need to be able to continue tracking it as a requirement. If it does move, I assume the maintainers will still be available and accessible. Josh has been helpful a number of times in the past. Other than that, I have no opinion on whether such a move is good or bad, right or wrong, or what it should look like. -efried > > Or would it be preferable to just fork and rename the project so > openstack can continue to use the current taskflow version without worry > of us breaking features? > > Greg > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo
On 2018-10-10 13:35:00 -0500 (-0500), Greg Hill wrote: [...] > We plan to still have a CI gatekeeper, probably Travis CI, to make sure PRs > past muster before being merged, so it's not like we're wanting to > circumvent good contribution practices by committing whatever to HEAD. Travis CI has gained the ability to prevent you from merging changes which fail testing? Or do you mean something else when you refer to it as a "gatekeeper" here? > But the +2/+W rights thing was a huge PITA to deal with with so > few contributors, for sure. [...] Note that this is not a technical limitation at all, merely social convention. There are plenty of projects hosted on our infrastructure, some even official OpenStack projects, where contributor count is low enough that authors who are also core reviewers just review and approve their own changes for expediency. > There's also a sense that if a project is in the Openstack > umbrella, it's not useful outside Openstack, and Taskflow is > designed to be a general purpose library. [...] Be aware that the "OpenStack Infrastructure" is in the process of rebranding itself as "OpenDev" and we're working to eliminate mention of OpenStack on things that don't need it. This includes moving services to a new domain name, switching to other repository namespaces, putting mirroring to services like GitHub and Bitbucket under the direct control of teams who are interested in handling that with their own unique organizations in those platforms, and so on. It's progressing, though perhaps too slowly to solve your immediate concerns. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo
On Wed, Oct 10, 2018, at 11:35 AM, Greg Hill wrote: > > I'm not sure how using pull requests instead of Gerrit changesets would > > help "core reviewers being pulled on to other projects"? > > > > The 2 +2 requirement works for larger projects with a lot of contributors. > When you have only 3 regular contributors and 1 of them gets pulled on to a > project and can no longer actively contribute, you have 2 developers who > can +2 each other but nothing can get merged without that 3rd dev finding > time to add another +2. This is what happened with Taskflow a few years > back. Eventually the other 2 gave up and moved on also. > To be clear this isn't enforced by anything but your reviewer practices. What is enforced is that you have +2 verified, a +2 code review, and +1 Workflow (this is a Gerrit submit requirements function that is also configurable per project). OpenStack requiring multiple +2 code reviews is enforced by humans and maybe the discussion could be "should taskflow and related tools allow single code review approval (and possibly self approval by any remaining cores)?" It might be a worthwhile discussion to reevaluate whether or not the humans should continue to enforce this rule on all code bases independent of what happens with taskflow. > > > Is this just about preferring not having a non-human gatekeeper like > > Gerrit+Zuul and being able to just have a couple people merge whatever > > they want to the master HEAD without needing to talk about +2/+W rights? > > > > We plan to still have a CI gatekeeper, probably Travis CI, to make sure PRs > past muster before being merged, so it's not like we're wanting to > circumvent good contribution practices by committing whatever to HEAD. But > the +2/+W rights thing was a huge PITA to deal with with so few > contributors, for sure. > > If it's just about preferring the pull request workflow versus the > > Gerrit rebase workflow, just say so. Same for just preferring the Github > > UI versus Gerrit's UI (which I agree is awful). > > > > I mean, yes, I personally prefer the Github UI and workflow, but that was > not a primary consideration. I got used to using gerrit well enough. It was > mostly the There's also a sense that if a project is in the Openstack > umbrella, it's not useful outside Openstack, and Taskflow is designed to be > a general purpose library. The hope is that just making it a regular open > source project might attract more users and contributors. This may or may > not bear out, but as it is, there's no real benefit to staying an openstack > project on this front since nobody is actively working on it within the > community. > > Greg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo
On Wed, Oct 10, 2018 at 2:35 PM Greg Hill wrote: > > I'm not sure how using pull requests instead of Gerrit changesets would >> help "core reviewers being pulled on to other projects"? >> > > The 2 +2 requirement works for larger projects with a lot of contributors. > When you have only 3 regular contributors and 1 of them gets pulled on to a > project and can no longer actively contribute, you have 2 developers who > can +2 each other but nothing can get merged without that 3rd dev finding > time to add another +2. This is what happened with Taskflow a few years > back. Eventually the other 2 gave up and moved on also. > As a note, the 2+2 requirement is only a convention, not a rule. Swift has moved to 1+2 already, and other projects have considered it. // jim __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo
> I'm not sure how using pull requests instead of Gerrit changesets would > help "core reviewers being pulled on to other projects"? > The 2 +2 requirement works for larger projects with a lot of contributors. When you have only 3 regular contributors and 1 of them gets pulled on to a project and can no longer actively contribute, you have 2 developers who can +2 each other but nothing can get merged without that 3rd dev finding time to add another +2. This is what happened with Taskflow a few years back. Eventually the other 2 gave up and moved on also. > Is this just about preferring not having a non-human gatekeeper like > Gerrit+Zuul and being able to just have a couple people merge whatever > they want to the master HEAD without needing to talk about +2/+W rights? > We plan to still have a CI gatekeeper, probably Travis CI, to make sure PRs past muster before being merged, so it's not like we're wanting to circumvent good contribution practices by committing whatever to HEAD. But the +2/+W rights thing was a huge PITA to deal with with so few contributors, for sure. If it's just about preferring the pull request workflow versus the > Gerrit rebase workflow, just say so. Same for just preferring the Github > UI versus Gerrit's UI (which I agree is awful). > I mean, yes, I personally prefer the Github UI and workflow, but that was not a primary consideration. I got used to using gerrit well enough. It was mostly the There's also a sense that if a project is in the Openstack umbrella, it's not useful outside Openstack, and Taskflow is designed to be a general purpose library. The hope is that just making it a regular open source project might attract more users and contributors. This may or may not bear out, but as it is, there's no real benefit to staying an openstack project on this front since nobody is actively working on it within the community. Greg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo
On 10/10/2018 01:41 PM, Greg Hill wrote: I've been out of the openstack loop for a few years, so I hope this reaches the right folks. Josh Harlow (original author of taskflow and related libraries) and I have been discussing the option of moving taskflow out of the openstack umbrella recently. This move would likely also include the futurist and automaton libraries that are primarily used by taskflow. The idea would be to just host them on github and use the regular Github features for Issues, PRs, wiki, etc, in the hopes that this would spur more development. Taskflow hasn't had any substantial contributions in several years and it doesn't really seem that the current openstack devs have a vested interest in moving it forward. I would like to move it forward, but I don't have an interest in being bound by the openstack workflow (this is why the project stagnated as core reviewers were pulled on to other projects and couldn't keep up with the review backlog, so contributions ground to a halt). I'm not sure how using pull requests instead of Gerrit changesets would help "core reviewers being pulled on to other projects"? Is this just about preferring not having a non-human gatekeeper like Gerrit+Zuul and being able to just have a couple people merge whatever they want to the master HEAD without needing to talk about +2/+W rights? If it's just about preferring the pull request workflow versus the Gerrit rebase workflow, just say so. Same for just preferring the Github UI versus Gerrit's UI (which I agree is awful). Anyway, it's cool with me to "free" taskflow from the onerous yoke of OpenStack development if that's what the contributors to it want. Best, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo
I've been out of the openstack loop for a few years, so I hope this reaches the right folks. Josh Harlow (original author of taskflow and related libraries) and I have been discussing the option of moving taskflow out of the openstack umbrella recently. This move would likely also include the futurist and automaton libraries that are primarily used by taskflow. The idea would be to just host them on github and use the regular Github features for Issues, PRs, wiki, etc, in the hopes that this would spur more development. Taskflow hasn't had any substantial contributions in several years and it doesn't really seem that the current openstack devs have a vested interest in moving it forward. I would like to move it forward, but I don't have an interest in being bound by the openstack workflow (this is why the project stagnated as core reviewers were pulled on to other projects and couldn't keep up with the review backlog, so contributions ground to a halt). I guess I'm putting it forward to the larger community. Does anyone have any objections to us doing this? Are there any non-obvious technicalities that might make such a transition difficult? Who would need to be made aware so they could adjust their own workflows? Or would it be preferable to just fork and rename the project so openstack can continue to use the current taskflow version without worry of us breaking features? Greg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
