Open Stack

> On Jun 22, 2017, at 03:01, Sean Dague <sean at dague.net> wrote:
> 
> 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.

I ask, then, what about those communities that do advocate one repo per
subproject? Chef is one such case in which monolithic all-in-one repos used to
be the mainstay, and are now frowned upon and actively discouraged in the Chef
community due to real pain felt in finding the right patterns. In the past, we
(Chef OpenStack) experimented with the One Repo To Rule Them All idea, but that
didn’t get much traction and wasn’t further fostered. Right now, what works for
us is a hybrid model of community best practices doing one repo per
cookbook/subproject and a single “meta” repo that ties the whole thing
together. Maybe that one repo per subproject pattern is an anti-pattern to
OpenStack’s use case and we’re now getting to the point of criticality. Past
iterations of the Chef method include using git submodules and the GitHub
workflow, as well as One Repo To Rule Them All. They’re in the past, gone and
left to the ages. Those didn’t work because they tried to be too opinionated,
or too clever, without looking at the user experience.

While I agree that the repo creep is real, there has to be a balance. The Chef
method to OpenStack has been around for a long time in both Chef and OpenStack
terms, and has generally followed the same pattern of one repo per subproject.
We still have users[1], most of whom have adopted this pattern and have been in
production, some for years, myself included. What, I ask, happens to their
future if Chef were to shake things up and pivot to a One Repo To Rule Them All
model? Not everyone can pivot, and some would be effectively left to rot with
what would now be considered tech debt by those closer to upstream. “If it
ain’t broke, don’t fix it” is still a strong force to contend with, whether we
like it or not. Providing smooth, clear paths to a production-grade open cloud
should be the aim, not what the definition of is, is, even if that is what
comes naturally to groups of highly skilled, highly technical people.

> 
> 	-Sean
> 
> --
> Sean Dague
> http://dague.net
> 
> __________________________________________________________________________
> 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

[1]: https://www.openstack.org/assets/survey/April2017SurveyReport.pdf (Pg. 42)


--
Best,

Samuel Cassiba

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170622/5ee00072/attachment.sig>