Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Find a place for `/pkg` #32989
In an effort of splitting Moby and Docker, we are reorganizing the repo to avoid confusion (see #32871)
We decided to not move some of the packages at first, so we won't break projects depending on those.
Item 1 - Move
Here's my proposal for dealing with
The full list of moves is rather long, so I've captured it in this gist: full pkg moves proposal. This gist includes the full list of
Below is a rough plan for the new repos that will be created. This may change as we work on the split, but it should be approximately on this scale. These are the github urls, but are not necessarily the "import urls". We will likely use our own urls with a service like http://labix.org/gopkg.in. These repo names are purely a suggestion and can easily be changed.
(Note: fsutils and archive might be combined)
Many of these would be created by combining multiple
16 packages will be moved to their single consumer.
@dnephin What would be the purpose of having the code split up into so many repositories? There are some other projects out there which make the life of a potential contributor a nightmare. The more processes and procedures are put in place to make a single contribution, the less likely it is for someone to go through the process to make that contribution.
The general idea is that each of these new repos are functionally very different and are not called from the same components. Any
It should be extremely unlikely that any contribution to a moby/moby component would need to modify more than one of these. In many cases not a single one of these packages would be modified. If you see any cases where these packages would have to be modified together, please do let me know, and I can update my proposal.
My rational for not moving everything into a single "random-pkg-stuff" repo is that it would actually be considerably worse for contributors. If multiple PRs require modification to the same repo it is very difficult to coordinate the vendoring of those changes. If we had every pkg in a single repo then the frequency of conflicting changes would be much higher.
A single repo of random utilities is also difficult to describe, and has no clear goal or purpose. This makes it hard to find owners for the entire repo, and results in quality issues over time.
I think we have to find a good balance between too many repos, and too few. I think the best way to do that is to look at package dependencies and consumers, and group things together based on their coupling to other packages. That is what I've done here.
Combining system, mount, and fs could work, although there are also dependencies between fs and archive I think.
This proposal was just an approximation, as the work is done to actually split it out we might discover a better fit, but I think the general plan remains the same.
I would suggest that we favor using the
A great example is
Dare I invoke this relationship, but I fear this effort will result in a serious case of leftpad-itis.
If we do find that a package is broadly useful, we should create a process for identifying those candidates and eliminate other options before going this route.
The goal of this effort is support breaking out components. Any
For the other 38
I agree many of these packages will have a suboptimal interface initially.
Trying to refactor everything right now will greatly delay the work to split out components. Instead of trying to fix everything now we can improve the interface of these packages over time.
That said, I don't think we want to rush this and create 10 new repos right away. This is just a roadmap for when we hit shared components. Maybe as we extract things we'll realize that we don't need some of these repos.
Since you mentioned
Creating components is the process of finding the correct interfaces. Splitting these out into packages without refactoring is going to create unforeseen problems.
If we can, it would be best to eliminate as many of these packages as possible. If we do find there are real shared patterns, we can propose and design the package with respect to requirements.
Either way, one less package for you to worry about: #33097.
Yes the interface for the component, not the interface for every library used by a component.
Yes, that is part of the plan.
Not exactly. As you can see in the plan
Adding some more details based on a discussion during slack standup.
This proposal is only a guideline to follow as we hit
Before creating any new repos the following steps should be performed:
Given these steps, the following work can be done at any time:
These packages and operations are listed in the full proposal
This was referenced
May 23, 2017
referenced this issue
Jun 1, 2017
This was referenced
Jun 1, 2017