Open Stack

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&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.

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 OpenStack" - that confusion should be improved in 
the not-too-distant-future. But - over half of the repos contained in 
the OpenStack Developer Infrastructure are already not "part of 
OpenStack" - so they would not be alone.

Finally, they can stop being "part of OpenStack" AND they can move their 
development to somewhere else.

>> 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.

At the same time, taskflow is used by a good number of OpenStack 
services - to the point that taskflow developing an issue would be a 
*problem* for OpenStack. If something goes wrong, the OpenStack project 
and the Oslo team currently can fix it. Since, as you mentioned, there 
isn't a super active dev team currently - we'd be looking at moving from 
important-library-that-can-be-fixed-by-OpenStack-if-OpenStack-breaks to 
important-library-with-dev-team-of-unknown-size-or-resources-that-might-stay-broken.

The last time we did this it was for an optional extra service with no 
real internal-OpenStack dependencies. If the end result had been the 
project completely ceasing to exist, as much as some humans would have 
been sad, OpenStack wouldn't have become broken.

Absent a compelling reason to the contrary, I'd argue that it's in 
OpenStack's best interests that the libraries remain not only in the 
OpenStack developer infrastructure but also under the governance of the 
Oslo team. Relaxing reviewer requirements seems like a fine idea and not 
at all problematic.

Obviously that's just me, but I'd love to see if we can work out making 
the current home more pleasant before we start ejecting libraries.

Monty