GitHub?

Posted May 16, 2017 15:52 UTC (Tue) by ebassi (subscriber, #54855)
In reply to: GitHub? by NightMonkey
Parent article: A proposal to move GNOME to GitLab

We have a full mirror on GitHub already.

To be fair: issue tracking on GitHub is pretty dire, and it's very much repository-oriented; you cannot move issues between projects under the same organisation, for instance. Virtually any complex project spanning multiple repositories that I know of — including commercial ones, though the enterprise version — hosted on GitHub end up moving away from GitHub issues to their own self-hosted issue and project management tracker.

Additionally, and this is my personal opinion, I think it's not great form for a free software project the size of GNOME to switch to a closed platform like GitHub.

GitHub?

Posted May 16, 2017 18:09 UTC (Tue) by SEJeff (guest, #51588) [Link] (1 responses)

Emanuel, that is incorrect, and has been for a bit.

https://github.com/blog/2272-introducing-projects-for-org...

https://github.com/blog/2256-a-whole-new-github-universe-...

Projects most definitely support multiple repos and their kanban board support isn't too bad honestly.

I do agree that something that goes out of the way to be libre (GNOME) shouldn't be primarily hosted on non-libre software (github) while my personal opinion is

GitHub?

Posted May 16, 2017 18:36 UTC (Tue) by ebassi (subscriber, #54855) [Link]

I know about Projects, and they are really not what I meant.

Example: if I, a user, end up filing a bug against application A, and the maintainer, after triage, decides that it's really an issue of a dependency inside GNOME, even if application A and the dependency are part of the same project, the issue is still assigned to application A; creating a project just means that you can see all the issues that are part of the project.

Of course, the way it's meant to be used is to have multiple projects inside the same organisation — say: SDK, applications, infrastructure, etc. This still does not allow me to move an issue from application A, inside the "applications" project, to the dependency inside the "SDK" project.

Issues still require me to open a new issue inside the dependency's repository (either directly or by turning a note into an issue), and then have a commit/merge message that looks like:

Fixes: organization/application-a#1234
Fixes: organization/toolkit#2345

With the chance of forgetting either issue, and then having to close issues left "dangling".