Re: Coming soon: A new site for fully free collaboration

[Drew DeVault]

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.