On 20.02.2020 13:47, Greg Troxel wrote: > Kamil Rytarowski <n54%gmx.com@localhost> writes: > >> I propose to merge src and xsrc into a single source tree. > > It is of course not possible to have a full evaluation without a > precise plan, and thus not possible to achieve the required consensus. > > I think it's really obvious that any such decision must be formally > adopted by core, rather than any developer doing it after perceiving > consensus. > Full plan with exact steps needs cooperation from other teams such as admins who handle GitHub exports. It's not realistic to expect me to draft scripts. At this stage of proposal I am open for flexibility here. >> Rationale: >> >> - xsrc (0.9GB) is around 22.5% of size of src+xsrc (4GB), which is >> still significant but hardly important enough to maintain the split. >> - xsrc is not restricted to Xorg these days and ships libraries for at >> least Wayland. >> - It is cost to maintain build machinery for two repositories that can >> be desynced. >> - Easier to analyze repository changes without looking intwo two >> distinct repositories. >> - After recent Andrew Doran's SMP improvements, in my personal feeling >> DVCS perform well in large repositories now. >> - We could rename the src repository to netbsd and merge CVS history of >> src and xsrc in one tree(*). This is a request from certain developers >> and I find it valuable. >> >> There is an option to preserve xsrc's history and merge it into src/ or >> reset it (redirecting to an archived xsrc tree) and import freshly into >> src/. It is hard (impossible without rewriting older branches?) to merge >> history without confusing developers and breaking older snapshots and >> this is why I am proposing to reset it and freshly import into src/. > > I think this overstates the trouble of the two repositories and > underestimates the trouble of combining them. In my experience, grand > changes are almost always more difficult than expected. > > I don't think losing history is a good tradeoff for this. > > If xsrc were to just become a subdirectory of src, that wouldn't be so > bad. Aside from a few path adjustments, it would be as before, execpt > branching/tagging checkouts would be over both. > This is how works everything else, external/ sys/external/ crypto/ etc. So why to insist on making xsrc different? Or why to insist of having only 2 repos instead of separated src/ externalsrc/ cryptosrc/ etc? We used to have src/gnu/ but it was finally flattened. We also lost its history. We also effectively lost history after moving around 3rd party sources after changes of licenses. > However, I really don't find it hard to update both trees to the same > tag/etc. Are you really having trouble doing two diffs instead of one > for the entire system? Wrapper script? > I'm not looking for workarounds. History can be preserved in various approaches (actually in all of them). If we import all the xsrc files cleanly into src/, the history will be archived at least in xsrc and kept around for historical interest. > It seems there is a culture of git submodules for large things, so it's > not clear a monolithic repository is an obvious goal. (I'm not speaking > in favor of submodules, just pointing out that some do that.) > git submodules are not an option. They create more trouble than they solve them (projects doing it receive constant complaints). They are also against the proposal of merging two repos and they are another workaround for the split. > Given all this, I think it's best to let this be as it is. > xsrc is not self-contained any more (assuming that is was that way in the past). It needs src/ for LLVM. I don't find the split relevant anymore. It also looks nicely said legacy to store drm in xsrc/ and new drivers in src/sys/external/bsd/drm.
Attachment:
signature.asc
Description: OpenPGP digital signature