salsa.debian.org (git.debian.org replacement) going into beta
External users are invited to create an account on salsa. To avoid clashes with future Debian Developers, we are enforcing a '-guest' suffix for any guest username. Therefore we developed a self-service portal which allows non-Debian Developers to sign up, available at https://signup.salsa.debian.org. Please keep in mind that your username will have '-guest' appended."
| From: | Alexander Wirt <formorer-AT-debian.org> | |
| To: | debian-devel-announce-AT-lists.debian.org | |
| Subject: | salsa.debian.org (git.debian.org replacement) going into beta | |
| Date: | Mon, 25 Dec 2017 11:45:37 +0100 | |
| Message-ID: | <20171225104537.GG6919@smithers.snow-crash.org> |
Hi, Since summer we have worked on our git.debian.org replacement based on GitLab. I am really happy to say that we are launching the beta of our service today. Please keep in mind that it is a beta, we don't expect any database resets, but under unexpected circumstances it might still happen. The new service is available at https://salsa.debian.org. Every active Debian Developer already has an account. Please request a password reset via https://salsa.debian.org/users/sign_in -- your login is either your Debian login or Debian e-mail address. SSH Keys from udldap get synced into your account. Guest users ----------- External users are invited to create an account on salsa. To avoid clashes with future Debian Developers, we are enforcing a '-guest' suffix for any guest username. Therefore we developed a self-service portal which allows non-Debian Developers to sign up, available at https://signup.salsa.debian.org. Please keep in mind that your username will have '-guest' appended. Project creation ---------------- Every user can create projects in their own namespace (similar to GitHub). Teams ----- For larger projects you can also create a group to host your projects. To avoid clashes with usernames (that share the same namespace as groups) we are requiring groups to have a '-team' suffix to their name. Groups can be created using the same self-service portal https://signup.salsa.debian.org. For larger, already-established teams it is also possible to ask us to create the group with a name not conforming to the normal team namespace. Examples are teams like *debian-qa*. Please create an issue in the support[1] project. Collab-maint ------------ If you want to allow other Debian Developers to work on your packages or software, you can create projects within the **Debian** group. Every Debian Developer has write access to projects created in this group. If you create a project within the Debian group, you are implicitly welcoming all DDs to contribute directly to the project. Guest users can only be added to individual projects with the Debian group, but not to the entire Debian group. This is different to the policy for the collab-maint group on Alioth. GitLab runners -------------- We won't provide any shared Gitlab runners for now. If you want to sponsor resources for such runners please contact us. Gitlab pages ------------ We will support Gitlab pages in the future, but more work is needed first. We will post an update when they are ready. Migration of repositories ------------------------- We don't plan to do any automatic migration of alioth repositories. If you use a repository and think it is important (!) migrate it on your own. We will provide a read-only export of all repositories that weren't exported after disabling alioth. Timeline -------- We want to run this beta at least for four weeks. If everything goes well we intend to leave beta around the end of January. Documentation ------------- Documentation of the service will happen in the Debian Wiki [2]. Please feel free to enhance the documentation. See also the upstream GitLab docs [3]. Getting help ------------ If you have problems with the service you can reach us: - IRC: #alioth@irc.debian.org - Mailing list: https://lists.alioth.debian.org/mailman/listinfo/alioth-s... - Issue tracker: https://salsa.debian.org/salsa/support/issues Don't expect us to be responsive during the holidays, so be patient :). Request for help ---------------- If you want to take part in salsa administration please get in touch with us. We want to have at least two more administrators for the Gitlab instance. Thanks for your attention Alex on behalf of the salsa team [1] https://salsa.debian.org/salsa/support [2] https://wiki.debian.org/Salsa/Doc [3] https://docs.gitlab.com/ee/README.html
Posted Dec 27, 2017 5:38 UTC (Wed)
by hosiet (subscriber, #106062)
[Link] (4 responses)
Posted Dec 28, 2017 1:27 UTC (Thu)
by jlargentaye (subscriber, #75206)
[Link] (3 responses)
Sounds like an updated article is required :)
Posted Dec 28, 2017 9:40 UTC (Thu)
by Felix (guest, #36445)
[Link] (1 responses)
from the gobby minutes (https://gobby.debian.org/export/Sprints/AliothSuccessors2...):
The question I can not answer is why they chose GitLab over Pagure as I was unable to find a summarizing post (aside from vague statements and suggestions).
Still I think the decision to go with GitLab is probably better than using Pagure as GitLab has way more features and a dedicated company behind which continues to add new features with full-time developers. Even if they encounter some conflicts due to GitLab's "open core" model it is probably less work to patch the missing features than carrying the a major share of the development effort (as Pagure has no commercial backing AFAIK).
Gnome is also moving to Gitlab so I assume the major issues with "big number of contributors but we want to use the open source version" were resolved.
Now Fedora just started to use Pagure and that is fine but I'm wondering if a move to Gitlab would be a wiser building such basic infrastructure like a git hosting platform on your own. IMHO the effort is better spent on really custom tools which you can't get of the shelf (maybe build platforms, release engineering+packaging tools) and I'm saying this as a Fedora packager and Python developer who does not really like Ruby on Rails. Anyway, I'm not doing the work so I'll trust Fedora admins that they found the best solution for Fedora as a whole.
Posted Dec 29, 2017 20:49 UTC (Fri)
by jdulaney (subscriber, #83672)
[Link]
Posted Dec 29, 2017 20:47 UTC (Fri)
by xtifr (guest, #143)
[Link]
Posted Jan 2, 2018 18:14 UTC (Tue)
by mirabilos (subscriber, #84359)
[Link] (8 responses)
Funnily enough, the Gitlab EE documentation is linked, although it’s, at least, a CE version.
After logging in, https://salsa.debian.org/api/v4/version shows it’s a version 10.x while Debian has 8.x in stable and unstable and 9.x in experimental.
This smells really fishy.
Posted Jan 3, 2018 0:07 UTC (Wed)
by zoobab (guest, #9945)
[Link]
Time for PPA for Debian.
Posted Jan 3, 2018 2:42 UTC (Wed)
by Conan_Kudo (subscriber, #103240)
[Link] (4 responses)
Posted Jan 3, 2018 5:57 UTC (Wed)
by pabs (subscriber, #43278)
[Link] (3 responses)
https://lists.debian.org/msgid-search/20160718170320.GI21...
Posted Jan 3, 2018 11:52 UTC (Wed)
by Conan_Kudo (subscriber, #103240)
[Link] (2 responses)
Posted Jan 3, 2018 12:59 UTC (Wed)
by pabs (subscriber, #43278)
[Link] (1 responses)
Posted Jan 3, 2018 16:21 UTC (Wed)
by Conan_Kudo (subscriber, #103240)
[Link]
Posted Jan 3, 2018 11:36 UTC (Wed)
by formorer (guest, #17518)
[Link] (1 responses)
Posted Jan 3, 2018 16:34 UTC (Wed)
by mirabilos (subscriber, #84359)
[Link]
DSA wants packages from stable or stable-backports, if packages are at all used, AFAICT.
Installing into a user’s ~ was also possible for services. But it still smells fishy.
FusionForge (the software behind Alioth) was usable as packaged in Debian.
Dogfooding is good.
salsa.debian.org (git.debian.org replacement) going into beta
salsa.debian.org (git.debian.org replacement) going into beta
salsa.debian.org (git.debian.org replacement) going into beta
> * Decision: We are going with GitLab and we are using upstreams packages.
salsa.debian.org (git.debian.org replacement) going into beta
salsa.debian.org (git.debian.org replacement) going into beta
salsa.debian.org (git.debian.org replacement) going into beta
salsa.debian.org (git.debian.org replacement) going into beta
The whole process of selecting GitLab after selecting Pagure was really fishy.
I've been sitting in the Pagure communication channels for well over a year, and I've only seen a couple of messages hinting around Debian packaging for Pagure. But obviously that never went anywhere.
I'm friends with a few Debian Developers (who will remain nameless to protect the innocent) and they're frustrated and upset about the "decision" but there's nothing they can do about it. One was particularly angry about the usage of GitLab's omnibus "blob" packages, since they're basically unverifiable goops of bundled software. But, apparently, DSAs can do what they want, for the most part...
But you know what? It's okay, Debian wants GitLab more than it wants to use software that it can offer in its own repositories to its own users. They can use whatever excuse they want to avoid the fact that Pagure was the one voted for because it's fully Free Software and complies with their own ethics (and isn't a pain to package and keep up to date, too!).
Pagure is getting better, and there are even features in Pagure that don't exist in GitLab, like remote pull requests! It has CI hooks for integrating with your CI system of choice. It supports fully email-based workflows (I hear Debian people seem to like that). Most of the actual "data" of Pagure is stored as Git repositories (issues, wiki, docs). Service integration is supported via FedMsg (which Debian has an instance in their infrastructure) or via regular webhooks.
As of today, Pagure supports every desired feature on the feature matrix in the gobby notes from the Alioth Successors 2017 Sprint except mirroring. Pull mirroring could be implemented through a service, and an (admittedly somewhat old) PR implements push mirroring support. You don't get these features with GitLab CE either, so I don't know why they listed it as an available feature.
Fortunately (or unfortunately, depending on your point of view), Debian does not mandate a specific way for sources to be managed for Debian packages. You're totally free to host the packaging sources wherever and hook it up to Debian infrastructure. There are even package sources hosted on GitHub pointed to Debian. So, if no one takes up the mantle to get a Pagure-based Alioth service up, there's always space on Pagure.io.
salsa.debian.org (git.debian.org replacement) going into beta
salsa.debian.org (git.debian.org replacement) going into beta
Well, that's sad. :(
FedMsg isn't strictly a requirement for service integration, but it's a really nice way to do it.
And parsing emails is horrible. :/
salsa.debian.org (git.debian.org replacement) going into beta
salsa.debian.org (git.debian.org replacement) going into beta
That doesn't really change my statement that parsing emails is horrible. :)
salsa.debian.org (git.debian.org replacement) going into beta
salsa.debian.org (git.debian.org replacement) going into beta
salsa.debian.org (git.debian.org replacement) going into beta