[webkit-dev] WebKit Transition to Git

Wed Oct 7 14:22:18 PDT 2020

Hello,

On Wed, 07 Oct 2020 04:17:45 +0300 Konstantin Tokarev <annulen at yandex.ru> wrote:

> 06.10.2020, 18:03, "Michael Catanzaro" <mcatanzaro at gnome.org>:
> > On Tue, Oct 6, 2020 at 3:13 am, Konstantin Tokarev <annulen at yandex.ru>
> > wrote:
> >>  1. Sub-par support for linking issues to each other
> >>  ------------------------------------------------------------
> >>
> >>  Traditional bug tracking systems (like Bugzilla or JIRA) have support
> >>  of "related" or "linked" issues. Most important relations are
> >>
> >>  * A depends on B (B blocks A) - blockers and umbrella issues
> >>  * B is duplicate of A
> >>  * A and B are related in other unspecified way
> >
> > GitHub does have duplicates btw, but the syntax is completely different
> > from GitLab so I can never remember how it's done. It's not exposed in
> > the UI. In GitLab it's easy: /duplicate #245 to mark a bug as duplicate
> > of issue #245. (You can have cross-repo duplicates too, and I think
> > even cross-*project* duplicates. This is very important for GNOME, but
> > not for WebKit since WebKit is just one huge repo.)
> >
> > I found instructions for GitHub here:
> > https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/about-duplicate-issues-and-pull-requests#marking-duplicates
> >
> >>  * There is no easily visible list of relations: if you are not
> >>  closely following all activity on A, to find all issues related to it
> >>  you have to browse through all its (pseudo-)comments, which in some
> >>  cases might be long.
> >>  * There is no *stateful* list of relations: if A was believed to have
> >>  common source with B, but then it was discovered they are not
> >>  related, you cannot delete relationship between A and B because there
> >>  is no relationship, just a set of comments.
> >
> > In my experience, this isn't really a *huge* problem. Umbrella issues
> > work well enough to track relationship between bugs, as do milestones,
> > and you can use whichever you prefer. I admit it is not nearly as nice
> > as Depends/Blocks from Bugzilla, though. But I think it should be good
> > enough for us.
> >
> >>  * "#<number>" is not a safe reference format. Sometimes users'
> >>  comments may have other data in "#<number>" format with a different
> >>  meaning than references to GitHub issues. For example, may the force
> >>  be with you if someone pastes gdb or lldb backtrace into comment
> >>  without escaping it into markdown raw text block (```). Also, GitHub
> >>  parses mentions in git commit messages, so care must be taken to
> >>  avoid any occurrences of "#<number>" with a meaning different from
> >>  reference to issue number.
> >
> > Yeah this is unfortunate and also guaranteed to happen. The first
> > several dozen issues are going to be spammed with references to other
> > bugs all over the place.
> >
> >>  [2] For some reason they have shared numbering, which means sometimes
> >>  you may not know what kind of reference is in front of you until you
> >>  look up its URL or navigate
> >
> > This is silly too (and not a problem on GitLab, which uses # for issues
> > and ! for merge requests). But although I agree it is a defect, is it
> > really a huge problem? Probably not.
> >
> >>  Also, on test cases. You probably like this feature of Bugzilla when
> >>  you can attach self-contained HTML file to the issue and then simply
> >>  open it by URL in any browser including your build of WebKit to try
> >>  it out. Forget this - GitHub simply forbids HTML or JS attachments
> >>  (without wrapping them in archive):
> >>
> >>      "We don’t support that file type. with a GIF, JPEG, JPG, PNG,
> >>  DOCX, GZ, LOG, PDF, PPTX, TXT, XLSX or ZIP."
> >>
> >>  And yes, take care not to use tar.xz or tar.bz2 or any other
> >>  unapproved archive type.
> >
> > OK, now you've convinced me... this is bad. :P I forgot about this
> > problem because GitLab does not have any such restrictions on
> > attachments. It's very frustrating to have to say "I added a .txt file
> > extension so I could upload this to GitHub. Please remove the file
> > extension after you have downloaded the file before you use it." I
> > would say this is strongest argument I've seen against GitHub. Silly
> > problem to have tbh.
> >
> > I'll just add that GitLab has become *really* popular for Linux-related
> > projects. I have to regularly work with GNOME GitLab, freedesktop
> > GitLab, and gitlab.com. Fedora and CentOS are both switching to GitLab
> > too, so soon that will be five different public GitLab instances that I
> > have to switch between regularly, and that's limited to only the public
> > instances. Then there are also many major communities I don't work with
> > that are also using GitLab (KDE, Debian, Purism).
> 
> FWIW, KDE is using Bugzilla for bug reporting, and Debian uses debbugs.

Not that debbugs would be particularly user-friendly… ;-)

> > It's reached the
> > point where unless you only work on Linux kernel itself, you probably
> > spend a lot of time on one GitLab or another. It should be considered
> > alongside GitHub as an option, especially if we're concerned about
> > GitHub-specific problems.
> 
> This is certainly non-representative, but among the projects /me personally 
> have interacted recently almost all use GitHub Issues, Bugzilla, or JIRA for
> bug reports.

I could also point out a few more well-known projects which use Bugzilla and
that I have used their bug trackers recently: Firefox (of course!), Gentoo,
Buildroot, and RedHat/Fedora. And for one that uses a completely different
thing: the that Arch Linux distribution uses Flyspray.

I've used JIRA quite a lot lately and I don't like it much. It makes me sad to
use it, in the same way GitLab makes me sad: it is so bloated and slow that
every time I have to load a bug page something dies inside of me while the
page has started to be displayed but one cannot interact with it for the next
30s (often not even scroll) because of the unwieldy JavaScript usage to load
bug details and comments—which could have been returned by the server along
with the page HTML… and don't get me started by the client-side page loads,
which are even slower than forcing full page load by copying the link one
wants to follow and copy-pasting it in the URL entry (GitHub also has this
problem, it's sad).

Cheers,
—Adrián
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20201008/12e15979/attachment.bin>