Open Stack

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)