[arch-general] [arch-dev-public] Switching the bugtracker to Bugzilla

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20171119/a0e56c15/attachment.asc>