<div dir="ltr">Howdy,<div><br></div><div>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?</div><div><br></div><div>It seems to me that the role of stackforge to provide a proving ground or place for aligned projects/repos was quite clear and well understood (although perhaps I'm wrong). There were some technical challenges in moving between namespaces that were less than ideal, but have we A) investigated what would be required to overcome or at least lessen the technical challenges, and/or B) weighed them against the alternatives and current proposals?</div><div><br></div><div>Cheers,<br>Josh</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 29, 2017 at 6:17 PM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">James E. Blair wrote:<br>
> Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> writes:<br>
><br>
>> Removing the root cause would be a more radical move: stop offering<br>
>> hosting to non-OpenStack projects on OpenStack infrastructure<br>
>> altogether. We originally did that for a reason, though. The benefits of<br>
>> offering that service are:<br>
>><br>
>> 1- it lets us set up code repositories and testing infrastructure before<br>
>> a project applies to be an official OpenStack project.<br>
>><br>
>> 2- it lets us host things that are not openstack but which we work on<br>
>> (like abandoned Python libraries or GPL-licensed things) in a familiar<br>
>> environment<br>
>><br>
>> 3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack itself<br>
><br>
> I think this omits what I consider the underlying reason for why we did<br>
> it:<br>
><br>
> It helps us build a community around OpenStack.<br>
><br>
> Early on we had so many people telling us that we needed to support<br>
> "ecosystem" projects better.  That was the word they used at the time.<br>
> Many of us said "hey, you're free to use github" and they told us that<br>
> wasn't enough.<br>
><br>
> We eventually got the message and invited them in, and it surpassed our<br>
> expectations and I think surprised even the most optimistic of us.  We<br>
> ended up in a place where anyone with an OpenStack related idea can try<br>
> it out and collaborate frictionlessly with everyone else in the<br>
> OpenStack community on it, and in doing so, become recognized in the<br>
> community for that.  The ability for someone to build something on top<br>
> of OpenStack as part of the OpenStack community has been empowering.<br>
><br>
> I confess to being a skeptic and a convert.  I wasn't thrilled about the<br>
> unbounded additional responsibility when we started this, but now that<br>
> we're here, I think it's one of the best things about the project and I<br>
> would hate to cleave our community by ending it.<br>
<br>
</div></div>I think that's a great point, Jim.<br>
<br>
I spent a lot of time last week analyzing the "negative space" (things<br>
that are on our project infrastructure but are not openstack), and there<br>
are indeed a number of projects which would qualify as "companion<br>
projects": David's ARA, the swift3 Swift middleware, or Neutron plugins<br>
for some proprietary hardware that got kicked out of the Neutron<br>
stadium. There aren't so many of those, but keeping those close to us is<br>
definitely a good thing.<br>
<br>
Ideally we would find a way to continue to host those, without creating<br>
any doubt as to whether they are an official OpenStack project under TC<br>
governance. Such options to address the confusion at the edge exist, and<br>
they were explored in the previous thread (selective GitHub replication,<br>
aggressive tagging, active removal of obviously-dead things, separate<br>
branding/domains...). The main issue being, those options all involved a<br>
lot of work for the infra team, work that is not conceivable with its<br>
current limited resources. The only reason why I put the nuclear plan B<br>
on the table is that we can't get the plan A properly done...<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Thierry Carrez (ttx)<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>