On 11/19/2017 09:08 AM, William Gathoye wrote:

Bugzilla is old both in terms of look and feel and usability. It doesn't even support Markdown formatting[1], 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[2]. 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).

I cannot think why we are especially in need of markdown, I guess it is nice to have but I never regarded it as critical. If it is just to inline a patch I consider it a lot kinder to attach a patch that I can download rather than inline a patch that I have to convert from text on a webpage into a patch file.

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.

OTOH, gitlab is complicated to package and occasionally breaks, which would be embarrassing if we could not report bugs against the package because the package is broken and we don't have a bugtracker... And it's also a git repository server first and a rudimentary issue tracker second, so a "real" bugtracker would be preferable for the flexibility they offer.

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' [3] 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).

We cannot migrate to git because no one has put in the work necessary to properly rewrite dbscripts. And if we had git for dbscripts, we would do quite well with our current cgit interface, which is... a git infrastructure. Don't forget that *the* standard git-based infrastructure is, well, git-send-email. And the reason people don't do that, nor do they attach patches for our svn repos, is mostly because reporting bugs is a lot easier than fixing them, and every target userbase is different. There are lots of other projects which get *lots* of contributions in the form of patches emailed or attached to bugzillas.

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).

I hereby volunteer to take the two minutes needed to write a synchronization script between cgit and and Github, should we desperately need one.

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[4].

Hiding a bug that isn't getting fixed doesn't make it go away, and I have a visceral hatred of systems that do so. Filtering based on Feature Requests (which can potentially languish for years before someone is inspired to implement it, but are no less valid) and Bugs, which should never ever be closed unless they are either fixed or determined to be invalid, is pretty easy in basically any proper setup. In the very much less common event that a bug is actually waiting on a response from the reporter in order to determine whether it is valid, that is why we have a "Waiting for Response" category, which should only ever be manually set when it is determined that that is the correct response, and which I dubiously suppose could in theory be automated for closure but which isn't really a problem as we can handle doing so automatically. This whole mindset seems to come from a world which is dominated by developers of some project who don't have time to handle every bug report, are already resigned to only fixing the most visible bugs or the ones with the most insistent reporters who don't ever give up when a bugfix takes a long time due to the aforementioned issue of developers not having enough time to even look at bugs, let alone fix them, and want some way to sweep their trash under the rug so they don't have to see the warts. Just in case you were wondering how I feel about this. :) -- Eli Schwartz

On 11/19/2017 11:04 AM, Florian Pritz via arch-general wrote:

On 19.11.2017 16:24, Eli Schwartz wrote:

...

We cannot migrate to git because no one has put in the work necessary to properly rewrite dbscripts.

Just to clarify: Gabriel Souza Franco (gbsf) has put quite a lot of work into this and some others have also worked on parts, but we haven't yet assembled all these parts or come up with a migration plan. It's a complex process and the people with sufficient access to deal with it are sadly quite busy. Additionally svn works well enough for our use case and other, more pressing, issues get priority. Git is certainly not forgotten and work will continue, but it may take a while until it's done.

Yes, this is a good point. :o I should have said "no one has put in all the work to finish". Apologies. -- Eli Schwartz

On Sun, 19 Nov 2017 17:58:55 +0100 William Gathoye wrote:

This is why at The Document Foundation and Mattermost, we have a QA team (or at least one or two persons) which checks if the bugs are valid and put in cc the people that have the abilities to work on it. I know all of us have a life aside FOSS projects, but sometimes, even if the dev put in cc cannot actually work on the fix for the bug itself, he might answer a question in 2 minutes and help another one that will actually do the fix for him: bringing synergy in the process.

