On 11/14/2017 10:34 PM, Bartłomiej Piotrowski wrote:
On 2017-11-14 20:30, Jelle van der Waa wrote:
Used by several big projects such as Gnome, LLVM and Mozilla
GNOME will probably end up switching to Gitlab. (Not dismissing the fact that bugzilla is rather popular choice.)
Bugzilla is old both in terms of look and feel and usability. It doesn't even support Markdown formatting, which could have been nice in order to be on part with the Markdown feature brought with the forthcoming aur web version. Contributing from a mobile device is rather complicated with bugzilla, even if I know some kind of non-maintained addon is available. We can't see properly the pull requests being made to solve a specific problem and I know the Bugzilla's UI doesn't encourage them (just ask the Document Foundation about it).
This is why, if I was in a position to provide a vote, I would have chosen a solution like gogs or Gitlab instead, which fixes the aforementioned problems and are well-maintained. On a side note, I'm currently in the process of rewriting the Gitlab install guide on the ArchLinux wiki, because I need it for corporate purpose and according to comments on the talk page, that article is hard to understand for newcomers.
In the same process, gogs/Gitlabs would allow the opportunity to migrate the svn infra used for official packages to a real git-based infrastructure. svn-to-git, even if we have 'abs'  as syntactic sugar, adds unneeded cluttering. The current infra for official packages is blocking new contributions (I remember the cumbersome process it was for me to push 2 fixes to openjfx, patches via email is from an old age).
Also, having an infra like gogs/Gitlab could allow us to have our Github ArchLinux account becoming the official read-only mirror for Arch Linux (yet another free backup). Synchronization scripts between both systems do already exist (I can ask at The Document Foundation if needed).
There are several options for migrating the bug history to Bugzilla and a few options are under debate. (input welcome)
As I said multiple times on IRC, I'm for starting from scratch. There are way too many inactive or/and incorrect bugs open, and honestly any effort to review that list is a waste of time. With no bugs open we can
- pretend everything works fine 2) hopefully avoid zombie-bugs
apocalypse that we have now. Flyspray could be mirrored with wget for read-only version.
When I migrate something, I don't like to have anything legacy in an infrastructure. I usually migrate everything and do not leave a publicly accessible web app, especially if the latter isn't maintained any more, and has multiple security vulnerabilities. This doesn't prevent us to keep a complete offline backup copy if needed.
Migrate everything doesn't prevent us to not close old bugs either.
In this regard, it would be nice to have a policy to auto-close bugs that haven't received comments/reactions within x day. Any way, if a contributor has anything to add, he could reopen it if needed. Having a more strict bug triaging policy is usually good and reminds me a recent article I read on the Gitlab.com blog.
Just my two cents :)
Ps.: I'm writing on arch-general, because I don't have write access to arch-dev-public, I'm not a TU (yet, but my application will come in the months to come, currently getting prepared to it), I'm just a Arch Linux user/contributor and have been since 2012 actually).
 https://bugzilla.mozilla.org/show_bug.cgi?id=330707  https://wiki.mozilla.org/Bugzilla:Addons#Handheld_Clients  https://wiki.archlinux.org/index.php/Arch_Build_System#Retrieve_PKGBUILD_sou...  https://about.gitlab.com/2017/10/26/triage-issues-gitmate/