Open Stack

> On Jun 21, 2017, at 2:35 PM, Jeremy Stanley <fungi at yuggoth.org> wrote:
> 
> On 2017-06-21 13:52:11 -0500 (-0500), Lauren Sell wrote:
> [...]
>> To make this actionable...Github is just a mirror of our
>> repositories, but for better or worse it's the way most people in
>> the world explore software. If you look at OpenStack on Github
>> now, it’s impossible to tell which projects are official. Maybe we
>> could help by better curating the Github projects (pinning some of
>> the top projects, using the new new topics feature to put tags
>> like openstack-official or openstack-unofficial, coming up with
>> more standard descriptions or naming, etc.).
> 
> I hadn't noticed the pinned repositories option until you mentioned
> it: appears they just extended that feature to orgs back in October
> (and introduced the topics feature in January). I could see
> potentially integrating pinning and topic management into the
> current GH API script we run when creating new mirrors
> there--assuming these are accessible via their API anyway--and yes
> normalizing the descriptions to something less freeform is something
> else we'd discussed to be able to drive users back to the official
> locations for repositories (or perhaps to the project navigator).
> 
> I've already made recent attempts to clarify our use of GH in the
> org descriptions and linked the openstack org back to the project
> navigator too, since those were easy enough to do right off the bat.
> 
>> Same goes for our repos…if there’s a way we could differentiate
>> between official and unofficial projects on this page it would be
>> really useful: https://git.openstack.org/cgit/openstack/
> 
> I have an idea as to how to go about that by generating custom
> indices rather than relying on the default one cgit provides; I'll
> mull it over.
> 
>> 2) Create a simple structure within the official set of projects
>> to provide focus and a place to get started. The challenge (again
>> to our success, and lots of great work by the community) is that
>> even the official project set is too big for most people to
>> follow.
> 
> This is one of my biggest concerns as well where high-cost (in the
> sense of increasingly valuable Infra team member time) solutions are
> being tossed around to solve the "what's official?" dilemma, while
> not taking into account that the overwhelming majority of active Git
> repositories we're hosting _are_ already deliverables for official
> teams. I strongly doubt that just labelling the minority as
> unofficial will any any way lessen the overall confusion about the
> *more than one thousand* official Git repositories we're
> maintaining.

Another instance where the horse is out of the barn, but this
is one of the reasons why I don’t like it when config-management
style efforts are organized as one-to-one mapping of repositories
to corresponding project. It created massive sprawl
within the ecosystem, limited opportunities for code sharing,
and made refactoring a nightmare. I lost count of the number
of times we submitted n inconsistent patches to change
similar behavior across n+1 projects. Trying to build a library
helped but was never as powerful as being able to target a
single repository.

>> While I fully admit it was an imperfect system, the three tier
>> delineation of “integrated," “incubated" and “stackforge" was
>> something folks could follow pretty easily. The tagging and
>> mapping is valuable and provides additional detail, but having the
>> three clear buckets is ideal.  I would like to see us adopt a
>> similar system, even if the names change (i.e. core infrastructure
>> services, optional services, stackforge). Happy to throw out ideas
>> if there is interest.
> [...]
> 
> Nearly none (almost certainly only a single-digit percentage anyway)
> of the Git repositories we host are themselves source code for
> persistent network services. We have lots of tools, reusable
> libraries, documentation, meta-documentation, test harnesses,
> configuration management frameworks, plugins... we probably need a
> way to reroute audiences who are not strictly interested in browsing
> source code itself so they stop looking at those Git repositories or
> else confusion is imminent regardless. As a community we do nearly
> _everything_ in Git, far beyond mere application and service
> software.
> 
> The other logical disconnect I'm seeing is that our governance is
> formed around teams, not around software. Trying to explain the
> software through the lens of governance is almost certain to confuse
> newcomers. Because we use one term (OpenStack!) for both the
> community of contributors and the software they produce, it's going
> to become very tangled in people's minds. I'm starting to strongly
> wish could use entirely different names for the community and the
> software, but that train has probably already sailed

Two points: 
1) Block That Metaphor!
2) You’ve convinced me that the existing tooling around our current
state is going to make it really hard to corral that sailed horse back
in the train station.


> (and could
> result in different confusion all its own too, I suppose).
> -- 
> Jeremy Stanley
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev