Jeremy Stanley wrote:
On 2019-02-25 09:09:59 -0500 (-0500), Doug Hellmann wrote: [...]
One of the criteria that caught my eye as especially interesting was that a project must complete at least one release before being accepted. We've debated that rule in the past, and always come down on the side encouraging new projects by accepting them early. I wonder if it's time to reconsider that, and perhaps to start thinking hard about projects that don't release after they are approved.
Thoughts?
For me, the key difference is that OpenStack already has clear release processes outlined which teams are expected to follow for their deliverables. For confirming a new OIP it's seen as important that they've worked out what their release process *is* and proven that they can follow it (this is, perhaps, similar to why the OIP confirmation criteria mentions other things we don't for new OpenStack project team acceptance, like vulnerability management and governance).
Yes, that was the main idea behind that "one release" criteria, and I think our automated release processes take care of that for our openstack project teams. Furthermore, some OIPs are formed by merging source code or ideas from multiple parties (the canonical example being Kata containers being merged from Hyper and Intel) -- the task of making it a clear single project (rather than a WIP merge activity) should be long completed by confirmation time. -- Thierry Carrez (ttx)