[openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo

Ben Nemec openstack at nemebean.com
Wed Oct 10 20:17:46 UTC 2018



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&i=nope&files=requirements.txt&repos=

> 
>     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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list