On Wed Feb 26, 2020 at 6:54 PM, Ian Kelling wrote: > The lack of linking between repo and lists and bugs is was listed as an > issue in our review already, and I think thats a bigger issue. If there > was some improvement around this, even if its not the final state, that > would be a huge reason to consider it more highly. For example, if I go > to a repo, its unclear how to file a bug for it. I created a new repo > for a new project, its unclear you generally want to create a list and a > bug tracker with the same name. Those kinds of things.
Yeah, this is a blocker for the alpha. Explaining my plans requires some additional context, though. On GitHub and its clones (e.g. Pagure, GitLab, Gitea), one git repo == one bug tracker == one place to submit patches == one wiki == one set of CI configs. It's all tied directly to the repository. This isn't how a lot of projects work in practice. SourceHut tries to model what projects actually want more closely. For example, we have X git repos, Y hg repos, Z bug trackers (where X != Y != Z), a single mailing list for patches, separate lists for announcements and end-user discussion, and dozens of CI configurations which have only a loose relationship with repos. The Linux kernel is an example where it gets even weirder. Linus' tree, distro trees, release train trees like linux-next or linux-lts, collaborative staging trees like linux-dri or linux-fi, all of them are managed independently, with different groups of participants, different organizational approaches, and a complex graph of relationships between them. And that's just the trees themselves - multiple independent groups maintain test suites for various subsets of the kernel, a number of bug trackers exist for various purposes, and there are hundreds of mailing lists. Linux is an extreme case, but illustrates my point nicely. The dreamland of project organization that GitHub et al are living in crashes hard against reality for many projects. A lot of people solve this by disabling issues for some repositories, using bots to herd people working in the "wrong" place, etc. Some projects have a workflow which is so dissonant with the GitHub prescription that they resign from it entirely, a group among which Linux is numbered. To this end, I intend to build a centralized project hub, which can be used to define a singular "project", and link together resources under it - both on and off SourceHut, or between multiple SourceHut instances. This would help maintainers organize their project's resources in a way which reflects their actual project structure and guide people to the right place accordingly, and would also be indexable (project discovery is an oft-heard complaint). Linking to related projects or sub-projects is also planned. Anyway, it's not a trivial problem, and I've never been fond of band-aid solutions when a more robust solution is within reach. So I don't think I'd like to quickly implement something which aligns more with GitHub, but I would be very happy to have some help in putting together a better approach. In general, SourceHut will eschew temporary solutions or following the establishment, in favor of taking a more measured approach which might require more time but will arrive at a better solution. A lot of SourceHut's most compelling features today have this approach to thank for it.
