Is webrev generation still relevant?

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Jan 18 18:12:47 UTC 2024


I also use full webrev for searches.

It also much easier extract patch for testing when you have a lot of incremental changes in PR and you need to test not 
last version during review. May be there is a way to do it with GitHub but webrev links are right on front page and easy 
to access.

Thanks,
Vladimir K

On 1/18/24 7:57 AM, Chris Plummer wrote:
> I rely on it pretty heavily. It provides better context than side-by-side, and also makes it easy to find other relevant 
> code in the file that might not show up in the diffs.
> 
> Chris
> 
> On 1/18/24 1:04 AM, Magnus Ihse Bursie wrote:
>> At the onset of Project Skara, one goal was to keep backwards compatibility with developers' workflows. For this, a 
>> Skara bot was created which generates webrevs, as closely aligned to the original ksh webrev script as possible.
>>
>> Now I believe all developers are well into the Skara/GitHub way of doing things, and I have not heard someone refer to 
>> webrevs in a long time. So my first question is:
>>
>> * Is it still relevant to continue let the Skara bots generate webrevs?
>>
>> I personally have only used webrevs on a few occasions the last years, and those have all been when the GitHub diff 
>> viewer was inadequate. For instance, the webrev bot uses a more aggressive method of letting git match files that have 
>> been simultaneously moved and edited, and the Frames view align code side-by-side which is sometimes much more helpful 
>> than the line-by-line view in GitHub. So, my second question is:
>>
>> * Should we keep the idea of a bot that generates diff pages, but instead of mimicking the old webrev script, tailor 
>> it to cover up for those use cases where GitHub falls short?
>>
>> I'm not suggesting we should immediately turn of the webrev bot, so if you still like and use it, there is no cause 
>> for panic. I'm just trying to get a sense of how people feel about the future for webrevs.
>>
>> /Magnus
>>


More information about the jdk-dev mailing list