|
Hi Oliver,
An important note before I get to other responses.....
Don't Forget that not all of the world's internet connections are FAST. While it might seem a good idea from the librarians perspective to have everything in a single repo, IT ISN'T a good idea at all if you happen to be on a slow internet connection. When I say slow, I'm talking common ADSL speeds here in Australia for example. They are often 8mbit/s or less. Even with the "National Broadband Network" rollout of Fibre, I know people that effectively suffered a net reduction of speed compared to their old ADSL connection. (Yeah, crazy, but it's true) If the entire lib ended up being ~ 3G (a figure mentioned in other posts) that would Take an Unacceptably long time to download. For this reason I would STRONGLY advise libraries remain broken up into manageable sized repositories Also, keep in mind that a repository never gets smaller, it only grows as changes are made. On 28/09/17 19:29, Oliver Walters
wrote:
Agreed, submodules may well add some management overhead, although most of the items in the list you gave are still relevant even if all libs are in a single repo. One possibly significant advantage of using a submodule structure is the ease of inclusion of libraries that are not part of the "core" project managed set. The aids in three ways. * Trivial inclusion of Vendor provided libraries in the Core Set, by simply including an extra submodule * Easy addition of site or project specific libs by having a new top level repo, that includes the Core repo, and additional libs * Easy reduction in the range of libs available to a team by having a fork of the Core repo with limited defined submodules NOTE: Submodules are not the only way to achieve these goals, but in many ways, as long as the appropriate helper scripts etc are put in place, submodules are likely the easiest to maintain in the long run. Potentially, the entire available-to-the-current-project library mechanism could be designed to use a local git repo, that simply includes submodules as required. As I've mentioned elsewhere, 99% of the problems with submodules becoming out of sync can be resolved with a few simple helper scripts, potentially in the form of makefile targets. Ideally, yes, forking of repo's is the best way to manage user contributions. To a large extent, I'd have thought most users are likely to only contribute to a small number of libraries directly. So that may not be a significant burden. However, There is an alternative way to handle contributions, assuming we manage it all from a KiCad provided UI. Rather than individually fork, have the project maintain an aggregated repo that contains ALL official libs. (other libs would be handled in a traditional forking methodology) If you want to contribute to on official lib, the UI would clone (or pull as required) the aggregated repo, and apply the changes to that. That repo would be configured to allow Public PR's to be raised, but only librarians would have permissions to do merges. Ideally, the PR would not be directly merged into the aggregate repo, but cherry picked into the appropriate discrete repo Then webhooks/githooks would be used to merge changes to the discrete repo's into the aggregate repo In theory, the opposite could be done instead. Regardless of submodule vs single repo, the "master files" will always need updating to stay in sync with library changes, so I don't see this as being an issue either way. That's a very good question. As I understood it (and I haven't looked closely yet) Symbol Libs were in separate repos, eg: Microchip, vs Connectors, etc I can see an very good argument to generally have Groups of things in a common repo, but separate repos for each Group. To be honest, I envisage libs as a set of trees. * core * connectors * samtec * generic * some other manufacturer * logic * TTL * CMOS * Lattice * Philips * Contributed (externally maintained semi official) * Lib Contributor foo * Beagle Bone Capes * Lib Contributor bar * Arduino Shields * This Companies Libs * special items * connectors * Custom Samtec As for footprints, vs symbols, vs 3D modules, I simply see them as additional branches in the tree. So * core may have them included, so may "This companies libs" While it's possible you may allow footprints etc to be included at lower levels in the tree (eg Arduino Shields) that would need to be carefully considered, and potentially policed. I know that it's unlikely such a significant change would happen anytime soon, but if it's something there is interest in, it's worth attempting to allow the tooling to achieve it in the future. I completely agree, from a user perspective, the simpler the better. (Note. I include the librarian in the "user" clause here) However, it doesn't matter how it's implemented, the backend to do it right is never going to be simple code. By using what you call a complex set of tools (git and submodules in this discussion) the KiCad project doesn't need to maintain complex code. Rather, it maintains a set of wrapper functions and relies on the extremely well tested, and robust capabilities of an existing complex tool. Namely Git The current situation of wrapping the Github API to essentially duplicate (in an incomplete and non-portable way) git functionality seems to me to be undesirable from a few angles. They would include, but not be limited to.... * Non-portability, it currently depends on github, so a company can't easily serve their own git repo * code complexity. Directly managing http requests against the github api is more complex, and certainly slower than using a local git clone and git library * Maintainability. The github api periodically goes through breaking changes, and we would need to follow those quite rapidly to prevent breakage. Even worse, Older versions of KiCad would likely cease to function correctly after some of those changes. Conversely, a git library based method will not break unless a newer version of the library is used to compile, at which point it's in the hands of the developer, rather than the user. Regards David Godfrey SB Tech Services mb: +61 437 286 200
|
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
