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
signature.asc
Description: Digital 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
