Re: [TDF infra] Announcing Gitiles VCS browser (gitweb replacement) and https:// anon git URIs

classic Classic list List threaded Threaded
14 messages Options
slacka slacka
Reply | Threaded
Open this post in threaded view
|

Re: [TDF infra] Announcing Gitiles VCS browser (gitweb replacement) and https:// anon git URIs

Could you please change the Commit Notification bot back to cgit?

In the 6 months, that I have been testing gitiles, I have found no advantages and many disadvantages over cgit. In general, it presents information in an inferior way and it’s URL’s have led to multiple copy  and paste errors, causing delays in work when the errors were missed.

In his last email, Mike explains how the gitiles timestamps lead to confusion. This is a serious problem for my use case. The other major problem, are the random symbols like “^!” appended to the ends of commit IDs in URLs. I’ve been copy and pasting commit IDs from cgit for years and never once had a problem. With gitiles, it happens regularly despite me being aware.

When I asked for feedback on the IRC dev channel, no one voiced preference for gitiles. I only heard agreement that the URLs and log format are inferior to cgit's.  

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Samuel Mehrbrodt-2 Samuel Mehrbrodt-2
Reply | Threaded
Open this post in threaded view
|

Re: [TDF infra] Announcing Gitiles VCS browser (gitweb replacement) and https:// anon git URIs

Maybe just use the hub redirection, e.g.

https://hub.libreoffice.org/git-core/40264372657160b69b9639eff4fe0263af8f9033

https://hub.libreoffice.org/git-online/eaa4a7838a913979eddd2304053b1697ad596586

Using the hub has the advantage that the links would still work even if cgit.fdo was no longer available, or gitiles was gone, or has another URL syntax, etc.

Regards
Samuel

Am 20.03.2019 um 17:24 schrieb Luke Benes:
Could you please change the Commit Notification bot back to cgit? 

In the 6 months, that I have been testing gitiles, I have found no advantages and many disadvantages over cgit. In general, it presents information in an inferior way and it’s URL’s have led to multiple copy  and paste errors, causing delays in work when the errors were missed.

In his last email, Mike explains how the gitiles timestamps lead to confusion. This is a serious problem for my use case. The other major problem, are the random symbols like “^!” appended to the ends of commit IDs in URLs. I’ve been copy and pasting commit IDs from cgit for years and never once had a problem. With gitiles, it happens regularly despite me being aware.

When I asked for feedback on the IRC dev channel, no one voiced preference for gitiles. I only heard agreement that the URLs and log format are inferior to cgit's.  

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
slacka slacka
Reply | Threaded
Open this post in threaded view
|

Re: [TDF infra] Announcing Gitiles VCS browser (gitweb replacement) and https:// anon git URIs

In reply to this post by slacka
Switching to hub redirection solves the annoying symbols that Gitiles appends to URLs leading to copy and paste errors and the timestamp issue. But it does not address:

* Lack of Built-in, easy to use search functionality
* Lack of branch tags, allowing you to see what release you are on when going through the master log
*cgit is a cleaner, easier to read interface

I have noticed that both QA and Developers continue to post cgit links on the bug tracker. When I have asked on IRC, no developers or QA members voiced support for using Gitiles.

So unless someone has some compelling reasons to keep it, I respectfully ask that the Commit Notification Bot be switch back to cgit. We have tried to use it, and as far as I can tell, universally dislike it.

-Luke
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Miklos Vajna-6 Miklos Vajna-6
Reply | Threaded
Open this post in threaded view
|

Re: [TDF infra] Announcing Gitiles VCS browser (gitweb replacement) and https:// anon git URIs

Hi,

On Thu, Apr 04, 2019 at 05:19:32PM +0000, Luke Benes <[hidden email]> wrote:
> So unless someone has some compelling reasons to keep it, I
> respectfully ask that the Commit Notification Bot be switch back to
> cgit. We have tried to use it, and as far as I can tell, universally
> dislike it.

One more aspect: perhaps I'm just unlucky, but on average, I found cgit
to load much faster than these git.libreoffice.org links. Random
example:

$ time curl -L 'https://git.libreoffice.org/core/+/a54230f3211f19290c4d2ac26b3084fc0a0eeab5%5E!/'
...
real    0m20,420s

$ time curl -L 'https://cgit.freedesktop.org/libreoffice/core/commit/?id=a54230f3211f19290c4d2ac26b3084fc0a0eeab5'
...
real    0m1,381s

Regards,

Miklos

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (201 bytes) Download Attachment
Guilhem Moulin Guilhem Moulin
Reply | Threaded
Open this post in threaded view
|

Re: Gitiles VCS browser

