Open Stack

On 06/21/2017 09:52 PM, Chris Hoge wrote:
> 
>> 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.

++

The micro repositories for config management and packaging create this
overwhelming wall of projects from the outside. I realize that git repos
are cheap from a dev perspective, but they are expensive from a concept
perspective.

	-Sean

-- 
Sean Dague
http://dague.net