| Summary: | Merge linux-yocto git trees to a single one to reduce download times and mirror sizes | ||
|---|---|---|---|
| Product: | [Yocto Project Subprojects] Kernel | Reporter: | mikko.rapeli |
| Component: | linux-yocto | Assignee: | Bruce Ashfield <bruce.ashfield> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Medium+ | CC: | bluelightning, richard.purdie, robin.l.jordan |
| Version: | unspecified | ||
| Target Milestone: | 2.5 M3 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Yes (doc changes required) | |
|
Description
mikko.rapeli
2017-09-01 11:01:19 UTC
This has already been proposed and offered on the mailing list by myself. And has been mentioned more than once in the past. The decided direction was to use shallow clones versus a single tree, since the tree is maintained/managed differently than other trees. Alternatively, having the project host a single pristine korg tree and all other kernels are reference clones against that kernel tree to reduce their size. A few deltas in the process for generating it are as follows: - The tree is rebased and re-created, since we carry content that cannot be easily updated in a fast forward manner. Hence history is re-created on top of each major release for clarity. - The kernel-cache repository tracks the patch history over time, not the actual kernel tree itself. - We won't use quilt or directories full of patches to manage the actual changes to the tree, that was rejected long before the first Yocto release. - We have topic branches for the various invasive features and kernel types (and also to represent BSPs), hence any versioned tracked trees would quickly have 50 or 60 branches and then continue to grow from there. So the actual fix is within bitbake and the options for git fetching, which are being looked at last I heard. Once a reference clone, or shallow clone option are reliably available, I'll adjust the reference kernel recipes to leverage them I believe shallow clone functionality is in bitbake already thanks for patches from Chris. I did ask for documentation patches, I don't think I ever got any :(. http://git.yoctoproject.org/cgit.cgi/poky/log/?qt=grep&q=shallow shows the patches in question. The other option would be a "clone by reference" setup where we have a common repo for kernels which we then clone the individuals from. That functionality obviously doesn't exist. Ah yes. I did find the old conversations on this topic, buried in a gcc6 upgrade thread! And one where I offered some options during the release of the 4.8 tree. We talked about shallow clones and references (actually my preference) in those threads. We've had a "linux-yocto" tree on git.yoctoproject.org for nearly a year now, which I asked to be created to work on this in the background. Getting reference clones is obviously more challenging since the code doesn't exist, but during the next release, I'll look at leveraging the shallow clone support and then see what would really be needed for reference clones. (In reply to comment #2) > I believe shallow clone functionality is in bitbake already thanks for > patches from Chris. I did ask for documentation patches, I don't think I > ever got any :(. > > http://git.yoctoproject.org/cgit.cgi/poky/log/?qt=grep&q=shallow shows the > patches in question. > > The other option would be a "clone by reference" setup where we have a > common repo for kernels which we then clone the individuals from. That > functionality obviously doesn't exist. Please provide an update on the status of this and let me know if it will be ready for YP 2.5 M3. This has been in place since the 4.8 yocto kernel. I've picked it up for 4.14 and 4.15 as part of the upcoming release. |