In reply to this post by slacka
On Wed, 20 Mar 2019 at 16:24:49 +0000, Luke Benes wrote:
> In his last email, Mike explains how the gitiles timestamps lead to
> confusion. This is a serious problem for my use case.

You mean https://lists.freedesktop.org/archives/libreoffice/2018-November/081343.html ?
This was addressed on Nov 9…  *author* names are shown along with
*committer* dates in /+log/…?pretty=oneline views (i.e. the default log
view).  Which timestamps are still confusing?
 
> When I asked for feedback on the IRC dev channel, no one voiced
> preference for gitiles. I only heard agreement that the URLs and log
> format are inferior to cgit's.  

Was there more to it than these 3 messages from Fri, 15 Mar around 19:00 CET?

    18:59:02 < slacka123> what are people's thoughts on gitiles vs cgit? There
                          are a few issues that annoy me, like the format for
                          logs and the "^!" symbols that it appends on the end
                          of the URLs, making copy/paste of commit id's a pain
    19:00:09 < slacka123> last message on the dev list was talk of putting cgit
                          back as default commit bot. Would people like to see
                          cgit back?
    19:09:10 <@erAck>     slacka123: the ^! is a tad annoying, but I don't mind
                          that much, once followed there's the raw commit ID as
                          well; the log was clearer with cgit

I might have missed part of the exchange, because from the above I'd say
that your conclusion is quite a stretch.  Moreover IRC isn't really
great for doing polls, especially on Friday evenings :-)

That said the plan with gitiles was to replace gitweb, not cgit, which
is not hosted nor maintained by TDF anyway.  For what it's worth, Björn
asked for the notification change in <20181028095501.GA21770@skorpion>.

--
Guilhem.

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (849 bytes) Download Attachment
Guilhem Moulin Guilhem Moulin
Reply | Threaded
Open this post in threaded view
|

Re: Gitiles VCS browser

In reply to this post by Miklos Vajna-6
Hi Miklos,

On Fri, 05 Apr 2019 at 09:17:01 +0200, Miklos Vajna wrote:
> One more aspect: perhaps I'm just unlucky, but on average, I found
> cgit to load much faster than these git.libreoffice.org links.

Hmm that's interesting.  That's not something I'm able to reproduce by
taking 100 random commits from the last 10000 non-merge commits in
master:

    $ git log -n 10000 --no-merges --pretty="%H" master | shuf -n 100 >/tmp/commit_list

    $ ./measure.sh "<a href="https://git.libreoffice.org/core/+/%s%%5E%%21/">https://git.libreoffice.org/core/+/%s%%5E%%21/" </tmp/commit_list
    […]
                         average  stddev  minimum  maximum
    -------------------  -------  ------  -------  -------
    size (byte)            41906   75197     4564   409087
    start transfer time     0.44    0.42     0.29     2.95
    total time              0.56    0.46     0.30     2.96

    $ ./measure.sh "<a href="https://cgit.freedesktop.org/libreoffice/core/commit/?id=%s">https://cgit.freedesktop.org/libreoffice/core/commit/?id=%s" </tmp/commit_list
    […]
                         average  stddev  minimum  maximum
    -------------------  -------  ------  -------  -------
    size (byte)            70122   63175    39247   390793
    start transfer time     0.37    0.19     0.28     2.06
    total time              0.59    0.34     0.29     2.22

(I'm not running running this from TDF's premises, by the way; though it
wouldn't matter as latency isn't the bottleneck here.)


Repeating the measurement with the same 10 random commits:

https://git.libreoffice.org/core/

                     average  stddev  minimum  maximum
-------------------  -------  ------  -------  -------
size (byte)            19691   17007     4334    64345
start transfer time     0.80    0.68     0.27     2.13
total time              0.86    0.66     0.29     2.17

start transfer time     0.12    0.09     0.08     0.38
total time              0.16    0.09     0.09     0.39

start transfer time     0.12    0.09     0.09     0.38
total time              0.16    0.09     0.09     0.39

https://cgit.freedesktop.org/libreoffice/core/

                     average  stddev  minimum  maximum
-------------------  -------  ------  -------  -------
size (byte)            52903   15767    39077    94857
start transfer time     0.39    0.16     0.30     0.85
total time              0.73    0.30     0.31     1.17

start transfer time     0.23    0.15     0.17     0.67
total time              0.56    0.31     0.33     1.30

start transfer time     0.23    0.15     0.18     0.67
total time              0.56    0.37     0.18     1.48

So on first glance it appears that occasionally a gitiles page takes
longer to load (though I wasn't able to reproduce the 20s you measured,
more like 2-3s in my case).  However it's AFAICT rare enough that it
doesn't impact the average load time.  And caching makes subsequent hits
constantly faster.  (I dunno what's the caching strategy here, something
internal to JGit probably.)

