Open Stack

On Fri, Jun 30, 2017 at 12:18 AM, Jeremy Stanley <fungi at yuggoth.org> wrote:

> On 2017-06-29 18:58:09 +1000 (+1000), Joshua Hesketh wrote:
> > So I apologise if this has already been suggested/discussed (the
> > long threads are difficult to keep up with), but has it been
> > considered to go back to using a stackforge namespace?
> [...]
>
> Back in the bad ol' days when we had a separate namespace for
> unofficial projects, it seemed to me like newcomers were just as
> confused as they are now, perhaps even more so. People like to
> forget, or wax nostalgic, or simply weren't around to see it first
> hand back then; so I agree it's probably worth rehashing the pain
> points as it's been a long time since I can recall anyone
> enumerating them.
>
> Gerrit's design assumes project names (including any prefixed
> namespace) never change. This means project renames in Gerrit are
> painful and disruptive (service outage for everyone, Git remote
> changes for anyone working on that repo, risk of breaking things
> with a SQL update query or directory move, et cetera). There is no
> good automation for transfers between orgs in GH either so handling
> this is a manual process involving lot of clicking around in a Web
> browser. Project renames also touch other systems (our many Git
> servers, StoryBoard) so more places to make mistakes or miss
> something.
>
> As a result, we would want to actively discourage repos moving from
> the stackforge namespace into the openstack namespace (or vice
> versa) which creates an artificial hurdle for projects seeking to
> become official. This causes them to place an urgent pressure on the
> Infra team which makes it harder for us to ease the pain of renames
> by batching them up and processing them less frequently. We
> similarly would no longer be allowed to create repos directly in the
> openstack namespace without prior approval from the TC, which puts
> the brakes on the current flow where teams can create a new repo as
> quickly as the project-config-cores review the change and then work
> on the corresponding governance addition in parallel with doing
> their project development.
>
> In the past the ability to push most of the work of doing renames
> onto the Infra team created a perverse incentive for projects to
> start unofficial so they didn't have to wait on the TC, and then ask
> for a rename once they got approval rather than waiting to start
> work until the TC approved their request. It's hard for the Infra
> team to effectively deter that sort of behavior because the most we
> can do is ask authors of their intentions and then trust that
> they're being up front about a lack of interest in becoming official
> (and that they're unlikely to change their minds about it later).
>
> Unfortunately, hosting unofficial projects grants official teams a
> license to experiment in that space rather than taking
> responsibility up front, and this is detrimental to our community as
> a whole. It also gives new teams an easy excuse to put off applying
> to become official until later since they get most of the
> infrastructure benefits right away regardless. If we could get rid
> of this pervasive temptation to "incubate" ideas out from under the
> shadow of governance then maybe that would make maintaining the rest
> under a different namespace slightly less of a burden, as the need
> to move repos between namespaces would then be far less common or
> urgent.
> --
> Jeremy Stanley
>
> __________________________________________________________________________
> 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
>
>
Hey Jeremy,

Thanks for that, it's a good refresher. I'm aware of the technical
challenges however (and I think I did a poor job of saying this) I was
suggesting that if we suspend the technical issues for the purpose of this
discussion what does it look like. In other words, lets assume we can
easily move between namespaces (and even git remotes aren't a problem), in
this case is returning to something like stackforge advantageous?

Then, if so, has anybody looked at how difficult it would be to actually to
fix gerrit, automate github (perhaps through a newer API or simulating
those clicks etc), come up with a creative fix to git remotes (redirects,
updating via git review or something) etc.

This possibly isn't helpful as I'm unfortunately not in a position to be
able to volunteer to work on any of the above. Realistically I imagine that
the amount of work is not feasible and that is one of the reasons we moved
away from multiple name spaces. I'm just wondering if that is still the
case.

Cheers,
Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170630/8a5bd0ed/attachment.html>