On Friday, February 14, 2014 22:52:04 Jeff Mitchell wrote: > However, in the intervening years, GitLab (https://www.gitlab.com/) has
Playing around with the demo a bit this morning, there are a number of benefits I see, most of which you already mentioned. The big one for me is the integration; that it feels a lot like github in style is a bonus too, as that should make KDE infrastructure feel more familiar to many new comers. It will mean a period of learning new tools by people used to what we have now, and a lot of dead links to projects.kde.org floating around out there unless there is some magical rewrite system implemented .. but those are not blocker issues imho. > Due to its feature set, GitLab alone could take the place of at least > projects.kde.org, commits.kde.org, quickgit.kde.org, and -- due to the > built-in merge request workflow -- reviewboard.kde.org, drastically > easing management and maintenance burden for the sysadmins. If the That’s a definitely plus and perhaps all the reason we need. I suppose sysadmin has already looked into what it will take to integrate it with identity.kde.org. You didn’t mention that in your email, but I assume that was probably one of the first things you did :) Since you said that gitlab has been doing well to gain adoption, I imagine that we will continue to see it grow or at least be maintained for a good while. That’s obviously quite important for KDE ... > built-in wiki and issue tracking capabilities are enabled (which can be > managed per-project), then projects (especially self-contained ones, > such as Extragear projects) that desire a highly integrated workflow > could migrate those functions to GitLab as well (note that this is not a > statement indicating that we are planning to ditch Bugzilla any time > soon!). I suppose a project could use the issue tracking as an internal project task list, which would be nice to have. Bugzilla is great for the public interaction, but that also makes its use for task lists not overly useful. It’s not a kanban board, but it’s at least a step up from what we have now on KDE infrastructure. > This email serves two purposes: one, to inform the community of the > direction we would like to go with KDE's Git hosting and request > feedback; two, to ask for volunteer projects that are willing to act as > crash test dummies for the new system, helping us figure out the best > way to set it up, work out kinks, etc. Due to the bleeding-edge nature, > we're currently limiting this to self-contained projects, such as those > in Extragear. I’d be happy to engage in this process with Sprinter. It’s self-contained and active. -- Aaron J. Seigo _______________________________________________ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community