Cheers,
--
Guilhem.

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

measure.sh (1K) Download Attachment
signature.asc (849 bytes) Download Attachment
Kaganski Mike Kaganski Mike
Reply | Threaded
Open this post in threaded view
|

Re: Gitiles VCS browser

On 05.04.2019 19:55, Guilhem Moulin wrote:
> Hi Miklos,
>
> On Fri, 05 Apr 2019 at 09:17:01 +0200, Miklos Vajna wrote:
>> One more aspect: perhaps I'm just unlucky, but on average, I found
>> cgit to load much faster than these git.libreoffice.org links.
>
> Hmm that's interesting.  That's not something I'm able to reproduce by
> taking 100 random commits from the last 10000 non-merge commits in
> master:

 From my observations, the older the commit, the longer it takes. It
might even timeout for some commits from early 2000s.

--
Best regards,
Mike Kaganski
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Guilhem Moulin Guilhem Moulin
Reply | Threaded
Open this post in threaded view
|

Re: Gitiles VCS browser

On Fri, 05 Apr 2019 at 17:07:06 +0000, Kaganski Mike wrote:

> On 05.04.2019 19:55, Guilhem Moulin wrote:
>> On Fri, 05 Apr 2019 at 09:17:01 +0200, Miklos Vajna wrote:
>>> One more aspect: perhaps I'm just unlucky, but on average, I found
>>> cgit to load much faster than these git.libreoffice.org links.
>>
>> Hmm that's interesting.  That's not something I'm able to reproduce by
>> taking 100 random commits from the last 10000 non-merge commits in
>> master:
>
> From my observations, the older the commit, the longer it takes. It
> might even timeout for some commits from early 2000s.
I see, thanks for the tip.  With very old commits I'm indeed able to
reproduce Miklos' metrics.  Should have taken the last 100000 commits, I
guess :-)  That's odd and unfortunate, indeed.

--
Guilhem.

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (849 bytes) Download Attachment
slacka slacka
Reply | Threaded
Open this post in threaded view
|

Re: Gitiles VCS browser

In reply to this post by Guilhem Moulin

Guilhem,

 

There is something wrong with your benchmark methodology.

 

This cgit page loads in under 1 second:

 

https://cgit.freedesktop.org/libreoffice/core/log/sw/source/filter/ww8/docxattributeoutput.cxx?ofs=50

 

While

https://gerrit.libreoffice.org/plugins/gitiles/core/+log/2d6f8c36126effc66ea35af2e65da6609fcfe013/sw/source/filter/ww8/docxattributeoutput.cxx?s=be8c414567f49242164b1fdfb12764b16be355c1

 

takes almost 20 seconds to load in North America. If you are not seeing these results, press next to see the older commits to avoid caching masking gitiles slowness.

 

No one in QA and no developers have voiced a preference for gitiles. Because it's slower, it's UI and UX is harder to read, it lacks useful tools like search,  and the URLs are a pain to work with. It's inferior in every way.

 

So please change the Commit Bot back to cgit.


Thanks


-Luke


 



_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Kaganski Mike Kaganski Mike
Reply | Threaded
Open this post in threaded view
|

Re: Gitiles VCS browser

Hi,

On 06.04.2019 1:46, Luke Benes wrote:
> No one in QA and no developers have voiced a preference for gitiles.
> Because it's slower, it's UI and UX is harder to read, it lacks useful
> tools like search,  and the URLs are a pain to work with. It's inferior
> in every way.

Personally I like URLs like
https://git.libreoffice.org/core/+/6a9cf9ba2d37fee9b7c2f190b347e0d7c4a2676a
being (a) shorter than all alternatives; (b) being libreoffice-related.
I'd like them to stay; I have no problems with expanded form of those,
too. After my concerns about dates were addressed, I only would like if
redirection to the actual (gitiles) address would be something internal,
not resulting in browser URL change.

Of course, the performance issue is something to solve, too, but that is
a technical task, which is not a blocker for me.

--
Best regards,
Mike Kaganski
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
slacka slacka
Reply | Threaded
Open this post in threaded view
|

Re: Gitiles VCS browser

Mike,
That is not an apples to apples comparison. In your browser open and compare side-by-side:

https://git.libreoffice.org/core/+/6a9cf9ba2d37fee9b7c2f190b347e0d7c4a2676a
and
https://cgit.freedesktop.org/libreoffice/core/commit/?id=6a9cf9ba2d37fee9b7c2f190b347e0d7c4a2676a

