Open Stack

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.

> > > 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.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180606/7765aa10/attachment.sig>