From my understanding and the time I spent following this community (I'm subscribed to all Arch Linux public mailing lists and have been reading all the message every weekend since 2012), a true bug triager person is something I haven't seen in Arch yet (unless I'm wrong).

That is exactly what Eli and I do.

On Sun, Nov 19, 2017 at 7:54 PM, Bartłomiej Piotrowski wrote:

On 2017-11-19 17:58, William Gathoye wrote:

...

I'll be using Gitlab professionally on Arch Linux. So as soon I become a TU (if it happen the Arch Linux community accepts me ;)) I think I'll help Sven-Hendrik Haase in this process. Packaging Gitlab as a single person is indeed a hard task.

There is more to reliability of service than correct and reliable packaging. By any means Gitlab isn't "fire & forget" type of project and with my infra team hat on, I'm completely unwilling to spend my evenings or lunches on making sure it's running properly.

...

This is why at The Document Foundation and Mattermost, we have a QA team (or at least one or two persons) which checks if the bugs are valid and put in cc the people that have the abilities to work on it. I know all of us have a life aside FOSS projects, but sometimes, even if the dev put in cc cannot actually work on the fix for the bug itself, he might answer a question in 2 minutes and help another one that will actually do the fix for him: bringing synergy in the process.

From my understanding and the time I spent following this community (I'm subscribed to all Arch Linux public mailing lists and have been reading all the message every weekend since 2012), a true bug triager person is something I haven't seen in Arch yet (unless I'm wrong).

With all due respect, we are not a foundation or project that also sells membership or deployments/hosted service. We already have people responsible for bug triaging, some of packagers also chime in occasionally. It's being accomplished fully in free time, so I don't see the point of comparison. This includes finding people who can actually fix given bug if someone who should do that is missing. Forgive us for not doing as good job as others, but in my opinion, we're doing quite fine.

Bartłomiej

I've refrained from commenting on this topic because I don't want to sound ungrateful people are taking the time to work on a fairly extensive migration off flyspray, but I'm not looking forward to Bugzilla (and I've contributed to a lot of Bugzilla-based projects in the past). It has the same mindset as Jira, making filing an issue a similar endeavour as filing taxes and creating artificial meta-work for both users and triagers. I strongly agree something like Gogs or Gitlab would be a much better path forward. Especially if, as Jelle was initially saying, the goal is for it to be "extended to our wishes". Furthermore, Gitlab has native support for federated login which we seriously could start using. Separate logins for bug tracker, BBS AUR, wiki, archweb and all the mailing lists is... eh. J. Leclanche

2017-11-19 18:54 GMT+01:00 Bartłomiej Piotrowski :

On 2017-11-19 17:58, William Gathoye wrote:

...

I'll be using Gitlab professionally on Arch Linux. So as soon I become a TU (if it happen the Arch Linux community accepts me ;)) I think I'll help Sven-Hendrik Haase in this process. Packaging Gitlab as a single person is indeed a hard task.

There is more to reliability of service than correct and reliable packaging. By any means Gitlab isn't "fire & forget" type of project and with my infra team hat on, I'm completely unwilling to spend my evenings or lunches on making sure it's running properly.

Why don't talk with GitLab people to get a free hosted solution? As you can see in his page[1] they offer "the very best full gold plan of the death" to Open Source projects. In this way you can devote your resources to other tasks and forget the Git/GitLab administration. Greetings. [1]:https://about.gitlab.com/gitlab-com/ -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me

From: Jelle van der Waa Sent: Tue Nov 21 10:36:08 CET 2017 To: General Discussion about Arch Linux Subject: Re: [arch-general] [arch-dev-public] Switching the bugtracker to Bugzilla

I'm quiet happy that we are still running everything on our (community sponsored) infrastructure without relying on third party's. This has a lot of benefits, we own the data, we can migrate freely to an alternative and we don't rely on externals messing things up or changing their offering.

A sponsored hosted platform sounds amazing, but having a vendor lock in isn't really :-)

-- Jelle van der Waa ----------------------------------------

That also means you have to manage everything on your own. As Arch is quite constrained on human resources this is rather huge dis-benefit. More and more projects like gnome or debian are migrating to something like gitlab/github so the advantages are real. Thinking strategically, moving to bugzilla will be one step forward but it still leaves Arch on relative backwardness. Why don't take two steps at once instead? Migrating one service will make migrating others easier. I know that Arch devs main priority as pure volunteer project is to minimize effort however it involves danger of being left in obscurity and quite unmanageable state. In the end moving faster may require less effort. The whole web is going to vendor lock-in model and it isn't really obvious that staying out is better choice. G. K.