Open Stack

Excerpts from Jeremy Stanley's message of 2018-06-06 20:09:36 +0000:
> On 2018-06-06 14:52:04 -0400 (-0400), Zane Bitter wrote:
> > On 29/05/18 13:37, Jeremy Stanley wrote:
> > > On 2018-05-29 10:53:03 -0400 (-0400), Zane Bitter wrote:
> [...]
> > > > * If the repo is a fork of another project, there must be (public)
> > > > evidence of an attempt to co-ordinate with the upstream first.
> > > 
> > > I don't recall this ever being mandated, though the project-config
> > > reviewers do often provide suggestions to project creators such as
> > > places in the existing community with which they might consider
> > > cooperating/collaborating.
> > 
> > We're mandating it for StarlingX, aren't we?
> 
> This goes back to depending on what you mean by "we" but assuming
> you mean those of us who were in the community track Forum room at
> the end of the day on Thursday, a number of us seemed to be in
> support of that idea including Dean (who was going to do the work to
> make it happen) and Jonathan (as OSF executive director). Far from a
> mandate, and definitely a rare enough situation that recording a
> hard and fast rule is not a useful way to spend our valuable time.
> 
> > AIUI we haven't otherwise forked anything that was still maintained
> > (although we've forked plenty of libraries after establishing that the
> > upstream was moribund).
> 
> All the Debian packaging, when we were hosting it (before it got
> retired and moved back to Debian's repository hosting) was
> implemented as forks of our Git repositories. The Infra team also
> maintains a fork of Gerrit (for the purposes of backporting bug
> fixes from later versions until we're ready to upgrade what we're
> running), and has some forks of other things which are basically
> dead upstream (lodgeit) or where we're stuck carrying support for
> very old versions of stuff that upstream has since moved on from
> (puppet-apache). Forks are not necessarily inherently bad, and
> usually the story around each one is somewhat unique.

Yeah, if I had realized the Debian packaging repos had changes beyond
packaging I wouldn't have supported hosting them at the time.

Because the gerrit fork is for the use of this community with our
deployment, we do try to upstream fixes, and we don't intend to
release it separately under our own distribution, I see that as
reasonable.

I'm trying to look at this from the perspective of the Golden Rule
[1].  We not treat other projects in ways we don't want to be treated
ourselves, regardless of whether we're doing it out in the open.
I don't want the OpenStack community to have the reputation of
forking instead of collaborating.

[1] https://en.wikipedia.org/wiki/Golden_Rule

> > > > Neither of those appears to be documented (specifically,
> > > > https://governance.openstack.org/tc/reference/licensing.html only
> > > > specifies licensing requirements for official projects, libraries
> > > > imported by official projects, and software used by the Infra
> > > > team).
> > > 
> > > The Infrastructure team has been granted a fair amount of autonomy
> > > to determine its operating guidelines, and future plans to separate
> > > project hosting further from the OpenStack name (in an attempt to
> > > make it more clear that hosting your project in the infrastructure
> > > is not an endorsement by OpenStack and doesn't make it "part of
> > > OpenStack") make the OpenStack TC governance site a particularly
> > > poor choice of venue to document such things.
> > 
> > So clearly in the future this will be the responsibility of the
> > Winterscale Infrastructure Council assuming that proposal goes
> > ahead.
> > 
> > For now, would it be valuable for the TC to develop some
> > guidelines that will provide the WIC with a solid base it can
> > evolve from once it takes them over, or should we just leave it up
> > to infra's discretion?
> [...]
> 
> My opinion is that helping clarify the terms of service
> documentation the Infra team is already maintaining is great, but
> putting hosting terms of service in the TC governance repo is likely
> a poor choice of venue. In the past it has fallen to the Infra team
> to help people come to the right conclusions as to what sorts of
> behaviors are acceptable, but we've preferred to avoid having lots
> of proscriptive rules and beating people into submission with them.
> I think we'd all like this to remain a fun and friendly place to get
> things done.

I want it to be fun, too. One way to ensure that is to try to avoid
these situations where one group angers another through some action
that the broader community can generally agree is not acceptable
to us by writing those policies down.

I agree this is ultimately going to be something we rely on the
infra team to deal with. I think it's reasonable for the rest of
the community to try to help establish the preferences about what
policies should be in place.

Doug