|
Hi guys, at the moment there is approximately 250 packages shipping projects written in go. In general, each project has its own set of dependencies and provided import paths (golang packages). As usually each package has four active branches. Thus, we are dealing with approximately 1000 spec files, all potential candidates for rebases/updates and bug fixes. Each update can break backward compatibility. Some projects may require different commits of the same dependency. What are the most hot packaging problems in the golang ecosystem? - bundled vs. de-bundled dependencies - updates of spec files - backward compatibility issues - integration testing - best practises bundled vs. de-bundled dependencies) As mentioned in [1] some projects can not be build from de-bundled dependencies. Either caused by requirement for more commits of the same dependency or due to daily updates which require reviews of new packages. The current effort is to minimize number of bundled dependencies. updates of spec files) In general, each spec file has to be manually updated. Either if it is a list of build-time (runtime) dependencies, list of provided packages or a list of tests. Secondly, you never know if you break dependencies of other projects when you change project's API. Last but not least, when you want to update to newer release (or commit) of a golang project, new dependencies may appear. Resulting in generating of new spec files, reviews, overrides and dreamless hours of routine steps. The current effort is to detect all dependencies and provide warnings about their removal and to detect portion of API that is used by other projects. At the same time to provide more complex tooling to generate better spec file with less dependencies. backward compatibility issues) With 1000 spec files it is difficult to keep API of all projects consistent. No matter what you do you will always break something. At the moment we can provide a dependency graph only. It can tell you if a given dependency is available and what projects requires the dependency. integration testing) Some golang projects need additional services running. It would be great to be able to CI all golang packages to see what is broken and what is suitable for fixing. best practises) Well... And there are other issues which when resolved can make the world better place to live. Mentioning some: - generator of self-standing dvel subpackages [2] - detectors of bundled deps [3] - multi spec file generators [4] - partial spec file generator [5] - better lint What can you do to make the world a better place? Join us and contribute on gofed [6]. Currently we are in a phase of implementing new architecture, extending current and introducing new functionality. At the moment we aim to support golang language. In future, there is no reason not to extend the support to other languages. The top most goal is to implement health check analysis. Once detection of used symbols in API is done, we can provide better feedback during updates of packages and make the ecosystem health enough to be able to grow fresh and strong golang projects. What can you do right away? Play with gofed and infrastructure, help testing and documenting. Ideas and improvements are welcome. [1] https://fedorahosted.org/fpc/ticket/382#comment:37 [2] https://github.com/gofed/gofed/issues/36 [3] https://github.com/gofed/gofed/issues/42 [4] https://github.com/gofed/gofed/issues/49 [5] https://github.com/gofed/gofed/issues/55 [6] https://github.com/gofed/gofed [7] https://github.com/gofed/infra Go nuts!!! Jan |
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