Do you really like all of the extraneous information? Do you like the missing search bar? Do you like having to scroll down several pages to see the relevant information? Do you like the lack of a search bar?

Besides the fact, these are not what the commits look like on our bug trackers. From

https://git.libreoffice.org/core/+/bf2f0c913774c90e4c9a65119d0219187bb4498c%5E%21
while the old cgit would be
https://cgit.freedesktop.org/libreoffice/core/commit/?id=bf2f0c913774c90e4c9a65119d0219187bb4498c

Now try to copy the commit ID from the gitiles and do the same for the cgit URL. Do you really prefer the random symbols appended to the end? I can tell you git does not and will puke if you accidentally include any of them.
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Kaganski Mike Kaganski Mike
Reply | Threaded
Open this post in threaded view
|

Re: Gitiles VCS browser

On 06.04.2019 17:18, Luke Benes wrote:
> Mike,
> That is not an apples to apples comparison. In your browser open and compare side-by-side:
>
> https://git.libreoffice.org/core/+/6a9cf9ba2d37fee9b7c2f190b347e0d7c4a2676a
> and
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=6a9cf9ba2d37fee9b7c2f190b347e0d7c4a2676a
>
> Do you really like all of the extraneous information?

Do you mean the tree below? Well - it doesn't hurt me. But if it went
away (with a link to easily reach the tree from that page), I'd not protest.

> Do you like the missing search bar?

It doesn't matter *for me*, because I don't use it anyway. But I can see
how people might miss it.

> Do you like having to scroll down several pages to see the relevant information?

I don't quite get that. Which information on that page requires to
scroll down several pages in gitiles, which does not on cgit?

> Do you like the lack of a search bar?

This is not the fourth argument, but rather the second ;-)

> Besides the fact, these are not what the commits look like on our bug trackers. From
>
> https://git.libreoffice.org/core/+/bf2f0c913774c90e4c9a65119d0219187bb4498c%5E%21
> while the old cgit would be
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=bf2f0c913774c90e4c9a65119d0219187bb4498c
>
> Now try to copy the commit ID from the gitiles and do the same for the cgit URL. Do you really prefer the random symbols appended to the end? I can tell you git does not and will puke if you accidentally include any of them.

For me, double-clicking commit number in the address bar in Chrome on
Windows (e.g., between b and f in the URL above), selects the commit ID
without the trailing part. Well - of course, if the commit diff were
right on that initial page without ^! (after the changed files list),
I'd also not protest.

--
Best regards,
Mike Kaganski
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
slacka slacka
Reply | Threaded
Open this post in threaded view
|

Re: Gitiles VCS browser

It is telling that when I asked what you prefer, you answered that the extraneous information “doesn't hurt “. Your tolerance to noise may be higher than many, but it’s a well-established fact the less clutter in the UI, the faster it is for humans to use.  Gitiles is fails here, takes longer to load, requires additional clicks, and is missing search tools and branch tags.

-Luke


_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
slacka slacka
Reply | Threaded
Open this post in threaded view
|

Re: Gitiles VCS browser

In reply to this post by slacka
Guilthem,
Why have you not answered my question about returning the Commit Bot back to cgit?

Gitiles is wasting our time. For example, just now I followed the commit bot link on tdf#42949 to

https://gerrit.libreoffice.org/plugins/gitiles/core/+log/63a25b79f18fda29cd744add813ce9508c69b996/sw/source/core/inc/dflyobj.hxx

In North America the paged timed out while trying to load. So I had to stop open cgit, and manually construct this link:

https://cgit.freedesktop.org/libreoffice/core/log/sw/source/core/inc/dflyobj.hxx

Which surprise, surprise loaded instantly. Why must we use inferior tools that slow down our workflow for QA and developers? At least in QA, most of us are volunteers that would rather not spend our time copy and pasting to use the tools that we all prefer. Please return the bot to cgit.

Follow the links below and you will see that both developers and QA are currently pasting cgit links into our bug tracker.

Xisco: https://bugs.documentfoundation.org/show_bug.cgi?id=124410
Gabor: https://bugs.documentfoundation.org/show_bug.cgi?id=124319
Julien: https://bugs.documentfoundation.org/show_bug.cgi?id=122821
Chih-Hsuan: https://bugs.documentfoundation.org/show_bug.cgi?id=123595
Aron: https://bugs.documentfoundation.org/show_bug.cgi?id=122509

From a QA workflow perfective, Gitiles is inferior in every way. On IRC -dev no devs spoke out in favor of Gitiles over cgit, and here the best defence from a developer here has been "it doesn't hurt". Please put back cgit to allow us to work more efficiently.

Thanks

-Luke


_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice