Open Stack

On 2017-06-30 11:31:01 +1000 (+1000), Joshua Hesketh wrote:
[...]
> has anybody looked at how difficult it would be to actually to
> fix gerrit,

There was an abandoned attempt to implement it in core:

https://gerrit-review.googlesource.com/q/project:gerrit+topic:rename-project

And there's still the vestige of an empty plugin attempt which never
had any code pushed up to it:

https://gerrit.googlesource.com/plugins/rename-project/

Being in Java is a bit of a roadblock for me personally to reattempt
to tackle it. I'm just a lowly sysadmin so if it's not
c/shell/perl/python my learning curve is pretty steep.

Given that Gerrit is used lots of places by lots of orgs and yet
their forums have a scant handful of posts on this subject from
people who suddenly discovered they needed to rename a single
project after years of running, I have to ask whether what we're
doing needing to rename things constantly isn't just plain counter
to the way the software is intended to be applied. Makes me think we
should just be finding ways to avoid renaming things over and over,
even if that means switching all repository names to UUIDs (okay,
mostly kidding there... _mostly_).

> automate github (perhaps through a newer API or simulating
> those clicks etc),

I poked around in the GH v3 REST API an v4 GraphQL-based API docs
and couldn't spot any methods for transferring a repo between orgs.
Given that the operation in the WebUI requires an account with
membership in both involved orgs, they may deem it beneath the value
threshold for inclusion. Also, I'd personally much rather stop
having Gerrit push replicate into GH, and hand maintenance of a
mirror there off to some other volunteers within the community who
have more of an interest in similar social media platforms.

> come up with a creative fix to git remotes (redirects, updating
> via git review or something) etc.
[...]

I've already been mulling over some ideas for useful
redirects/rewrites on our git.openstack.org service and that's not
too hard for HTTP(S) remotes to deal with, but for Git protocol
requests I don't think it's possible without significant
modification to the backend service (best I can come up with is
symlinking on the underlying filesystem, and maybe that's "good
enough").

But to circle back around to my earlier point, assuming that we're
just going to need to accept a constant flood of renames and then
try to engineer solutions to make that marginally less painful is
stretching my suspension of disbelief here. I'd rather find a way to
avoid project renames just for the sake of governance
inclusion/exclusion. We don't have any solid evidence that it will
"fix" the external confusion around OpenStack at all, but we
definitely know it will create a lot of additional work. I have a
hard time seeing justification in such a tradeoff.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170630/61693444/attachment.sig>