On 06/21/2017 09:52 PM, Chris Hoge wrote: > >> On Jun 21, 2017, at 2:35 PM, Jeremy Stanley <fu...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev