Bug 119766 – Make bug url more human friendly in ChangeLog

• Status: REOPENED
• Component: Tools / Tests

[Dean Jackson]

It's 2013 - we should not be exposing our bugzilla tool URLs to the web when we have a nice redirect already in place.

Update prepare-ChangeLog to use https://webkit.org/b/id rather than the longer bugzilla form.

The hitch might be to make sure webkit-patch can detect the shorter url.

[Joseph Pecoraro]

I would even prefer a single line for the bug and bug title, like radars:

    <http://webkit.org/b/119766> Make bug url more human friendly in ChangeLog

That would also make `git log --oneline` history for WebKit way easier to read then the current mess.

[Dean Jackson]

Created attachment 208671 [details]
Patch

[Dean Jackson]

OK. Ignore this patch then. BTW, the patch was created with the changes, so webkit-patch works fine.

[Dean Jackson]

Created attachment 208673 [details]
Patch

[Mark Rowe (bdash)]

Comment on attachment 208673 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=208673&action=review

> Tools/Scripts/prepare-ChangeLog:198
> +    my $bugReadableURL;

readableBugURL would be more readable than bugReadableURL.

[Dean Jackson]

Committed r154022: <http://trac.webkit.org/changeset/154022>

[Tim Horton]

This patch broke webkitbot's rollout ability, as it entirely failed to update changelog.py's changelog parsing code. I'm going to fix it in https://bugs.webkit.org/show_bug.cgi?id=120131.

[Tim Horton]

Rolled out in http://trac.webkit.org/changeset/154406.

[Ryosuke Niwa]

There are just too many tools that rely on the old format.  Using wekbit.org/b/<~> URL is good but wrapping them in <> and putting the URL and bug title isn't.

It makes the long way too long for some bugs and wrapping it in < > breaks all sorts of tools.

[Ahmad Saleem]

@Jonathan & Ryan - do we need this now?

We still have 'prepare-ChangeLog' script.