Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Hi, Alexey,

Yes, now we can keep updating the website as before. Here is a contributor
guide: https://github.com/apache/beam/blob/master/website/CONTRIBUTE.md

Thanks for checking :)

Aizhamal


On Tue, May 26, 2020 at 8:39 AM Alexey Romanenko 
wrote:

> Thank you to everybody who worked on this migration.
>
> I just wanted to clarify - does it mean, since it’s finished now, we can
> update a website as before?
>
> On 15 May 2020, at 01:33, Aizhamal Nurmamat kyzy 
> wrote:
>
> Thank you Ahmet, Brian, Robert and everyone else who spent time working on
> this. The pull requests are now merged and the website seems to be working
> as expected [1].
>
> One minor issue that I have noticed is that the code blocks have a grey
> background, which makes it less accessible than before. I created a Jira
> issue for this [2], and will follow up to get it fixed. If you notice any
> other issues, please file Jira issues and let me know.
>
> Hope you are all safe,
> Aizhamal
>
> [1] https://beam.apache.org/
> [2] https://issues.apache.org/jira/browse/BEAM-10001
>
> On Thu, May 14, 2020 at 11:25 AM Pablo Estrada  wrote:
>
>> Here's a zipped-up tree from a staged sample of the website:
>> https://drive.google.com/file/d/1LKL936tBJ79jpjvlL5vC5uYYwTHsWXiJ/view?usp=sharing
>>
>> I'd also suggest tagging the commit, so we can find the fist commit later
>> on for reference. I can push the tag after the PR is merged.
>>
>> On Thu, May 14, 2020 at 10:43 AM Ahmet Altay  wrote:
>>
>>>
>>>
>>> On Thu, May 14, 2020 at 9:16 AM Aizhamal Nurmamat kyzy <
>>> aizha...@apache.org> wrote:
>>>
 Thank you all for reviewing and validating this pull request. I see
 that all tests are passing now, should we merge it?

>>>
>>> +1 to merging now.
>>>
>>> Before the merge, please share a link to an archive copy of the old
>>> website. After the merge, please try out the live website see if it is
>>> working as expected.
>>>
>>>

 On Wed, May 13, 2020, 5:41 PM Ahmet Altay  wrote:

> Thank you! Let's merge it once tests are done.
>
> On Wed, May 13, 2020 at 5:23 PM Robert Bradshaw 
> wrote:
>
>> I took a (non-comprehensive) look at these as well, and didn't see
>> any issues, so am happy to sign off on this. Thanks Nam, Brian, Ahmet, 
>> and
>> everyone else.
>>
>> On Wed, May 13, 2020 at 7:58 AM Nam Bui  wrote:
>>
>>> Hi Ahmet,
>>> "Does this mean the internal links (e.g. contribute/team) will
>>> disappear?"
>>> Yes, I'd like to get rid of them. And to make sure it won't appear
>>> to confuse people, I replaced all of the spots using "contribute/team" 
>>> with
>>> the external one. Currently, we only have 2 "redirect_to" links which 
>>> are
>>> "contribute/team" & "contribute/project/team", so this act won't have 
>>> any
>>> affects.
>>> Also, based on your question, I just added a section in the
>>> documentation (CONTRIBUTE.md), which mentions the replaced/removed 
>>> features
>>> of Jekyll in terms of writing a new blog post or documentation in Hugo.
>>>
>>
> Got it. The main effect will be any one has a bookmark/link to these
> pages, those links will no longer work. It is fine if it is only limited 
> to
> these 2 urls.
>
>
>>
>>>
>>> On Wed, May 13, 2020 at 4:17 AM Ahmet Altay 
>>> wrote:
>>>
 - I reviewed the diff output with Nam's explanations. The change
 looks minimal. Large diffs are primarily coming from index and redirect
 files. codeblocks have differences but the content is seemingly 
 preserved.
 IIUC, the source of truth is snippet files anyway. (It would be good 
 to get
 one more set of eyes on this.)
 - Brian and I reviewed the infrastructure changes. They look
 reasonable.

 I think PR is very close to a mergeable state. Especially if we can
 get an archive copy of the current website, I will be comfortable with 
 the
 merge.

 And, thank you Nam for your work so far.

 On Tue, May 12, 2020 at 4:13 PM Nam Bui 
 wrote:

> Hi,
>
> A new commit covers Robert's script is pushed [1], and also the
> script output is attached in this email.
>
> Based on the diff output of the script, my strategy is looking at
> the sections which contain the large/massive removed texts, to make 
> sure
> that there are no lost content or files. And below are all of the 
> links
> which have large of the removed content.
>
> - Detection:
> These links lost some of the contents. Fixed!
> + documentation/runners/jstorm/index.html
> + documentation/dsls/sql/calcite/lexical-structure/index.html
> + documentation/dsls/sql/zetasql/data-types/index.html
> + 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Alexey Romanenko]

Thank you to everybody who worked on this migration. 

I just wanted to clarify - does it mean, since it’s finished now, we can update 
a website as before?

> On 15 May 2020, at 01:33, Aizhamal Nurmamat kyzy  wrote:
> 
> Thank you Ahmet, Brian, Robert and everyone else who spent time working on 
> this. The pull requests are now merged and the website seems to be working as 
> expected [1].
> 
> One minor issue that I have noticed is that the code blocks have a grey 
> background, which makes it less accessible than before. I created a Jira 
> issue for this [2], and will follow up to get it fixed. If you notice any 
> other issues, please file Jira issues and let me know.
> 
> Hope you are all safe,
> Aizhamal
> 
> [1] https://beam.apache.org/ 
> [2] https://issues.apache.org/jira/browse/BEAM-10001 
> 
> On Thu, May 14, 2020 at 11:25 AM Pablo Estrada  > wrote:
> Here's a zipped-up tree from a staged sample of the website: 
> https://drive.google.com/file/d/1LKL936tBJ79jpjvlL5vC5uYYwTHsWXiJ/view?usp=sharing
>  
> 
> 
> I'd also suggest tagging the commit, so we can find the fist commit later on 
> for reference. I can push the tag after the PR is merged.
> 
> On Thu, May 14, 2020 at 10:43 AM Ahmet Altay  > wrote:
> 
> 
> On Thu, May 14, 2020 at 9:16 AM Aizhamal Nurmamat kyzy  > wrote:
> Thank you all for reviewing and validating this pull request. I see that all 
> tests are passing now, should we merge it?
> 
> +1 to merging now.
> 
> Before the merge, please share a link to an archive copy of the old website. 
> After the merge, please try out the live website see if it is working as 
> expected.
>  
> 
> On Wed, May 13, 2020, 5:41 PM Ahmet Altay  > wrote:
> Thank you! Let's merge it once tests are done.
> 
> On Wed, May 13, 2020 at 5:23 PM Robert Bradshaw  > wrote:
> I took a (non-comprehensive) look at these as well, and didn't see any 
> issues, so am happy to sign off on this. Thanks Nam, Brian, Ahmet, and 
> everyone else. 
> 
> On Wed, May 13, 2020 at 7:58 AM Nam Bui  > wrote:
> Hi Ahmet,
> "Does this mean the internal links (e.g. contribute/team) will disappear?"
> Yes, I'd like to get rid of them. And to make sure it won't appear to confuse 
> people, I replaced all of the spots using "contribute/team" with the external 
> one. Currently, we only have 2 "redirect_to" links which are 
> "contribute/team" & "contribute/project/team", so this act won't have any 
> affects.
> Also, based on your question, I just added a section in the documentation 
> (CONTRIBUTE.md), which mentions the replaced/removed features of Jekyll in 
> terms of writing a new blog post or documentation in Hugo.
> 
> Got it. The main effect will be any one has a bookmark/link to these pages, 
> those links will no longer work. It is fine if it is only limited to these 2 
> urls.
>  
> 
> 
> On Wed, May 13, 2020 at 4:17 AM Ahmet Altay  > wrote:
> - I reviewed the diff output with Nam's explanations. The change looks 
> minimal. Large diffs are primarily coming from index and redirect files. 
> codeblocks have differences but the content is seemingly preserved. IIUC, the 
> source of truth is snippet files anyway. (It would be good to get one more 
> set of eyes on this.)
> - Brian and I reviewed the infrastructure changes. They look reasonable.
> 
> I think PR is very close to a mergeable state. Especially if we can get an 
> archive copy of the current website, I will be comfortable with the merge.
> 
> And, thank you Nam for your work so far.
> 
> On Tue, May 12, 2020 at 4:13 PM Nam Bui  > wrote:
> Hi,
> 
> A new commit covers Robert's script is pushed [1], and also the script output 
> is attached in this email.
> 
> Based on the diff output of the script, my strategy is looking at the 
> sections which contain the large/massive removed texts, to make sure that 
> there are no lost content or files. And below are all of the links which have 
> large of the removed content.
> 
> - Detection:
> These links lost some of the contents. Fixed!
> + documentation/runners/jstorm/index.html
> + documentation/dsls/sql/calcite/lexical-structure/index.html
> + documentation/dsls/sql/zetasql/data-types/index.html
> + documentation/dsls/sql/zetasql/query-syntax/index.html
> 
> - Aliases:
> These links are redirected links. So in Hugo, these HTML files only include 
> redirected URLs. I also took a look at them to ensure the content was there.
> + documentation/dsls/sql/calcite/lexical/index.html
> + old URLs of blog posts
> 
> - Ignore:
> Hugo and Jekyll have different structures of code highlighters rendering in 
> HTML. Ahmed & Pablo agree with me that its fair to 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Thank you Ahmet, Brian, Robert and everyone else who spent time working on
this. The pull requests are now merged and the website seems to be working
as expected [1].

One minor issue that I have noticed is that the code blocks have a grey
background, which makes it less accessible than before. I created a Jira
issue for this [2], and will follow up to get it fixed. If you notice any
other issues, please file Jira issues and let me know.

Hope you are all safe,
Aizhamal

[1] https://beam.apache.org/
[2] https://issues.apache.org/jira/browse/BEAM-10001

On Thu, May 14, 2020 at 11:25 AM Pablo Estrada  wrote:

> Here's a zipped-up tree from a staged sample of the website:
> https://drive.google.com/file/d/1LKL936tBJ79jpjvlL5vC5uYYwTHsWXiJ/view?usp=sharing
>
> I'd also suggest tagging the commit, so we can find the fist commit later
> on for reference. I can push the tag after the PR is merged.
>
> On Thu, May 14, 2020 at 10:43 AM Ahmet Altay  wrote:
>
>>
>>
>> On Thu, May 14, 2020 at 9:16 AM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>>
>>> Thank you all for reviewing and validating this pull request. I see that
>>> all tests are passing now, should we merge it?
>>>
>>
>> +1 to merging now.
>>
>> Before the merge, please share a link to an archive copy of the old
>> website. After the merge, please try out the live website see if it is
>> working as expected.
>>
>>
>>>
>>> On Wed, May 13, 2020, 5:41 PM Ahmet Altay  wrote:
>>>
 Thank you! Let's merge it once tests are done.

 On Wed, May 13, 2020 at 5:23 PM Robert Bradshaw 
 wrote:

> I took a (non-comprehensive) look at these as well, and didn't see any
> issues, so am happy to sign off on this. Thanks Nam, Brian, Ahmet, and
> everyone else.
>
> On Wed, May 13, 2020 at 7:58 AM Nam Bui  wrote:
>
>> Hi Ahmet,
>> "Does this mean the internal links (e.g. contribute/team) will
>> disappear?"
>> Yes, I'd like to get rid of them. And to make sure it won't appear to
>> confuse people, I replaced all of the spots using "contribute/team" with
>> the external one. Currently, we only have 2 "redirect_to" links which are
>> "contribute/team" & "contribute/project/team", so this act won't have any
>> affects.
>> Also, based on your question, I just added a section in the
>> documentation (CONTRIBUTE.md), which mentions the replaced/removed 
>> features
>> of Jekyll in terms of writing a new blog post or documentation in Hugo.
>>
>
 Got it. The main effect will be any one has a bookmark/link to these
 pages, those links will no longer work. It is fine if it is only limited to
 these 2 urls.


>
>>
>> On Wed, May 13, 2020 at 4:17 AM Ahmet Altay  wrote:
>>
>>> - I reviewed the diff output with Nam's explanations. The change
>>> looks minimal. Large diffs are primarily coming from index and redirect
>>> files. codeblocks have differences but the content is seemingly 
>>> preserved.
>>> IIUC, the source of truth is snippet files anyway. (It would be good to 
>>> get
>>> one more set of eyes on this.)
>>> - Brian and I reviewed the infrastructure changes. They look
>>> reasonable.
>>>
>>> I think PR is very close to a mergeable state. Especially if we can
>>> get an archive copy of the current website, I will be comfortable with 
>>> the
>>> merge.
>>>
>>> And, thank you Nam for your work so far.
>>>
>>> On Tue, May 12, 2020 at 4:13 PM Nam Bui  wrote:
>>>
 Hi,

 A new commit covers Robert's script is pushed [1], and also the
 script output is attached in this email.

 Based on the diff output of the script, my strategy is looking at
 the sections which contain the large/massive removed texts, to make 
 sure
 that there are no lost content or files. And below are all of the links
 which have large of the removed content.

 - Detection:
 These links lost some of the contents. Fixed!
 + documentation/runners/jstorm/index.html
 + documentation/dsls/sql/calcite/lexical-structure/index.html
 + documentation/dsls/sql/zetasql/data-types/index.html
 + documentation/dsls/sql/zetasql/query-syntax/index.html

 - Aliases:
 These links are redirected links. So in Hugo, these HTML files only
 include redirected URLs. I also took a look at them to ensure the 
 content
 was there.
 + documentation/dsls/sql/calcite/lexical/index.html
 + old URLs of blog posts

 - Ignore:
 Hugo and Jekyll have different structures of code highlighters
 rendering in HTML. Ahmed & Pablo agree with me that its fair to ignore 
 them
 for now.
 + codeblocks

 - Missing files:
 The script returns some of “missing files” 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Pablo Estrada]

Here's a zipped-up tree from a staged sample of the website:
https://drive.google.com/file/d/1LKL936tBJ79jpjvlL5vC5uYYwTHsWXiJ/view?usp=sharing

I'd also suggest tagging the commit, so we can find the fist commit later
on for reference. I can push the tag after the PR is merged.

On Thu, May 14, 2020 at 10:43 AM Ahmet Altay  wrote:

>
>
> On Thu, May 14, 2020 at 9:16 AM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
>
>> Thank you all for reviewing and validating this pull request. I see that
>> all tests are passing now, should we merge it?
>>
>
> +1 to merging now.
>
> Before the merge, please share a link to an archive copy of the old
> website. After the merge, please try out the live website see if it is
> working as expected.
>
>
>>
>> On Wed, May 13, 2020, 5:41 PM Ahmet Altay  wrote:
>>
>>> Thank you! Let's merge it once tests are done.
>>>
>>> On Wed, May 13, 2020 at 5:23 PM Robert Bradshaw 
>>> wrote:
>>>
 I took a (non-comprehensive) look at these as well, and didn't see any
 issues, so am happy to sign off on this. Thanks Nam, Brian, Ahmet, and
 everyone else.

 On Wed, May 13, 2020 at 7:58 AM Nam Bui  wrote:

> Hi Ahmet,
> "Does this mean the internal links (e.g. contribute/team) will
> disappear?"
> Yes, I'd like to get rid of them. And to make sure it won't appear to
> confuse people, I replaced all of the spots using "contribute/team" with
> the external one. Currently, we only have 2 "redirect_to" links which are
> "contribute/team" & "contribute/project/team", so this act won't have any
> affects.
> Also, based on your question, I just added a section in the
> documentation (CONTRIBUTE.md), which mentions the replaced/removed 
> features
> of Jekyll in terms of writing a new blog post or documentation in Hugo.
>

>>> Got it. The main effect will be any one has a bookmark/link to these
>>> pages, those links will no longer work. It is fine if it is only limited to
>>> these 2 urls.
>>>
>>>

>
> On Wed, May 13, 2020 at 4:17 AM Ahmet Altay  wrote:
>
>> - I reviewed the diff output with Nam's explanations. The change
>> looks minimal. Large diffs are primarily coming from index and redirect
>> files. codeblocks have differences but the content is seemingly 
>> preserved.
>> IIUC, the source of truth is snippet files anyway. (It would be good to 
>> get
>> one more set of eyes on this.)
>> - Brian and I reviewed the infrastructure changes. They look
>> reasonable.
>>
>> I think PR is very close to a mergeable state. Especially if we can
>> get an archive copy of the current website, I will be comfortable with 
>> the
>> merge.
>>
>> And, thank you Nam for your work so far.
>>
>> On Tue, May 12, 2020 at 4:13 PM Nam Bui  wrote:
>>
>>> Hi,
>>>
>>> A new commit covers Robert's script is pushed [1], and also the
>>> script output is attached in this email.
>>>
>>> Based on the diff output of the script, my strategy is looking at
>>> the sections which contain the large/massive removed texts, to make sure
>>> that there are no lost content or files. And below are all of the links
>>> which have large of the removed content.
>>>
>>> - Detection:
>>> These links lost some of the contents. Fixed!
>>> + documentation/runners/jstorm/index.html
>>> + documentation/dsls/sql/calcite/lexical-structure/index.html
>>> + documentation/dsls/sql/zetasql/data-types/index.html
>>> + documentation/dsls/sql/zetasql/query-syntax/index.html
>>>
>>> - Aliases:
>>> These links are redirected links. So in Hugo, these HTML files only
>>> include redirected URLs. I also took a look at them to ensure the 
>>> content
>>> was there.
>>> + documentation/dsls/sql/calcite/lexical/index.html
>>> + old URLs of blog posts
>>>
>>> - Ignore:
>>> Hugo and Jekyll have different structures of code highlighters
>>> rendering in HTML. Ahmed & Pablo agree with me that its fair to ignore 
>>> them
>>> for now.
>>> + codeblocks
>>>
>>> - Missing files:
>>> The script returns some of “missing files” status
>>> + coming-soon.html (this file was used nowhere in Jekyll, so I
>>> didn’t migrate to Hugo)
>>> + documentation/dsls/sql/statements/select/index.html (aliases)
>>> + blog/2019/04/25/beam-2.12.0.html (fixed!)
>>> + blog/2020/05/08/beam-summit-digital-2020.html (new blog post,
>>> added!)
>>> + v2/index.html (this file was used nowhere in Jekyll, so I didn’t
>>> migrate to Hugo)
>>> + contribute/team/index.html (mentioned in “redirect_to” below)
>>> + contribute/project/team/index.html (mentioned in “redirect_to”
>>> below)
>>>
>>> - “redirect_to”:
>>> In Jekyll, there is a feature called “redirect_to”. For instance,
>>> you click on an internal link “contribute/team/” 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Ahmet Altay]

On Thu, May 14, 2020 at 9:16 AM Aizhamal Nurmamat kyzy 
wrote:

> Thank you all for reviewing and validating this pull request. I see that
> all tests are passing now, should we merge it?
>

+1 to merging now.

Before the merge, please share a link to an archive copy of the old
website. After the merge, please try out the live website see if it is
working as expected.


>
> On Wed, May 13, 2020, 5:41 PM Ahmet Altay  wrote:
>
>> Thank you! Let's merge it once tests are done.
>>
>> On Wed, May 13, 2020 at 5:23 PM Robert Bradshaw 
>> wrote:
>>
>>> I took a (non-comprehensive) look at these as well, and didn't see any
>>> issues, so am happy to sign off on this. Thanks Nam, Brian, Ahmet, and
>>> everyone else.
>>>
>>> On Wed, May 13, 2020 at 7:58 AM Nam Bui  wrote:
>>>
 Hi Ahmet,
 "Does this mean the internal links (e.g. contribute/team) will
 disappear?"
 Yes, I'd like to get rid of them. And to make sure it won't appear to
 confuse people, I replaced all of the spots using "contribute/team" with
 the external one. Currently, we only have 2 "redirect_to" links which are
 "contribute/team" & "contribute/project/team", so this act won't have any
 affects.
 Also, based on your question, I just added a section in the
 documentation (CONTRIBUTE.md), which mentions the replaced/removed features
 of Jekyll in terms of writing a new blog post or documentation in Hugo.

>>>
>> Got it. The main effect will be any one has a bookmark/link to these
>> pages, those links will no longer work. It is fine if it is only limited to
>> these 2 urls.
>>
>>
>>>

 On Wed, May 13, 2020 at 4:17 AM Ahmet Altay  wrote:

> - I reviewed the diff output with Nam's explanations. The change looks
> minimal. Large diffs are primarily coming from index and redirect files.
> codeblocks have differences but the content is seemingly preserved. IIUC,
> the source of truth is snippet files anyway. (It would be good to get one
> more set of eyes on this.)
> - Brian and I reviewed the infrastructure changes. They look
> reasonable.
>
> I think PR is very close to a mergeable state. Especially if we can
> get an archive copy of the current website, I will be comfortable with the
> merge.
>
> And, thank you Nam for your work so far.
>
> On Tue, May 12, 2020 at 4:13 PM Nam Bui  wrote:
>
>> Hi,
>>
>> A new commit covers Robert's script is pushed [1], and also the
>> script output is attached in this email.
>>
>> Based on the diff output of the script, my strategy is looking at the
>> sections which contain the large/massive removed texts, to make sure that
>> there are no lost content or files. And below are all of the links which
>> have large of the removed content.
>>
>> - Detection:
>> These links lost some of the contents. Fixed!
>> + documentation/runners/jstorm/index.html
>> + documentation/dsls/sql/calcite/lexical-structure/index.html
>> + documentation/dsls/sql/zetasql/data-types/index.html
>> + documentation/dsls/sql/zetasql/query-syntax/index.html
>>
>> - Aliases:
>> These links are redirected links. So in Hugo, these HTML files only
>> include redirected URLs. I also took a look at them to ensure the content
>> was there.
>> + documentation/dsls/sql/calcite/lexical/index.html
>> + old URLs of blog posts
>>
>> - Ignore:
>> Hugo and Jekyll have different structures of code highlighters
>> rendering in HTML. Ahmed & Pablo agree with me that its fair to ignore 
>> them
>> for now.
>> + codeblocks
>>
>> - Missing files:
>> The script returns some of “missing files” status
>> + coming-soon.html (this file was used nowhere in Jekyll, so I didn’t
>> migrate to Hugo)
>> + documentation/dsls/sql/statements/select/index.html (aliases)
>> + blog/2019/04/25/beam-2.12.0.html (fixed!)
>> + blog/2020/05/08/beam-summit-digital-2020.html (new blog post,
>> added!)
>> + v2/index.html (this file was used nowhere in Jekyll, so I didn’t
>> migrate to Hugo)
>> + contribute/team/index.html (mentioned in “redirect_to” below)
>> + contribute/project/team/index.html (mentioned in “redirect_to”
>> below)
>>
>> - “redirect_to”:
>> In Jekyll, there is a feature called “redirect_to”. For instance, you
>> click on an internal link “contribute/team/” to reach the markdown
>> “team.md”, then from the markdown file, it redirects you to the external
>> URL “https://example.com”.
>> However, there is no such feature in Hugo. My solution is to directly
>> replace “contribute/team/” with “https://example.com”.
>>
>
> Does this mean the internal links (e.g. contribute/team) will
> disappear?
>
>
>>
>> [1] https://github.com/apache/beam/pull/11554
>>
>> On Mon, May 11, 2020 at 7:34 PM Nam Bui  wrote:
>>
>>> 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Thank you all for reviewing and validating this pull request. I see that
all tests are passing now, should we merge it?

On Wed, May 13, 2020, 5:41 PM Ahmet Altay  wrote:

> Thank you! Let's merge it once tests are done.
>
> On Wed, May 13, 2020 at 5:23 PM Robert Bradshaw 
> wrote:
>
>> I took a (non-comprehensive) look at these as well, and didn't see any
>> issues, so am happy to sign off on this. Thanks Nam, Brian, Ahmet, and
>> everyone else.
>>
>> On Wed, May 13, 2020 at 7:58 AM Nam Bui  wrote:
>>
>>> Hi Ahmet,
>>> "Does this mean the internal links (e.g. contribute/team) will
>>> disappear?"
>>> Yes, I'd like to get rid of them. And to make sure it won't appear to
>>> confuse people, I replaced all of the spots using "contribute/team" with
>>> the external one. Currently, we only have 2 "redirect_to" links which are
>>> "contribute/team" & "contribute/project/team", so this act won't have any
>>> affects.
>>> Also, based on your question, I just added a section in the
>>> documentation (CONTRIBUTE.md), which mentions the replaced/removed features
>>> of Jekyll in terms of writing a new blog post or documentation in Hugo.
>>>
>>
> Got it. The main effect will be any one has a bookmark/link to these
> pages, those links will no longer work. It is fine if it is only limited to
> these 2 urls.
>
>
>>
>>>
>>> On Wed, May 13, 2020 at 4:17 AM Ahmet Altay  wrote:
>>>
 - I reviewed the diff output with Nam's explanations. The change looks
 minimal. Large diffs are primarily coming from index and redirect files.
 codeblocks have differences but the content is seemingly preserved. IIUC,
 the source of truth is snippet files anyway. (It would be good to get one
 more set of eyes on this.)
 - Brian and I reviewed the infrastructure changes. They look reasonable.

 I think PR is very close to a mergeable state. Especially if we can get
 an archive copy of the current website, I will be comfortable with the
 merge.

 And, thank you Nam for your work so far.

 On Tue, May 12, 2020 at 4:13 PM Nam Bui  wrote:

> Hi,
>
> A new commit covers Robert's script is pushed [1], and also the script
> output is attached in this email.
>
> Based on the diff output of the script, my strategy is looking at the
> sections which contain the large/massive removed texts, to make sure that
> there are no lost content or files. And below are all of the links which
> have large of the removed content.
>
> - Detection:
> These links lost some of the contents. Fixed!
> + documentation/runners/jstorm/index.html
> + documentation/dsls/sql/calcite/lexical-structure/index.html
> + documentation/dsls/sql/zetasql/data-types/index.html
> + documentation/dsls/sql/zetasql/query-syntax/index.html
>
> - Aliases:
> These links are redirected links. So in Hugo, these HTML files only
> include redirected URLs. I also took a look at them to ensure the content
> was there.
> + documentation/dsls/sql/calcite/lexical/index.html
> + old URLs of blog posts
>
> - Ignore:
> Hugo and Jekyll have different structures of code highlighters
> rendering in HTML. Ahmed & Pablo agree with me that its fair to ignore 
> them
> for now.
> + codeblocks
>
> - Missing files:
> The script returns some of “missing files” status
> + coming-soon.html (this file was used nowhere in Jekyll, so I didn’t
> migrate to Hugo)
> + documentation/dsls/sql/statements/select/index.html (aliases)
> + blog/2019/04/25/beam-2.12.0.html (fixed!)
> + blog/2020/05/08/beam-summit-digital-2020.html (new blog post, added!)
> + v2/index.html (this file was used nowhere in Jekyll, so I didn’t
> migrate to Hugo)
> + contribute/team/index.html (mentioned in “redirect_to” below)
> + contribute/project/team/index.html (mentioned in “redirect_to” below)
>
> - “redirect_to”:
> In Jekyll, there is a feature called “redirect_to”. For instance, you
> click on an internal link “contribute/team/” to reach the markdown
> “team.md”, then from the markdown file, it redirects you to the external
> URL “https://example.com”.
> However, there is no such feature in Hugo. My solution is to directly
> replace “contribute/team/” with “https://example.com”.
>

 Does this mean the internal links (e.g. contribute/team) will disappear?


>
> [1] https://github.com/apache/beam/pull/11554
>
> On Mon, May 11, 2020 at 7:34 PM Nam Bui  wrote:
>
>> Updates for today:
>> - Thanks Brian & Ahmet for your reviews. I left my comments for some
>> of the questions and also adapted new changes to the reviews [1].
>> - I see that the new blog post was merged yesterday, so I added it to
>> the PR as well.
>>
>> I briefly tried the script from Robert with the input of build files
>> from old and new websites. It 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Ahmet Altay]

Thank you! Let's merge it once tests are done.

On Wed, May 13, 2020 at 5:23 PM Robert Bradshaw  wrote:

> I took a (non-comprehensive) look at these as well, and didn't see any
> issues, so am happy to sign off on this. Thanks Nam, Brian, Ahmet, and
> everyone else.
>
> On Wed, May 13, 2020 at 7:58 AM Nam Bui  wrote:
>
>> Hi Ahmet,
>> "Does this mean the internal links (e.g. contribute/team) will disappear?"
>> Yes, I'd like to get rid of them. And to make sure it won't appear to
>> confuse people, I replaced all of the spots using "contribute/team" with
>> the external one. Currently, we only have 2 "redirect_to" links which are
>> "contribute/team" & "contribute/project/team", so this act won't have any
>> affects.
>> Also, based on your question, I just added a section in the documentation
>> (CONTRIBUTE.md), which mentions the replaced/removed features of Jekyll in
>> terms of writing a new blog post or documentation in Hugo.
>>
>
Got it. The main effect will be any one has a bookmark/link to these pages,
those links will no longer work. It is fine if it is only limited to these
2 urls.


>
>>
>> On Wed, May 13, 2020 at 4:17 AM Ahmet Altay  wrote:
>>
>>> - I reviewed the diff output with Nam's explanations. The change looks
>>> minimal. Large diffs are primarily coming from index and redirect files.
>>> codeblocks have differences but the content is seemingly preserved. IIUC,
>>> the source of truth is snippet files anyway. (It would be good to get one
>>> more set of eyes on this.)
>>> - Brian and I reviewed the infrastructure changes. They look reasonable.
>>>
>>> I think PR is very close to a mergeable state. Especially if we can get
>>> an archive copy of the current website, I will be comfortable with the
>>> merge.
>>>
>>> And, thank you Nam for your work so far.
>>>
>>> On Tue, May 12, 2020 at 4:13 PM Nam Bui  wrote:
>>>
 Hi,

 A new commit covers Robert's script is pushed [1], and also the script
 output is attached in this email.

 Based on the diff output of the script, my strategy is looking at the
 sections which contain the large/massive removed texts, to make sure that
 there are no lost content or files. And below are all of the links which
 have large of the removed content.

 - Detection:
 These links lost some of the contents. Fixed!
 + documentation/runners/jstorm/index.html
 + documentation/dsls/sql/calcite/lexical-structure/index.html
 + documentation/dsls/sql/zetasql/data-types/index.html
 + documentation/dsls/sql/zetasql/query-syntax/index.html

 - Aliases:
 These links are redirected links. So in Hugo, these HTML files only
 include redirected URLs. I also took a look at them to ensure the content
 was there.
 + documentation/dsls/sql/calcite/lexical/index.html
 + old URLs of blog posts

 - Ignore:
 Hugo and Jekyll have different structures of code highlighters
 rendering in HTML. Ahmed & Pablo agree with me that its fair to ignore them
 for now.
 + codeblocks

 - Missing files:
 The script returns some of “missing files” status
 + coming-soon.html (this file was used nowhere in Jekyll, so I didn’t
 migrate to Hugo)
 + documentation/dsls/sql/statements/select/index.html (aliases)
 + blog/2019/04/25/beam-2.12.0.html (fixed!)
 + blog/2020/05/08/beam-summit-digital-2020.html (new blog post, added!)
 + v2/index.html (this file was used nowhere in Jekyll, so I didn’t
 migrate to Hugo)
 + contribute/team/index.html (mentioned in “redirect_to” below)
 + contribute/project/team/index.html (mentioned in “redirect_to” below)

 - “redirect_to”:
 In Jekyll, there is a feature called “redirect_to”. For instance, you
 click on an internal link “contribute/team/” to reach the markdown
 “team.md”, then from the markdown file, it redirects you to the external
 URL “https://example.com”.
 However, there is no such feature in Hugo. My solution is to directly
 replace “contribute/team/” with “https://example.com”.

>>>
>>> Does this mean the internal links (e.g. contribute/team) will disappear?
>>>
>>>

 [1] https://github.com/apache/beam/pull/11554

 On Mon, May 11, 2020 at 7:34 PM Nam Bui  wrote:

> Updates for today:
> - Thanks Brian & Ahmet for your reviews. I left my comments for some
> of the questions and also adapted new changes to the reviews [1].
> - I see that the new blog post was merged yesterday, so I added it to
> the PR as well.
>
> I briefly tried the script from Robert with the input of build files
> from old and new websites. It seemed to work well in terms of detecting
> missing files (or probably wrong links leading to missing files). I will
> push another commit to fix all that up, hope can be tomorrow.
>
> [1] https://github.com/apache/beam/pull/11554#issuecomment-626792031
>
> Best regards,
> Nam

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Robert Bradshaw]

I took a (non-comprehensive) look at these as well, and didn't see any
issues, so am happy to sign off on this. Thanks Nam, Brian, Ahmet, and
everyone else.

On Wed, May 13, 2020 at 7:58 AM Nam Bui  wrote:

> Hi Ahmet,
> "Does this mean the internal links (e.g. contribute/team) will disappear?"
> Yes, I'd like to get rid of them. And to make sure it won't appear to
> confuse people, I replaced all of the spots using "contribute/team" with
> the external one. Currently, we only have 2 "redirect_to" links which are
> "contribute/team" & "contribute/project/team", so this act won't have any
> affects.
> Also, based on your question, I just added a section in the documentation
> (CONTRIBUTE.md), which mentions the replaced/removed features of Jekyll in
> terms of writing a new blog post or documentation in Hugo.
>
>
> On Wed, May 13, 2020 at 4:17 AM Ahmet Altay  wrote:
>
>> - I reviewed the diff output with Nam's explanations. The change looks
>> minimal. Large diffs are primarily coming from index and redirect files.
>> codeblocks have differences but the content is seemingly preserved. IIUC,
>> the source of truth is snippet files anyway. (It would be good to get one
>> more set of eyes on this.)
>> - Brian and I reviewed the infrastructure changes. They look reasonable.
>>
>> I think PR is very close to a mergeable state. Especially if we can get
>> an archive copy of the current website, I will be comfortable with the
>> merge.
>>
>> And, thank you Nam for your work so far.
>>
>> On Tue, May 12, 2020 at 4:13 PM Nam Bui  wrote:
>>
>>> Hi,
>>>
>>> A new commit covers Robert's script is pushed [1], and also the script
>>> output is attached in this email.
>>>
>>> Based on the diff output of the script, my strategy is looking at the
>>> sections which contain the large/massive removed texts, to make sure that
>>> there are no lost content or files. And below are all of the links which
>>> have large of the removed content.
>>>
>>> - Detection:
>>> These links lost some of the contents. Fixed!
>>> + documentation/runners/jstorm/index.html
>>> + documentation/dsls/sql/calcite/lexical-structure/index.html
>>> + documentation/dsls/sql/zetasql/data-types/index.html
>>> + documentation/dsls/sql/zetasql/query-syntax/index.html
>>>
>>> - Aliases:
>>> These links are redirected links. So in Hugo, these HTML files only
>>> include redirected URLs. I also took a look at them to ensure the content
>>> was there.
>>> + documentation/dsls/sql/calcite/lexical/index.html
>>> + old URLs of blog posts
>>>
>>> - Ignore:
>>> Hugo and Jekyll have different structures of code highlighters rendering
>>> in HTML. Ahmed & Pablo agree with me that its fair to ignore them for now.
>>> + codeblocks
>>>
>>> - Missing files:
>>> The script returns some of “missing files” status
>>> + coming-soon.html (this file was used nowhere in Jekyll, so I didn’t
>>> migrate to Hugo)
>>> + documentation/dsls/sql/statements/select/index.html (aliases)
>>> + blog/2019/04/25/beam-2.12.0.html (fixed!)
>>> + blog/2020/05/08/beam-summit-digital-2020.html (new blog post, added!)
>>> + v2/index.html (this file was used nowhere in Jekyll, so I didn’t
>>> migrate to Hugo)
>>> + contribute/team/index.html (mentioned in “redirect_to” below)
>>> + contribute/project/team/index.html (mentioned in “redirect_to” below)
>>>
>>> - “redirect_to”:
>>> In Jekyll, there is a feature called “redirect_to”. For instance, you
>>> click on an internal link “contribute/team/” to reach the markdown
>>> “team.md”, then from the markdown file, it redirects you to the external
>>> URL “https://example.com”.
>>> However, there is no such feature in Hugo. My solution is to directly
>>> replace “contribute/team/” with “https://example.com”.
>>>
>>
>> Does this mean the internal links (e.g. contribute/team) will disappear?
>>
>>
>>>
>>> [1] https://github.com/apache/beam/pull/11554
>>>
>>> On Mon, May 11, 2020 at 7:34 PM Nam Bui  wrote:
>>>
 Updates for today:
 - Thanks Brian & Ahmet for your reviews. I left my comments for some of
 the questions and also adapted new changes to the reviews [1].
 - I see that the new blog post was merged yesterday, so I added it to
 the PR as well.

 I briefly tried the script from Robert with the input of build files
 from old and new websites. It seemed to work well in terms of detecting
 missing files (or probably wrong links leading to missing files). I will
 push another commit to fix all that up, hope can be tomorrow.

 [1] https://github.com/apache/beam/pull/11554#issuecomment-626792031

 Best regards,
 Nam


 On Mon, May 11, 2020 at 9:01 AM Nam Bui  wrote:

> Hi,
>
> @Ahmet: Yeah, it's all clear to me. :)
> @Robert: Thanks for your ideas and also the script. It really helps me
> to serve my works.
>
> Best regard!
>
> On Sat, May 9, 2020 at 2:10 AM Ahmet Altay  wrote:
>
>> This sounds reasonable to me. Thank you. Nam, does it 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Nam Bui]

Hi Ahmet,
"Does this mean the internal links (e.g. contribute/team) will disappear?"
Yes, I'd like to get rid of them. And to make sure it won't appear to
confuse people, I replaced all of the spots using "contribute/team" with
the external one. Currently, we only have 2 "redirect_to" links which are
"contribute/team" & "contribute/project/team", so this act won't have any
affects.
Also, based on your question, I just added a section in the documentation
(CONTRIBUTE.md), which mentions the replaced/removed features of Jekyll in
terms of writing a new blog post or documentation in Hugo.


On Wed, May 13, 2020 at 4:17 AM Ahmet Altay  wrote:

> - I reviewed the diff output with Nam's explanations. The change looks
> minimal. Large diffs are primarily coming from index and redirect files.
> codeblocks have differences but the content is seemingly preserved. IIUC,
> the source of truth is snippet files anyway. (It would be good to get one
> more set of eyes on this.)
> - Brian and I reviewed the infrastructure changes. They look reasonable.
>
> I think PR is very close to a mergeable state. Especially if we can get an
> archive copy of the current website, I will be comfortable with the merge.
>
> And, thank you Nam for your work so far.
>
> On Tue, May 12, 2020 at 4:13 PM Nam Bui  wrote:
>
>> Hi,
>>
>> A new commit covers Robert's script is pushed [1], and also the script
>> output is attached in this email.
>>
>> Based on the diff output of the script, my strategy is looking at the
>> sections which contain the large/massive removed texts, to make sure that
>> there are no lost content or files. And below are all of the links which
>> have large of the removed content.
>>
>> - Detection:
>> These links lost some of the contents. Fixed!
>> + documentation/runners/jstorm/index.html
>> + documentation/dsls/sql/calcite/lexical-structure/index.html
>> + documentation/dsls/sql/zetasql/data-types/index.html
>> + documentation/dsls/sql/zetasql/query-syntax/index.html
>>
>> - Aliases:
>> These links are redirected links. So in Hugo, these HTML files only
>> include redirected URLs. I also took a look at them to ensure the content
>> was there.
>> + documentation/dsls/sql/calcite/lexical/index.html
>> + old URLs of blog posts
>>
>> - Ignore:
>> Hugo and Jekyll have different structures of code highlighters rendering
>> in HTML. Ahmed & Pablo agree with me that its fair to ignore them for now.
>> + codeblocks
>>
>> - Missing files:
>> The script returns some of “missing files” status
>> + coming-soon.html (this file was used nowhere in Jekyll, so I didn’t
>> migrate to Hugo)
>> + documentation/dsls/sql/statements/select/index.html (aliases)
>> + blog/2019/04/25/beam-2.12.0.html (fixed!)
>> + blog/2020/05/08/beam-summit-digital-2020.html (new blog post, added!)
>> + v2/index.html (this file was used nowhere in Jekyll, so I didn’t
>> migrate to Hugo)
>> + contribute/team/index.html (mentioned in “redirect_to” below)
>> + contribute/project/team/index.html (mentioned in “redirect_to” below)
>>
>> - “redirect_to”:
>> In Jekyll, there is a feature called “redirect_to”. For instance, you
>> click on an internal link “contribute/team/” to reach the markdown
>> “team.md”, then from the markdown file, it redirects you to the external
>> URL “https://example.com”.
>> However, there is no such feature in Hugo. My solution is to directly
>> replace “contribute/team/” with “https://example.com”.
>>
>
> Does this mean the internal links (e.g. contribute/team) will disappear?
>
>
>>
>> [1] https://github.com/apache/beam/pull/11554
>>
>> On Mon, May 11, 2020 at 7:34 PM Nam Bui  wrote:
>>
>>> Updates for today:
>>> - Thanks Brian & Ahmet for your reviews. I left my comments for some of
>>> the questions and also adapted new changes to the reviews [1].
>>> - I see that the new blog post was merged yesterday, so I added it to
>>> the PR as well.
>>>
>>> I briefly tried the script from Robert with the input of build files
>>> from old and new websites. It seemed to work well in terms of detecting
>>> missing files (or probably wrong links leading to missing files). I will
>>> push another commit to fix all that up, hope can be tomorrow.
>>>
>>> [1] https://github.com/apache/beam/pull/11554#issuecomment-626792031
>>>
>>> Best regards,
>>> Nam
>>>
>>>
>>> On Mon, May 11, 2020 at 9:01 AM Nam Bui  wrote:
>>>
 Hi,

 @Ahmet: Yeah, it's all clear to me. :)
 @Robert: Thanks for your ideas and also the script. It really helps me
 to serve my works.

 Best regard!

 On Sat, May 9, 2020 at 2:10 AM Ahmet Altay  wrote:

> This sounds reasonable to me. Thank you. Nam, does it make sense to
> you?
>
> On Fri, May 8, 2020 at 11:53 AM Robert Bradshaw 
> wrote:
>
>> I'd really like to not see this work go to waste, both the original
>> revision, the further efforts Nam has done in making it more manageable 
>> to
>> review, and the work put into reviewing this so far, so we can 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Ahmet Altay]

- I reviewed the diff output with Nam's explanations. The change looks
minimal. Large diffs are primarily coming from index and redirect files.
codeblocks have differences but the content is seemingly preserved. IIUC,
the source of truth is snippet files anyway. (It would be good to get one
more set of eyes on this.)
- Brian and I reviewed the infrastructure changes. They look reasonable.

I think PR is very close to a mergeable state. Especially if we can get an
archive copy of the current website, I will be comfortable with the merge.

And, thank you Nam for your work so far.

On Tue, May 12, 2020 at 4:13 PM Nam Bui  wrote:

> Hi,
>
> A new commit covers Robert's script is pushed [1], and also the script
> output is attached in this email.
>
> Based on the diff output of the script, my strategy is looking at the
> sections which contain the large/massive removed texts, to make sure that
> there are no lost content or files. And below are all of the links which
> have large of the removed content.
>
> - Detection:
> These links lost some of the contents. Fixed!
> + documentation/runners/jstorm/index.html
> + documentation/dsls/sql/calcite/lexical-structure/index.html
> + documentation/dsls/sql/zetasql/data-types/index.html
> + documentation/dsls/sql/zetasql/query-syntax/index.html
>
> - Aliases:
> These links are redirected links. So in Hugo, these HTML files only
> include redirected URLs. I also took a look at them to ensure the content
> was there.
> + documentation/dsls/sql/calcite/lexical/index.html
> + old URLs of blog posts
>
> - Ignore:
> Hugo and Jekyll have different structures of code highlighters rendering
> in HTML. Ahmed & Pablo agree with me that its fair to ignore them for now.
> + codeblocks
>
> - Missing files:
> The script returns some of “missing files” status
> + coming-soon.html (this file was used nowhere in Jekyll, so I didn’t
> migrate to Hugo)
> + documentation/dsls/sql/statements/select/index.html (aliases)
> + blog/2019/04/25/beam-2.12.0.html (fixed!)
> + blog/2020/05/08/beam-summit-digital-2020.html (new blog post, added!)
> + v2/index.html (this file was used nowhere in Jekyll, so I didn’t migrate
> to Hugo)
> + contribute/team/index.html (mentioned in “redirect_to” below)
> + contribute/project/team/index.html (mentioned in “redirect_to” below)
>
> - “redirect_to”:
> In Jekyll, there is a feature called “redirect_to”. For instance, you
> click on an internal link “contribute/team/” to reach the markdown
> “team.md”, then from the markdown file, it redirects you to the external
> URL “https://example.com”.
> However, there is no such feature in Hugo. My solution is to directly
> replace “contribute/team/” with “https://example.com”.
>

Does this mean the internal links (e.g. contribute/team) will disappear?


>
> [1] https://github.com/apache/beam/pull/11554
>
> On Mon, May 11, 2020 at 7:34 PM Nam Bui  wrote:
>
>> Updates for today:
>> - Thanks Brian & Ahmet for your reviews. I left my comments for some of
>> the questions and also adapted new changes to the reviews [1].
>> - I see that the new blog post was merged yesterday, so I added it to the
>> PR as well.
>>
>> I briefly tried the script from Robert with the input of build files from
>> old and new websites. It seemed to work well in terms of detecting missing
>> files (or probably wrong links leading to missing files). I will push
>> another commit to fix all that up, hope can be tomorrow.
>>
>> [1] https://github.com/apache/beam/pull/11554#issuecomment-626792031
>>
>> Best regards,
>> Nam
>>
>>
>> On Mon, May 11, 2020 at 9:01 AM Nam Bui  wrote:
>>
>>> Hi,
>>>
>>> @Ahmet: Yeah, it's all clear to me. :)
>>> @Robert: Thanks for your ideas and also the script. It really helps me
>>> to serve my works.
>>>
>>> Best regard!
>>>
>>> On Sat, May 9, 2020 at 2:10 AM Ahmet Altay  wrote:
>>>
 This sounds reasonable to me. Thank you. Nam, does it make sense to you?

 On Fri, May 8, 2020 at 11:53 AM Robert Bradshaw 
 wrote:

> I'd really like to not see this work go to waste, both the original
> revision, the further efforts Nam has done in making it more manageable to
> review, and the work put into reviewing this so far, so we can get the
> benefits of being on Hugo. How about this for a concrete proposal:
>
> (1) We get "standard" approval from one or more committers for the
> infrastructure changes, just as with any other PR. Brian has
> already started this, but if others could step up as well that'd be great.
>
> (2) Reviewers (and authors) typically count on (or request) sufficient
> automated test coverage to augment the fact that their eyeballs are
> fallible, which is something that is missing here (and given the size of
> the change not easily compensated for by a more detailed manual review).
> How about we use the script above (or similar) as an automated test to
> validate the website's contents haven't (materially) changed. I feel we've

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Nam Bui]

Updates for today:
- Thanks Brian & Ahmet for your reviews. I left my comments for some of the
questions and also adapted new changes to the reviews [1].
- I see that the new blog post was merged yesterday, so I added it to the
PR as well.

I briefly tried the script from Robert with the input of build files from
old and new websites. It seemed to work well in terms of detecting missing
files (or probably wrong links leading to missing files). I will push
another commit to fix all that up, hope can be tomorrow.

[1] https://github.com/apache/beam/pull/11554#issuecomment-626792031

Best regards,
Nam


On Mon, May 11, 2020 at 9:01 AM Nam Bui  wrote:

> Hi,
>
> @Ahmet: Yeah, it's all clear to me. :)
> @Robert: Thanks for your ideas and also the script. It really helps me to
> serve my works.
>
> Best regard!
>
> On Sat, May 9, 2020 at 2:10 AM Ahmet Altay  wrote:
>
>> This sounds reasonable to me. Thank you. Nam, does it make sense to you?
>>
>> On Fri, May 8, 2020 at 11:53 AM Robert Bradshaw 
>> wrote:
>>
>>> I'd really like to not see this work go to waste, both the original
>>> revision, the further efforts Nam has done in making it more manageable to
>>> review, and the work put into reviewing this so far, so we can get the
>>> benefits of being on Hugo. How about this for a concrete proposal:
>>>
>>> (1) We get "standard" approval from one or more committers for the
>>> infrastructure changes, just as with any other PR. Brian has
>>> already started this, but if others could step up as well that'd be great.
>>>
>>> (2) Reviewers (and authors) typically count on (or request) sufficient
>>> automated test coverage to augment the fact that their eyeballs are
>>> fallible, which is something that is missing here (and given the size of
>>> the change not easily compensated for by a more detailed manual review).
>>> How about we use the script above (or similar) as an automated test to
>>> validate the website's contents haven't (materially) changed. I feel we've
>>> validated enough that the style looks good via spot checking (which is
>>> something that should work on all pages if it works on one). The diff
>>> between the current site and the newly generated site should be empty (it
>>> might already be [1]), or at least we should get a stamp of approval on the
>>> plain-text diff (which should be small), before merging.
>>>
>>> (3) To make things easier, everyone holds off on making any changes to
>>> the old site until a fixed future date (say, next Wednesday). Hopefully we
>>> can get it merged by then. If not, a condition for merging would be a
>>> commitment incorporating new changes after this date.
>>>
>>> Does this sound reasonable?
>>>
>>> - Robert
>>>
>>>
>>>
>>> [1] I'd be curious as to how small the diff already is, but my script
>>> relies on local directories with the generated HTML, which I don't have
>>> handy at the moment.
>>>
>>>
>>>
>>> On Fri, May 8, 2020 at 10:45 AM Robert Bradshaw 
>>> wrote:
>>>
 Here's a script that we could run on the old and new sites that should
 quickly catch any major issues but not get caught up in formatting minutia.



 On Fri, May 8, 2020 at 10:23 AM Robert Bradshaw 
 wrote:

> On Fri, May 8, 2020 at 9:58 AM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
>
>> I understand the difficulty, and this certainly comes with lessons
>> learned for future similar projects.
>>
>> To your questions Robert:
>> (1 and 2) I will commit to review the text in the resulting pages. I
>> will try and use some automation to extract visible text from each page 
>> and
>> diff it with the current state of the website. I can do this starting 
>> next
>> week. From some quick research, there seem to be tools that help with 
>> this
>> analysis (
>> https://stackoverflow.com/questions/3286955/compare-two-websites-and-see-if-they-are-equal
>> )
>>
>
> At first glance it looks like these tools would give diffs that are
> *larger* than the 47K one we're struggling to review here.
>
>
>> By remaining in this state, we hold others up from making changes, or
>> we increase the amount of work needed after merging to port over changes
>> that may be missed. If we move forward, new changes can be done on top of
>> the new website.
>>
>
> I agree we don't want to hold others up from making changes. However,
> the amount of work to port changes over seems small in comparison to
> everything else that is being discussed here. (It also provides good
> incentives to reach the bar quickly and has the advantage of falling on 
> the
> right people.) (3) will still take some time.
>
> If we go this route, we're lowering the bar for doc changes, but not
> removing it.
>
>
>> (3) This makes sense. Brian, would you be able to spend some time to
>> look at the automation changes (build files and 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Nam Bui]

Hi,

@Ahmet: Yeah, it's all clear to me. :)
@Robert: Thanks for your ideas and also the script. It really helps me to
serve my works.

Best regard!

On Sat, May 9, 2020 at 2:10 AM Ahmet Altay  wrote:

> This sounds reasonable to me. Thank you. Nam, does it make sense to you?
>
> On Fri, May 8, 2020 at 11:53 AM Robert Bradshaw 
> wrote:
>
>> I'd really like to not see this work go to waste, both the original
>> revision, the further efforts Nam has done in making it more manageable to
>> review, and the work put into reviewing this so far, so we can get the
>> benefits of being on Hugo. How about this for a concrete proposal:
>>
>> (1) We get "standard" approval from one or more committers for the
>> infrastructure changes, just as with any other PR. Brian has
>> already started this, but if others could step up as well that'd be great.
>>
>> (2) Reviewers (and authors) typically count on (or request) sufficient
>> automated test coverage to augment the fact that their eyeballs are
>> fallible, which is something that is missing here (and given the size of
>> the change not easily compensated for by a more detailed manual review).
>> How about we use the script above (or similar) as an automated test to
>> validate the website's contents haven't (materially) changed. I feel we've
>> validated enough that the style looks good via spot checking (which is
>> something that should work on all pages if it works on one). The diff
>> between the current site and the newly generated site should be empty (it
>> might already be [1]), or at least we should get a stamp of approval on the
>> plain-text diff (which should be small), before merging.
>>
>> (3) To make things easier, everyone holds off on making any changes to
>> the old site until a fixed future date (say, next Wednesday). Hopefully we
>> can get it merged by then. If not, a condition for merging would be a
>> commitment incorporating new changes after this date.
>>
>> Does this sound reasonable?
>>
>> - Robert
>>
>>
>>
>> [1] I'd be curious as to how small the diff already is, but my script
>> relies on local directories with the generated HTML, which I don't have
>> handy at the moment.
>>
>>
>>
>> On Fri, May 8, 2020 at 10:45 AM Robert Bradshaw 
>> wrote:
>>
>>> Here's a script that we could run on the old and new sites that should
>>> quickly catch any major issues but not get caught up in formatting minutia.
>>>
>>>
>>>
>>> On Fri, May 8, 2020 at 10:23 AM Robert Bradshaw 
>>> wrote:
>>>
 On Fri, May 8, 2020 at 9:58 AM Aizhamal Nurmamat kyzy <
 aizha...@apache.org> wrote:

> I understand the difficulty, and this certainly comes with lessons
> learned for future similar projects.
>
> To your questions Robert:
> (1 and 2) I will commit to review the text in the resulting pages. I
> will try and use some automation to extract visible text from each page 
> and
> diff it with the current state of the website. I can do this starting next
> week. From some quick research, there seem to be tools that help with this
> analysis (
> https://stackoverflow.com/questions/3286955/compare-two-websites-and-see-if-they-are-equal
> )
>

 At first glance it looks like these tools would give diffs that are
 *larger* than the 47K one we're struggling to review here.


> By remaining in this state, we hold others up from making changes, or
> we increase the amount of work needed after merging to port over changes
> that may be missed. If we move forward, new changes can be done on top of
> the new website.
>

 I agree we don't want to hold others up from making changes. However,
 the amount of work to port changes over seems small in comparison to
 everything else that is being discussed here. (It also provides good
 incentives to reach the bar quickly and has the advantage of falling on the
 right people.) (3) will still take some time.

 If we go this route, we're lowering the bar for doc changes, but not
 removing it.


> (3) This makes sense. Brian, would you be able to spend some time to
> look at the automation changes (build files and scripts) to ensure they
> look fine?
>
> I would also like to write a post mortem to extract lessons learned
> and avoid this situation in the future.
>
>
> On Fri, May 8, 2020 at 9:44 AM Brian Hulette 
> wrote:
>
>> I'm -0 on merging as-is. I have the same concerns as Robert and he's
>> voiced them very well so I won't waste time re-airing them.
>>
>> (2) I spot checked the content, pulled out some common patterns, and
>>> it mostly looks good, but there were also some issues (e.g. several
>>> pages were replaced with the contents from entirely different pages).
>>> I would be more comfortable if, say, a smoke test of comparing the
>>> old
>>> and new sites, with html tags stripped and ignoring whitespace,

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Ahmet Altay]

This sounds reasonable to me. Thank you. Nam, does it make sense to you?

On Fri, May 8, 2020 at 11:53 AM Robert Bradshaw  wrote:

> I'd really like to not see this work go to waste, both the original
> revision, the further efforts Nam has done in making it more manageable to
> review, and the work put into reviewing this so far, so we can get the
> benefits of being on Hugo. How about this for a concrete proposal:
>
> (1) We get "standard" approval from one or more committers for the
> infrastructure changes, just as with any other PR. Brian has
> already started this, but if others could step up as well that'd be great.
>
> (2) Reviewers (and authors) typically count on (or request) sufficient
> automated test coverage to augment the fact that their eyeballs are
> fallible, which is something that is missing here (and given the size of
> the change not easily compensated for by a more detailed manual review).
> How about we use the script above (or similar) as an automated test to
> validate the website's contents haven't (materially) changed. I feel we've
> validated enough that the style looks good via spot checking (which is
> something that should work on all pages if it works on one). The diff
> between the current site and the newly generated site should be empty (it
> might already be [1]), or at least we should get a stamp of approval on the
> plain-text diff (which should be small), before merging.
>
> (3) To make things easier, everyone holds off on making any changes to the
> old site until a fixed future date (say, next Wednesday). Hopefully we can
> get it merged by then. If not, a condition for merging would be a
> commitment incorporating new changes after this date.
>
> Does this sound reasonable?
>
> - Robert
>
>
>
> [1] I'd be curious as to how small the diff already is, but my script
> relies on local directories with the generated HTML, which I don't have
> handy at the moment.
>
>
>
> On Fri, May 8, 2020 at 10:45 AM Robert Bradshaw 
> wrote:
>
>> Here's a script that we could run on the old and new sites that should
>> quickly catch any major issues but not get caught up in formatting minutia.
>>
>>
>>
>> On Fri, May 8, 2020 at 10:23 AM Robert Bradshaw 
>> wrote:
>>
>>> On Fri, May 8, 2020 at 9:58 AM Aizhamal Nurmamat kyzy <
>>> aizha...@apache.org> wrote:
>>>
 I understand the difficulty, and this certainly comes with lessons
 learned for future similar projects.

 To your questions Robert:
 (1 and 2) I will commit to review the text in the resulting pages. I
 will try and use some automation to extract visible text from each page and
 diff it with the current state of the website. I can do this starting next
 week. From some quick research, there seem to be tools that help with this
 analysis (
 https://stackoverflow.com/questions/3286955/compare-two-websites-and-see-if-they-are-equal
 )

>>>
>>> At first glance it looks like these tools would give diffs that are
>>> *larger* than the 47K one we're struggling to review here.
>>>
>>>
 By remaining in this state, we hold others up from making changes, or
 we increase the amount of work needed after merging to port over changes
 that may be missed. If we move forward, new changes can be done on top of
 the new website.

>>>
>>> I agree we don't want to hold others up from making changes. However,
>>> the amount of work to port changes over seems small in comparison to
>>> everything else that is being discussed here. (It also provides good
>>> incentives to reach the bar quickly and has the advantage of falling on the
>>> right people.) (3) will still take some time.
>>>
>>> If we go this route, we're lowering the bar for doc changes, but not
>>> removing it.
>>>
>>>
 (3) This makes sense. Brian, would you be able to spend some time to
 look at the automation changes (build files and scripts) to ensure they
 look fine?

 I would also like to write a post mortem to extract lessons learned and
 avoid this situation in the future.


 On Fri, May 8, 2020 at 9:44 AM Brian Hulette 
 wrote:

> I'm -0 on merging as-is. I have the same concerns as Robert and he's
> voiced them very well so I won't waste time re-airing them.
>
> (2) I spot checked the content, pulled out some common patterns, and
>> it mostly looks good, but there were also some issues (e.g. several
>> pages were replaced with the contents from entirely different pages).
>> I would be more comfortable if, say, a smoke test of comparing the old
>> and new sites, with html tags stripped and ignoring whitespace,
>> yielded what should be empty diffs.
>>
>
> Can you share any details about this analysis?
>

>>> It was basically paging through the diff, adding things to the sed
>>> script, and then looking at more diffs.
>>>
>>>
 +1 for verifying the old and new are the same by diffing the output.
>
>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Robert Bradshaw]

I'd really like to not see this work go to waste, both the original
revision, the further efforts Nam has done in making it more manageable to
review, and the work put into reviewing this so far, so we can get the
benefits of being on Hugo. How about this for a concrete proposal:

(1) We get "standard" approval from one or more committers for the
infrastructure changes, just as with any other PR. Brian has
already started this, but if others could step up as well that'd be great.

(2) Reviewers (and authors) typically count on (or request) sufficient
automated test coverage to augment the fact that their eyeballs are
fallible, which is something that is missing here (and given the size of
the change not easily compensated for by a more detailed manual review).
How about we use the script above (or similar) as an automated test to
validate the website's contents haven't (materially) changed. I feel we've
validated enough that the style looks good via spot checking (which is
something that should work on all pages if it works on one). The diff
between the current site and the newly generated site should be empty (it
might already be [1]), or at least we should get a stamp of approval on the
plain-text diff (which should be small), before merging.

(3) To make things easier, everyone holds off on making any changes to the
old site until a fixed future date (say, next Wednesday). Hopefully we can
get it merged by then. If not, a condition for merging would be a
commitment incorporating new changes after this date.

Does this sound reasonable?

- Robert



[1] I'd be curious as to how small the diff already is, but my script
relies on local directories with the generated HTML, which I don't have
handy at the moment.



On Fri, May 8, 2020 at 10:45 AM Robert Bradshaw  wrote:

> Here's a script that we could run on the old and new sites that should
> quickly catch any major issues but not get caught up in formatting minutia.
>
>
>
> On Fri, May 8, 2020 at 10:23 AM Robert Bradshaw 
> wrote:
>
>> On Fri, May 8, 2020 at 9:58 AM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>>
>>> I understand the difficulty, and this certainly comes with lessons
>>> learned for future similar projects.
>>>
>>> To your questions Robert:
>>> (1 and 2) I will commit to review the text in the resulting pages. I
>>> will try and use some automation to extract visible text from each page and
>>> diff it with the current state of the website. I can do this starting next
>>> week. From some quick research, there seem to be tools that help with this
>>> analysis (
>>> https://stackoverflow.com/questions/3286955/compare-two-websites-and-see-if-they-are-equal
>>> )
>>>
>>
>> At first glance it looks like these tools would give diffs that are
>> *larger* than the 47K one we're struggling to review here.
>>
>>
>>> By remaining in this state, we hold others up from making changes, or we
>>> increase the amount of work needed after merging to port over changes that
>>> may be missed. If we move forward, new changes can be done on top of the
>>> new website.
>>>
>>
>> I agree we don't want to hold others up from making changes. However, the
>> amount of work to port changes over seems small in comparison to everything
>> else that is being discussed here. (It also provides good incentives to
>> reach the bar quickly and has the advantage of falling on the right
>> people.) (3) will still take some time.
>>
>> If we go this route, we're lowering the bar for doc changes, but not
>> removing it.
>>
>>
>>> (3) This makes sense. Brian, would you be able to spend some time to
>>> look at the automation changes (build files and scripts) to ensure they
>>> look fine?
>>>
>>> I would also like to write a post mortem to extract lessons learned and
>>> avoid this situation in the future.
>>>
>>>
>>> On Fri, May 8, 2020 at 9:44 AM Brian Hulette 
>>> wrote:
>>>
 I'm -0 on merging as-is. I have the same concerns as Robert and he's
 voiced them very well so I won't waste time re-airing them.

 (2) I spot checked the content, pulled out some common patterns, and
> it mostly looks good, but there were also some issues (e.g. several
> pages were replaced with the contents from entirely different pages).
> I would be more comfortable if, say, a smoke test of comparing the old
> and new sites, with html tags stripped and ignoring whitespace,
> yielded what should be empty diffs.
>

 Can you share any details about this analysis?

>>>
>> It was basically paging through the diff, adding things to the sed
>> script, and then looking at more diffs.
>>
>>
>>> +1 for verifying the old and new are the same by diffing the output.


> (3) It'd be good to have someone give a stamp of approval on the
> infrastructure changes, at least to validate that we're not going to
> be taking on extra tech debt with regard to jenkins stability and
> developer workflow. I see that Brian has at least 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Robert Bradshaw]

Here's a script that we could run on the old and new sites that should
quickly catch any major issues but not get caught up in formatting minutia.



On Fri, May 8, 2020 at 10:23 AM Robert Bradshaw  wrote:

> On Fri, May 8, 2020 at 9:58 AM Aizhamal Nurmamat kyzy 
> wrote:
>
>> I understand the difficulty, and this certainly comes with lessons
>> learned for future similar projects.
>>
>> To your questions Robert:
>> (1 and 2) I will commit to review the text in the resulting pages. I will
>> try and use some automation to extract visible text from each page and diff
>> it with the current state of the website. I can do this starting next week.
>> From some quick research, there seem to be tools that help with this
>> analysis (
>> https://stackoverflow.com/questions/3286955/compare-two-websites-and-see-if-they-are-equal
>> )
>>
>
> At first glance it looks like these tools would give diffs that are
> *larger* than the 47K one we're struggling to review here.
>
>
>> By remaining in this state, we hold others up from making changes, or we
>> increase the amount of work needed after merging to port over changes that
>> may be missed. If we move forward, new changes can be done on top of the
>> new website.
>>
>
> I agree we don't want to hold others up from making changes. However, the
> amount of work to port changes over seems small in comparison to everything
> else that is being discussed here. (It also provides good incentives to
> reach the bar quickly and has the advantage of falling on the right
> people.) (3) will still take some time.
>
> If we go this route, we're lowering the bar for doc changes, but not
> removing it.
>
>
>> (3) This makes sense. Brian, would you be able to spend some time to look
>> at the automation changes (build files and scripts) to ensure they look
>> fine?
>>
>> I would also like to write a post mortem to extract lessons learned and
>> avoid this situation in the future.
>>
>>
>> On Fri, May 8, 2020 at 9:44 AM Brian Hulette  wrote:
>>
>>> I'm -0 on merging as-is. I have the same concerns as Robert and he's
>>> voiced them very well so I won't waste time re-airing them.
>>>
>>> (2) I spot checked the content, pulled out some common patterns, and
 it mostly looks good, but there were also some issues (e.g. several
 pages were replaced with the contents from entirely different pages).
 I would be more comfortable if, say, a smoke test of comparing the old
 and new sites, with html tags stripped and ignoring whitespace,
 yielded what should be empty diffs.

>>>
>>> Can you share any details about this analysis?
>>>
>>
> It was basically paging through the diff, adding things to the sed script,
> and then looking at more diffs.
>
>
>> +1 for verifying the old and new are the same by diffing the output.
>>>
>>>
 (3) It'd be good to have someone give a stamp of approval on the
 infrastructure changes, at least to validate that we're not going to
 be taking on extra tech debt with regard to jenkins stability and
 developer workflow. I see that Brian has at least looked at this some.
>>>
>>>
>>> My involvement so far was just recognizing a problem (creating
>>> root-owned files on jenkins workers) and helping to fix it. If there's
>>> anyone available who's familiar with the website infrastructure it would be
>>> great if they could take a look instead (if not I could probably acquaint
>>> myself enough to review).
>>>
>>> On Thu, May 7, 2020 at 11:57 PM Robert Bradshaw 
>>> wrote:
>>>
 This is a tough situation.

 It would have been much better if this transition was structured in
 such a way that the review was more manageable (e.g. the suggestion of
 scripts, not mixing in voluminous unnecessary changes like whitespace,
 and not updating content), and possibly even incrementally (e.g. the
 new site would have been developed over multiple PRs in a subdomain or
 subdirectory while being worked on). But hindsight is 20/20 and no
 one, myself included, thought to bring this up when the original
 migration was proposed, so this is more something to keep in mind for
 the future. I also appreciate the efforts that have been made to clean
 things up (e.g. preserving history) and address feedback.

 So, where do we go from here? My first thought is that I really don't
 want to set a precedent that just because a PR "will require a large
 effort" and in a state that if we don't "move forward and merge what
 we have now" then "work done so far will be lost" means that we think
 it's OK to forgo doing a proper review.

 On the other hand, there are some mitigating factors with this being
 the website and not the code in that "bugs," though possibly
 embarrassing, won't break production pipelines or data loss, and
 though the source is technically part of the release, when we find
 something to fix we can fix the live website much more quickly than go
 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Robert Bradshaw]

On Fri, May 8, 2020 at 9:58 AM Aizhamal Nurmamat kyzy 
wrote:

> I understand the difficulty, and this certainly comes with lessons learned
> for future similar projects.
>
> To your questions Robert:
> (1 and 2) I will commit to review the text in the resulting pages. I will
> try and use some automation to extract visible text from each page and diff
> it with the current state of the website. I can do this starting next week.
> From some quick research, there seem to be tools that help with this
> analysis (
> https://stackoverflow.com/questions/3286955/compare-two-websites-and-see-if-they-are-equal
> )
>

At first glance it looks like these tools would give diffs that are
*larger* than the 47K one we're struggling to review here.


> By remaining in this state, we hold others up from making changes, or we
> increase the amount of work needed after merging to port over changes that
> may be missed. If we move forward, new changes can be done on top of the
> new website.
>

I agree we don't want to hold others up from making changes. However, the
amount of work to port changes over seems small in comparison to everything
else that is being discussed here. (It also provides good incentives to
reach the bar quickly and has the advantage of falling on the right
people.) (3) will still take some time.

If we go this route, we're lowering the bar for doc changes, but not
removing it.


> (3) This makes sense. Brian, would you be able to spend some time to look
> at the automation changes (build files and scripts) to ensure they look
> fine?
>
> I would also like to write a post mortem to extract lessons learned and
> avoid this situation in the future.
>
>
> On Fri, May 8, 2020 at 9:44 AM Brian Hulette  wrote:
>
>> I'm -0 on merging as-is. I have the same concerns as Robert and he's
>> voiced them very well so I won't waste time re-airing them.
>>
>> (2) I spot checked the content, pulled out some common patterns, and
>>> it mostly looks good, but there were also some issues (e.g. several
>>> pages were replaced with the contents from entirely different pages).
>>> I would be more comfortable if, say, a smoke test of comparing the old
>>> and new sites, with html tags stripped and ignoring whitespace,
>>> yielded what should be empty diffs.
>>>
>>
>> Can you share any details about this analysis?
>>
>
It was basically paging through the diff, adding things to the sed script,
and then looking at more diffs.


> +1 for verifying the old and new are the same by diffing the output.
>>
>>
>>> (3) It'd be good to have someone give a stamp of approval on the
>>> infrastructure changes, at least to validate that we're not going to
>>> be taking on extra tech debt with regard to jenkins stability and
>>> developer workflow. I see that Brian has at least looked at this some.
>>
>>
>> My involvement so far was just recognizing a problem (creating root-owned
>> files on jenkins workers) and helping to fix it. If there's anyone
>> available who's familiar with the website infrastructure it would be great
>> if they could take a look instead (if not I could probably acquaint myself
>> enough to review).
>>
>> On Thu, May 7, 2020 at 11:57 PM Robert Bradshaw 
>> wrote:
>>
>>> This is a tough situation.
>>>
>>> It would have been much better if this transition was structured in
>>> such a way that the review was more manageable (e.g. the suggestion of
>>> scripts, not mixing in voluminous unnecessary changes like whitespace,
>>> and not updating content), and possibly even incrementally (e.g. the
>>> new site would have been developed over multiple PRs in a subdomain or
>>> subdirectory while being worked on). But hindsight is 20/20 and no
>>> one, myself included, thought to bring this up when the original
>>> migration was proposed, so this is more something to keep in mind for
>>> the future. I also appreciate the efforts that have been made to clean
>>> things up (e.g. preserving history) and address feedback.
>>>
>>> So, where do we go from here? My first thought is that I really don't
>>> want to set a precedent that just because a PR "will require a large
>>> effort" and in a state that if we don't "move forward and merge what
>>> we have now" then "work done so far will be lost" means that we think
>>> it's OK to forgo doing a proper review.
>>>
>>> On the other hand, there are some mitigating factors with this being
>>> the website and not the code in that "bugs," though possibly
>>> embarrassing, won't break production pipelines or data loss, and
>>> though the source is technically part of the release, when we find
>>> something to fix we can fix the live website much more quickly than go
>>> through the whole release process and convince people to upgrade. (I
>>> recognize accepting this argument is, to some degree at least, saying
>>> that we don't care about the correctness of docs as much as so-called
>>> "real" code, if we go there.)
>>>
>>> If we decide to go ahead and merge (and I would not object), there 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Also an update from +Nam Bui  :

"This commit [1] is up-to-date. So I walked through all of markdown files.
Apart from Syntax changes between Jekyll & Hugo, if there were any
differences in contents regarding to removed/added/modified, I would have
double check the text with the current website. I can make sure that now
98-99% (probably 100% if I don’t miss any typos) of the contents are synced
and 0 lost files. Thus, there should be no unexpected content changes which
appears in this commit [1] anymore.


[1]
https://github.com/apache/beam/pull/11554/commits/94e624fb43aa2218150fd3d97333c58d3d9ff653
"

On Fri, May 8, 2020 at 9:57 AM Aizhamal Nurmamat kyzy 
wrote:

> I understand the difficulty, and this certainly comes with lessons learned
> for future similar projects.
>
> To your questions Robert:
> (1 and 2) I will commit to review the text in the resulting pages. I will
> try and use some automation to extract visible text from each page and diff
> it with the current state of the website. I can do this starting next week.
> From some quick research, there seem to be tools that help with this
> analysis (
> https://stackoverflow.com/questions/3286955/compare-two-websites-and-see-if-they-are-equal
> )
> By remaining in this state, we hold others up from making changes, or we
> increase the amount of work needed after merging to port over changes that
> may be missed. If we move forward, new changes can be done on top of the
> new website.
>
> (3) This makes sense. Brian, would you be able to spend some time to look
> at the automation changes (build files and scripts) to ensure they look
> fine?
>
> I would also like to write a post mortem to extract lessons learned and
> avoid this situation in the future.
>
>
> On Fri, May 8, 2020 at 9:44 AM Brian Hulette  wrote:
>
>> I'm -0 on merging as-is. I have the same concerns as Robert and he's
>> voiced them very well so I won't waste time re-airing them.
>>
>> (2) I spot checked the content, pulled out some common patterns, and
>>> it mostly looks good, but there were also some issues (e.g. several
>>> pages were replaced with the contents from entirely different pages).
>>> I would be more comfortable if, say, a smoke test of comparing the old
>>> and new sites, with html tags stripped and ignoring whitespace,
>>> yielded what should be empty diffs.
>>>
>>
>> Can you share any details about this analysis?
>>
>> +1 for verifying the old and new are the same by diffing the output.
>>
>>
>>> (3) It'd be good to have someone give a stamp of approval on the
>>> infrastructure changes, at least to validate that we're not going to
>>> be taking on extra tech debt with regard to jenkins stability and
>>> developer workflow. I see that Brian has at least looked at this some.
>>
>>
>> My involvement so far was just recognizing a problem (creating root-owned
>> files on jenkins workers) and helping to fix it. If there's anyone
>> available who's familiar with the website infrastructure it would be great
>> if they could take a look instead (if not I could probably acquaint myself
>> enough to review).
>>
>> On Thu, May 7, 2020 at 11:57 PM Robert Bradshaw 
>> wrote:
>>
>>> This is a tough situation.
>>>
>>> It would have been much better if this transition was structured in
>>> such a way that the review was more manageable (e.g. the suggestion of
>>> scripts, not mixing in voluminous unnecessary changes like whitespace,
>>> and not updating content), and possibly even incrementally (e.g. the
>>> new site would have been developed over multiple PRs in a subdomain or
>>> subdirectory while being worked on). But hindsight is 20/20 and no
>>> one, myself included, thought to bring this up when the original
>>> migration was proposed, so this is more something to keep in mind for
>>> the future. I also appreciate the efforts that have been made to clean
>>> things up (e.g. preserving history) and address feedback.
>>>
>>> So, where do we go from here? My first thought is that I really don't
>>> want to set a precedent that just because a PR "will require a large
>>> effort" and in a state that if we don't "move forward and merge what
>>> we have now" then "work done so far will be lost" means that we think
>>> it's OK to forgo doing a proper review.
>>>
>>> On the other hand, there are some mitigating factors with this being
>>> the website and not the code in that "bugs," though possibly
>>> embarrassing, won't break production pipelines or data loss, and
>>> though the source is technically part of the release, when we find
>>> something to fix we can fix the live website much more quickly than go
>>> through the whole release process and convince people to upgrade. (I
>>> recognize accepting this argument is, to some degree at least, saying
>>> that we don't care about the correctness of docs as much as so-called
>>> "real" code, if we go there.)
>>>
>>> If we decide to go ahead and merge (and I would not object), there are
>>> some things I would like to see.
>>>
>>> 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

I understand the difficulty, and this certainly comes with lessons learned
for future similar projects.

To your questions Robert:
(1 and 2) I will commit to review the text in the resulting pages. I will
try and use some automation to extract visible text from each page and diff
it with the current state of the website. I can do this starting next week.
>From some quick research, there seem to be tools that help with this
analysis (
https://stackoverflow.com/questions/3286955/compare-two-websites-and-see-if-they-are-equal
)
By remaining in this state, we hold others up from making changes, or we
increase the amount of work needed after merging to port over changes that
may be missed. If we move forward, new changes can be done on top of the
new website.

(3) This makes sense. Brian, would you be able to spend some time to look
at the automation changes (build files and scripts) to ensure they look
fine?

I would also like to write a post mortem to extract lessons learned and
avoid this situation in the future.


On Fri, May 8, 2020 at 9:44 AM Brian Hulette  wrote:

> I'm -0 on merging as-is. I have the same concerns as Robert and he's
> voiced them very well so I won't waste time re-airing them.
>
> (2) I spot checked the content, pulled out some common patterns, and
>> it mostly looks good, but there were also some issues (e.g. several
>> pages were replaced with the contents from entirely different pages).
>> I would be more comfortable if, say, a smoke test of comparing the old
>> and new sites, with html tags stripped and ignoring whitespace,
>> yielded what should be empty diffs.
>>
>
> Can you share any details about this analysis?
>
> +1 for verifying the old and new are the same by diffing the output.
>
>
>> (3) It'd be good to have someone give a stamp of approval on the
>> infrastructure changes, at least to validate that we're not going to
>> be taking on extra tech debt with regard to jenkins stability and
>> developer workflow. I see that Brian has at least looked at this some.
>
>
> My involvement so far was just recognizing a problem (creating root-owned
> files on jenkins workers) and helping to fix it. If there's anyone
> available who's familiar with the website infrastructure it would be great
> if they could take a look instead (if not I could probably acquaint myself
> enough to review).
>
> On Thu, May 7, 2020 at 11:57 PM Robert Bradshaw 
> wrote:
>
>> This is a tough situation.
>>
>> It would have been much better if this transition was structured in
>> such a way that the review was more manageable (e.g. the suggestion of
>> scripts, not mixing in voluminous unnecessary changes like whitespace,
>> and not updating content), and possibly even incrementally (e.g. the
>> new site would have been developed over multiple PRs in a subdomain or
>> subdirectory while being worked on). But hindsight is 20/20 and no
>> one, myself included, thought to bring this up when the original
>> migration was proposed, so this is more something to keep in mind for
>> the future. I also appreciate the efforts that have been made to clean
>> things up (e.g. preserving history) and address feedback.
>>
>> So, where do we go from here? My first thought is that I really don't
>> want to set a precedent that just because a PR "will require a large
>> effort" and in a state that if we don't "move forward and merge what
>> we have now" then "work done so far will be lost" means that we think
>> it's OK to forgo doing a proper review.
>>
>> On the other hand, there are some mitigating factors with this being
>> the website and not the code in that "bugs," though possibly
>> embarrassing, won't break production pipelines or data loss, and
>> though the source is technically part of the release, when we find
>> something to fix we can fix the live website much more quickly than go
>> through the whole release process and convince people to upgrade. (I
>> recognize accepting this argument is, to some degree at least, saying
>> that we don't care about the correctness of docs as much as so-called
>> "real" code, if we go there.)
>>
>> If we decide to go ahead and merge (and I would not object), there are
>> some things I would like to see.
>>
>> (1) I would like to understand what we would do afterwards to "review
>> the outcome, and ensure that all the content is there," and why it
>> can't be done before merging instead. (Is it because it'd take time
>> and we don't want to incorporate changes that are made to the website
>> in the meantime? I think that boat has sailed, but maybe we can avoid
>> making it worse...)
>>
>> (2) I spot checked the content, pulled out some common patterns, and
>> it mostly looks good, but there were also some issues (e.g. several
>> pages were replaced with the contents from entirely different pages).
>> I would be more comfortable if, say, a smoke test of comparing the old
>> and new sites, with html tags stripped and ignoring whitespace,
>> yielded what should be empty diffs.
>>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Brian Hulette]

I'm -0 on merging as-is. I have the same concerns as Robert and he's voiced
them very well so I won't waste time re-airing them.

(2) I spot checked the content, pulled out some common patterns, and
> it mostly looks good, but there were also some issues (e.g. several
> pages were replaced with the contents from entirely different pages).
> I would be more comfortable if, say, a smoke test of comparing the old
> and new sites, with html tags stripped and ignoring whitespace,
> yielded what should be empty diffs.
>

Can you share any details about this analysis?

+1 for verifying the old and new are the same by diffing the output.


> (3) It'd be good to have someone give a stamp of approval on the
> infrastructure changes, at least to validate that we're not going to
> be taking on extra tech debt with regard to jenkins stability and
> developer workflow. I see that Brian has at least looked at this some.


My involvement so far was just recognizing a problem (creating root-owned
files on jenkins workers) and helping to fix it. If there's anyone
available who's familiar with the website infrastructure it would be great
if they could take a look instead (if not I could probably acquaint myself
enough to review).

On Thu, May 7, 2020 at 11:57 PM Robert Bradshaw  wrote:

> This is a tough situation.
>
> It would have been much better if this transition was structured in
> such a way that the review was more manageable (e.g. the suggestion of
> scripts, not mixing in voluminous unnecessary changes like whitespace,
> and not updating content), and possibly even incrementally (e.g. the
> new site would have been developed over multiple PRs in a subdomain or
> subdirectory while being worked on). But hindsight is 20/20 and no
> one, myself included, thought to bring this up when the original
> migration was proposed, so this is more something to keep in mind for
> the future. I also appreciate the efforts that have been made to clean
> things up (e.g. preserving history) and address feedback.
>
> So, where do we go from here? My first thought is that I really don't
> want to set a precedent that just because a PR "will require a large
> effort" and in a state that if we don't "move forward and merge what
> we have now" then "work done so far will be lost" means that we think
> it's OK to forgo doing a proper review.
>
> On the other hand, there are some mitigating factors with this being
> the website and not the code in that "bugs," though possibly
> embarrassing, won't break production pipelines or data loss, and
> though the source is technically part of the release, when we find
> something to fix we can fix the live website much more quickly than go
> through the whole release process and convince people to upgrade. (I
> recognize accepting this argument is, to some degree at least, saying
> that we don't care about the correctness of docs as much as so-called
> "real" code, if we go there.)
>
> If we decide to go ahead and merge (and I would not object), there are
> some things I would like to see.
>
> (1) I would like to understand what we would do afterwards to "review
> the outcome, and ensure that all the content is there," and why it
> can't be done before merging instead. (Is it because it'd take time
> and we don't want to incorporate changes that are made to the website
> in the meantime? I think that boat has sailed, but maybe we can avoid
> making it worse...)
>
> (2) I spot checked the content, pulled out some common patterns, and
> it mostly looks good, but there were also some issues (e.g. several
> pages were replaced with the contents from entirely different pages).
> I would be more comfortable if, say, a smoke test of comparing the old
> and new sites, with html tags stripped and ignoring whitespace,
> yielded what should be empty diffs.
>
> (3) It'd be good to have someone give a stamp of approval on the
> infrastructure changes, at least to validate that we're not going to
> be taking on extra tech debt with regard to jenkins stability and
> developer workflow. I see that Brian has at least looked at this some.
>
> - Robert
>
>
> On Thu, May 7, 2020 at 12:40 PM Aizhamal Nurmamat kyzy
>  wrote:
> >
> > Thank you Ahmet.
> >
> > Robert/Brian, what do you think?
> >
> > The website staging and pre commit tests have passed [1]. If nobody has
> objections, we could merge it soon.
> >
> >
> > [1] https://github.com/apache/beam/pull/11554
> >
> > On Thu, May 7, 2020 at 11:38 AM Ahmet Altay  wrote:
> >>
> >>
> >>
> >> On Thu, May 7, 2020 at 10:50 AM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
> >>>
> >>> Thanks for the writeup Ahmet.
> >>>
> >>> My bias is to move forward and merge the PR. After this, we'll review
> the outcome, and ensure that all the content is there. Nam will help us
> with that.
> >>> The reason that I'd like to move forward and merge what we have now -
> is that if we don't do that, the work done so far will be lost.
> >>> We'll make sure to stage the website in 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Robert Bradshaw]

This is a tough situation.

It would have been much better if this transition was structured in
such a way that the review was more manageable (e.g. the suggestion of
scripts, not mixing in voluminous unnecessary changes like whitespace,
and not updating content), and possibly even incrementally (e.g. the
new site would have been developed over multiple PRs in a subdomain or
subdirectory while being worked on). But hindsight is 20/20 and no
one, myself included, thought to bring this up when the original
migration was proposed, so this is more something to keep in mind for
the future. I also appreciate the efforts that have been made to clean
things up (e.g. preserving history) and address feedback.

So, where do we go from here? My first thought is that I really don't
want to set a precedent that just because a PR "will require a large
effort" and in a state that if we don't "move forward and merge what
we have now" then "work done so far will be lost" means that we think
it's OK to forgo doing a proper review.

On the other hand, there are some mitigating factors with this being
the website and not the code in that "bugs," though possibly
embarrassing, won't break production pipelines or data loss, and
though the source is technically part of the release, when we find
something to fix we can fix the live website much more quickly than go
through the whole release process and convince people to upgrade. (I
recognize accepting this argument is, to some degree at least, saying
that we don't care about the correctness of docs as much as so-called
"real" code, if we go there.)

If we decide to go ahead and merge (and I would not object), there are
some things I would like to see.

(1) I would like to understand what we would do afterwards to "review
the outcome, and ensure that all the content is there," and why it
can't be done before merging instead. (Is it because it'd take time
and we don't want to incorporate changes that are made to the website
in the meantime? I think that boat has sailed, but maybe we can avoid
making it worse...)

(2) I spot checked the content, pulled out some common patterns, and
it mostly looks good, but there were also some issues (e.g. several
pages were replaced with the contents from entirely different pages).
I would be more comfortable if, say, a smoke test of comparing the old
and new sites, with html tags stripped and ignoring whitespace,
yielded what should be empty diffs.

(3) It'd be good to have someone give a stamp of approval on the
infrastructure changes, at least to validate that we're not going to
be taking on extra tech debt with regard to jenkins stability and
developer workflow. I see that Brian has at least looked at this some.

- Robert


On Thu, May 7, 2020 at 12:40 PM Aizhamal Nurmamat kyzy
 wrote:
>
> Thank you Ahmet.
>
> Robert/Brian, what do you think?
>
> The website staging and pre commit tests have passed [1]. If nobody has 
> objections, we could merge it soon.
>
>
> [1] https://github.com/apache/beam/pull/11554
>
> On Thu, May 7, 2020 at 11:38 AM Ahmet Altay  wrote:
>>
>>
>>
>> On Thu, May 7, 2020 at 10:50 AM Aizhamal Nurmamat kyzy  
>> wrote:
>>>
>>> Thanks for the writeup Ahmet.
>>>
>>> My bias is to move forward and merge the PR. After this, we'll review the 
>>> outcome, and ensure that all the content is there. Nam will help us with 
>>> that.
>>> The reason that I'd like to move forward and merge what we have now - is 
>>> that if we don't do that, the work done so far will be lost.
>>> We'll make sure to stage the website in its current state, and use that as 
>>> reference/archive to ensure all the content have been moved.
>>>
>>> Is this reasonable to everyone?
>>
>>
>> This is reasonable to me. I agree with your reasons.
>>
>> What do others think?
>>
>>>
>>>
>>>
>>> On Wed, May 6, 2020 at 7:07 PM Ahmet Altay  wrote:



 On Wed, May 6, 2020 at 2:33 PM Aizhamal Nurmamat kyzy 
  wrote:
>>
>>
>> > 1) Currently, the main blocker for merging is Staging Test Failures.
>>
>> That and finishing the review. (Is someone tracking/coordinating this?)
>
>
> I am coordinating the work on the failed tests, but I would need other 
> committer's help to perform the review. @Ahmet, could you help us 
> prioritize the review for this PR?


 The problem is there are too many manual changes. Reviewing this change in 
 this form will require a large effort. I do not think I can interrupt 
 other projects to prioritize reviews on this PR. IMO, we have a few 
 options:

 - PR to be restructured in the format suggested in this thread. A commit 
 for infrastructure changes from Jekyll to hugo. A second commit for a 
 script that will convert the majority of the content. A third commit for 
 the execution of the script. And a fourth commit for the additional manual 
 content changes. If Nam can get to this form, people on this thread 
 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Thank you Ahmet.

Robert/Brian, what do you think?

The website staging and pre commit tests have passed [1]. If nobody has
objections, we could merge it soon.


[1] https://github.com/apache/beam/pull/11554

On Thu, May 7, 2020 at 11:38 AM Ahmet Altay  wrote:

>
>
> On Thu, May 7, 2020 at 10:50 AM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
>
>> Thanks for the writeup Ahmet.
>>
>> My bias is to move forward and merge the PR. After this, we'll review the
>> outcome, and ensure that all the content is there. Nam will help us with
>> that.
>> The reason that I'd like to move forward and merge what we have now - is
>> that if we don't do that, the work done so far will be lost.
>> We'll make sure to stage the website in its current state, and use that
>> as reference/archive to ensure all the content have been moved.
>>
>> Is this reasonable to everyone?
>>
>
> This is reasonable to me. I agree with your reasons.
>
> What do others think?
>
>
>>
>>
>> On Wed, May 6, 2020 at 7:07 PM Ahmet Altay  wrote:
>>
>>>
>>>
>>> On Wed, May 6, 2020 at 2:33 PM Aizhamal Nurmamat kyzy <
>>> aizha...@apache.org> wrote:
>>>

> > 1) Currently, the main blocker for merging is Staging Test Failures.
>
> That and finishing the review. (Is someone tracking/coordinating this?)
>

 I am coordinating the work on the failed tests, but I would need other
 committer's help to perform the review. @Ahmet, could you help us
 prioritize the review for this PR?

>>>
>>> The problem is there are too many manual changes. Reviewing this change
>>> in this form will require a large effort. I do not think I can interrupt
>>> other projects to prioritize reviews on this PR. IMO, we have a few options:
>>>
>>> - PR to be restructured in the format suggested in this thread. A commit
>>> for infrastructure changes from Jekyll to hugo. A second commit for a
>>> script that will convert the majority of the content. A third commit for
>>> the execution of the script. And a fourth commit for the additional manual
>>> content changes. If Nam can get to this form, people on this thread
>>> myself/Robert/Pablo/Brian can review the changes.
>>> - Another option is, we can accept that we already invested in this
>>> transition and overall this is a good change, and merge the PR more or less
>>> in its current form (with tests fixed and open comments addressed) even
>>> though it has issues. And then overtime fix the issues we encounter. There
>>> was already some amount of review and visual comparisons, we risk losing
>>> some recent content changes but I am assuming this will not be much. If Nam
>>> can commit to compare two sites after a merge, fixing the majority of the
>>> delta, this might be a viable option.
>>>
>>> Another thing we can do, we can archive/store a read-only copy of the
>>> current website in an "archive" url temporarily instead of completely
>>> deleting it. It will give us a baseline for a while to go back to the old
>>> content and move any missing data. (And maybe, someone can come up with an
>>> innovative way to compare the textual content of both sites.) A note on the
>>> stop world approach, I believe we are already failing on that with merge
>>> conflicts showing up on the PR. It will be better for us to complete the
>>> transition as soon as possible. Fixing after the initial merge might be a
>>> simpler task, especially if we can archive the old site.
>>>
>>>


> > Michal showed Nam how to handle the 1st test which was about Apache
> License missing.
> >
> > However, the 2nd and 3rd tests looked like some kind of permissions
> error on the Jenkins worker, not to be configured by code. For more 
> details
> based on Jenkin logs, the 2nd test failed because of
> website/www/site/themes and the 3rd test failed because of
> website/www/node_modules, they are both auto-generated files on build. Can
> someone help Nam to look into this?
> >
> > RAT ("Run RAT PreCommit") — FAILURE
> > Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
> > Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
> >
> > 2) Are there any other blockers for merging? @Ahmet/Robert/others
> please share if there are any other blockers.
> >
> >
> > [1] https://github.com/gohugoio/hugo/pull/4494
> >
> >
> > On Wed, May 6, 2020 at 10:19 AM Robert Bradshaw 
> wrote:
> >>
> >> On Mon, May 4, 2020 at 7:07 PM Ahmet Altay 
> wrote:
> >> >
> >> >> On Mon, May 4, 2020 at 6:30 PM Robert Bradshaw <
> rober...@google.com> wrote:
> >> >>>
> >> >>> I took the massive commit and split it up into:
> >> >>>
> >> >>> (1) Infrastructure changes (basically everything outside of
> >> >>> (website/www/site/content)
> >> >>> (2) Sed script changes, and
> >> >>> (3) Manual changes (everything not in (1) and (2)).
> >> >
> >> >
> >> > Thank you 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Ahmet Altay]

On Thu, May 7, 2020 at 10:50 AM Aizhamal Nurmamat kyzy 
wrote:

> Thanks for the writeup Ahmet.
>
> My bias is to move forward and merge the PR. After this, we'll review the
> outcome, and ensure that all the content is there. Nam will help us with
> that.
> The reason that I'd like to move forward and merge what we have now - is
> that if we don't do that, the work done so far will be lost.
> We'll make sure to stage the website in its current state, and use that as
> reference/archive to ensure all the content have been moved.
>
> Is this reasonable to everyone?
>

This is reasonable to me. I agree with your reasons.

What do others think?


>
>
> On Wed, May 6, 2020 at 7:07 PM Ahmet Altay  wrote:
>
>>
>>
>> On Wed, May 6, 2020 at 2:33 PM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>>
>>>
 > 1) Currently, the main blocker for merging is Staging Test Failures.

 That and finishing the review. (Is someone tracking/coordinating this?)

>>>
>>> I am coordinating the work on the failed tests, but I would need other
>>> committer's help to perform the review. @Ahmet, could you help us
>>> prioritize the review for this PR?
>>>
>>
>> The problem is there are too many manual changes. Reviewing this change
>> in this form will require a large effort. I do not think I can interrupt
>> other projects to prioritize reviews on this PR. IMO, we have a few options:
>>
>> - PR to be restructured in the format suggested in this thread. A commit
>> for infrastructure changes from Jekyll to hugo. A second commit for a
>> script that will convert the majority of the content. A third commit for
>> the execution of the script. And a fourth commit for the additional manual
>> content changes. If Nam can get to this form, people on this thread
>> myself/Robert/Pablo/Brian can review the changes.
>> - Another option is, we can accept that we already invested in this
>> transition and overall this is a good change, and merge the PR more or less
>> in its current form (with tests fixed and open comments addressed) even
>> though it has issues. And then overtime fix the issues we encounter. There
>> was already some amount of review and visual comparisons, we risk losing
>> some recent content changes but I am assuming this will not be much. If Nam
>> can commit to compare two sites after a merge, fixing the majority of the
>> delta, this might be a viable option.
>>
>> Another thing we can do, we can archive/store a read-only copy of the
>> current website in an "archive" url temporarily instead of completely
>> deleting it. It will give us a baseline for a while to go back to the old
>> content and move any missing data. (And maybe, someone can come up with an
>> innovative way to compare the textual content of both sites.) A note on the
>> stop world approach, I believe we are already failing on that with merge
>> conflicts showing up on the PR. It will be better for us to complete the
>> transition as soon as possible. Fixing after the initial merge might be a
>> simpler task, especially if we can archive the old site.
>>
>>
>>>
>>>
 > Michal showed Nam how to handle the 1st test which was about Apache
 License missing.
 >
 > However, the 2nd and 3rd tests looked like some kind of permissions
 error on the Jenkins worker, not to be configured by code. For more details
 based on Jenkin logs, the 2nd test failed because of
 website/www/site/themes and the 3rd test failed because of
 website/www/node_modules, they are both auto-generated files on build. Can
 someone help Nam to look into this?
 >
 > RAT ("Run RAT PreCommit") — FAILURE
 > Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
 > Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
 >
 > 2) Are there any other blockers for merging? @Ahmet/Robert/others
 please share if there are any other blockers.
 >
 >
 > [1] https://github.com/gohugoio/hugo/pull/4494
 >
 >
 > On Wed, May 6, 2020 at 10:19 AM Robert Bradshaw 
 wrote:
 >>
 >> On Mon, May 4, 2020 at 7:07 PM Ahmet Altay  wrote:
 >> >
 >> >> On Mon, May 4, 2020 at 6:30 PM Robert Bradshaw <
 rober...@google.com> wrote:
 >> >>>
 >> >>> I took the massive commit and split it up into:
 >> >>>
 >> >>> (1) Infrastructure changes (basically everything outside of
 >> >>> (website/www/site/content)
 >> >>> (2) Sed script changes, and
 >> >>> (3) Manual changes (everything not in (1) and (2)).
 >> >
 >> >
 >> > Thank you Robert. This makes it much easier. What is the source of
 the sed script? I am not sure why some of those lines are there. It would
 be much easier for us to comment on the script source if it is reviewable
 somewhere.
 >>
 >> I just gathered up common patterns as I was trying to go through and
 >> review the files... Mostly it was an exercise in finding a compact
 >> representation for 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Thanks for the writeup Ahmet.

My bias is to move forward and merge the PR. After this, we'll review the
outcome, and ensure that all the content is there. Nam will help us with
that.
The reason that I'd like to move forward and merge what we have now - is
that if we don't do that, the work done so far will be lost.
We'll make sure to stage the website in its current state, and use that as
reference/archive to ensure all the content have been moved.

Is this reasonable to everyone?


On Wed, May 6, 2020 at 7:07 PM Ahmet Altay  wrote:

>
>
> On Wed, May 6, 2020 at 2:33 PM Aizhamal Nurmamat kyzy 
> wrote:
>
>>
>>> > 1) Currently, the main blocker for merging is Staging Test Failures.
>>>
>>> That and finishing the review. (Is someone tracking/coordinating this?)
>>>
>>
>> I am coordinating the work on the failed tests, but I would need other
>> committer's help to perform the review. @Ahmet, could you help us
>> prioritize the review for this PR?
>>
>
> The problem is there are too many manual changes. Reviewing this change in
> this form will require a large effort. I do not think I can interrupt other
> projects to prioritize reviews on this PR. IMO, we have a few options:
>
> - PR to be restructured in the format suggested in this thread. A commit
> for infrastructure changes from Jekyll to hugo. A second commit for a
> script that will convert the majority of the content. A third commit for
> the execution of the script. And a fourth commit for the additional manual
> content changes. If Nam can get to this form, people on this thread
> myself/Robert/Pablo/Brian can review the changes.
> - Another option is, we can accept that we already invested in this
> transition and overall this is a good change, and merge the PR more or less
> in its current form (with tests fixed and open comments addressed) even
> though it has issues. And then overtime fix the issues we encounter. There
> was already some amount of review and visual comparisons, we risk losing
> some recent content changes but I am assuming this will not be much. If Nam
> can commit to compare two sites after a merge, fixing the majority of the
> delta, this might be a viable option.
>
> Another thing we can do, we can archive/store a read-only copy of the
> current website in an "archive" url temporarily instead of completely
> deleting it. It will give us a baseline for a while to go back to the old
> content and move any missing data. (And maybe, someone can come up with an
> innovative way to compare the textual content of both sites.) A note on the
> stop world approach, I believe we are already failing on that with merge
> conflicts showing up on the PR. It will be better for us to complete the
> transition as soon as possible. Fixing after the initial merge might be a
> simpler task, especially if we can archive the old site.
>
>
>>
>>
>>> > Michal showed Nam how to handle the 1st test which was about Apache
>>> License missing.
>>> >
>>> > However, the 2nd and 3rd tests looked like some kind of permissions
>>> error on the Jenkins worker, not to be configured by code. For more details
>>> based on Jenkin logs, the 2nd test failed because of
>>> website/www/site/themes and the 3rd test failed because of
>>> website/www/node_modules, they are both auto-generated files on build. Can
>>> someone help Nam to look into this?
>>> >
>>> > RAT ("Run RAT PreCommit") — FAILURE
>>> > Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
>>> > Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
>>> >
>>> > 2) Are there any other blockers for merging? @Ahmet/Robert/others
>>> please share if there are any other blockers.
>>> >
>>> >
>>> > [1] https://github.com/gohugoio/hugo/pull/4494
>>> >
>>> >
>>> > On Wed, May 6, 2020 at 10:19 AM Robert Bradshaw 
>>> wrote:
>>> >>
>>> >> On Mon, May 4, 2020 at 7:07 PM Ahmet Altay  wrote:
>>> >> >
>>> >> >> On Mon, May 4, 2020 at 6:30 PM Robert Bradshaw <
>>> rober...@google.com> wrote:
>>> >> >>>
>>> >> >>> I took the massive commit and split it up into:
>>> >> >>>
>>> >> >>> (1) Infrastructure changes (basically everything outside of
>>> >> >>> (website/www/site/content)
>>> >> >>> (2) Sed script changes, and
>>> >> >>> (3) Manual changes (everything not in (1) and (2)).
>>> >> >
>>> >> >
>>> >> > Thank you Robert. This makes it much easier. What is the source of
>>> the sed script? I am not sure why some of those lines are there. It would
>>> be much easier for us to comment on the script source if it is reviewable
>>> somewhere.
>>> >>
>>> >> I just gathered up common patterns as I was trying to go through and
>>> >> review the files... Mostly it was an exercise in finding a compact
>>> >> representation for the delta, not trying to be a perfect conversion.
>>> >> (I do think in retrospect, if we do something like this again, it
>>> >> would be preferable to commit a script that does the auto-conversion
>>> >> (maybe even with some patch files for manual changes) both for ease of
>>> >> 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Ahmet Altay]

On Wed, May 6, 2020 at 2:33 PM Aizhamal Nurmamat kyzy 
wrote:

>
>> > 1) Currently, the main blocker for merging is Staging Test Failures.
>>
>> That and finishing the review. (Is someone tracking/coordinating this?)
>>
>
> I am coordinating the work on the failed tests, but I would need other
> committer's help to perform the review. @Ahmet, could you help us
> prioritize the review for this PR?
>

The problem is there are too many manual changes. Reviewing this change in
this form will require a large effort. I do not think I can interrupt other
projects to prioritize reviews on this PR. IMO, we have a few options:

- PR to be restructured in the format suggested in this thread. A commit
for infrastructure changes from Jekyll to hugo. A second commit for a
script that will convert the majority of the content. A third commit for
the execution of the script. And a fourth commit for the additional manual
content changes. If Nam can get to this form, people on this thread
myself/Robert/Pablo/Brian can review the changes.
- Another option is, we can accept that we already invested in this
transition and overall this is a good change, and merge the PR more or less
in its current form (with tests fixed and open comments addressed) even
though it has issues. And then overtime fix the issues we encounter. There
was already some amount of review and visual comparisons, we risk losing
some recent content changes but I am assuming this will not be much. If Nam
can commit to compare two sites after a merge, fixing the majority of the
delta, this might be a viable option.

Another thing we can do, we can archive/store a read-only copy of the
current website in an "archive" url temporarily instead of completely
deleting it. It will give us a baseline for a while to go back to the old
content and move any missing data. (And maybe, someone can come up with an
innovative way to compare the textual content of both sites.) A note on the
stop world approach, I believe we are already failing on that with merge
conflicts showing up on the PR. It will be better for us to complete the
transition as soon as possible. Fixing after the initial merge might be a
simpler task, especially if we can archive the old site.


>
>
>> > Michal showed Nam how to handle the 1st test which was about Apache
>> License missing.
>> >
>> > However, the 2nd and 3rd tests looked like some kind of permissions
>> error on the Jenkins worker, not to be configured by code. For more details
>> based on Jenkin logs, the 2nd test failed because of
>> website/www/site/themes and the 3rd test failed because of
>> website/www/node_modules, they are both auto-generated files on build. Can
>> someone help Nam to look into this?
>> >
>> > RAT ("Run RAT PreCommit") — FAILURE
>> > Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
>> > Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
>> >
>> > 2) Are there any other blockers for merging? @Ahmet/Robert/others
>> please share if there are any other blockers.
>> >
>> >
>> > [1] https://github.com/gohugoio/hugo/pull/4494
>> >
>> >
>> > On Wed, May 6, 2020 at 10:19 AM Robert Bradshaw 
>> wrote:
>> >>
>> >> On Mon, May 4, 2020 at 7:07 PM Ahmet Altay  wrote:
>> >> >
>> >> >> On Mon, May 4, 2020 at 6:30 PM Robert Bradshaw 
>> wrote:
>> >> >>>
>> >> >>> I took the massive commit and split it up into:
>> >> >>>
>> >> >>> (1) Infrastructure changes (basically everything outside of
>> >> >>> (website/www/site/content)
>> >> >>> (2) Sed script changes, and
>> >> >>> (3) Manual changes (everything not in (1) and (2)).
>> >> >
>> >> >
>> >> > Thank you Robert. This makes it much easier. What is the source of
>> the sed script? I am not sure why some of those lines are there. It would
>> be much easier for us to comment on the script source if it is reviewable
>> somewhere.
>> >>
>> >> I just gathered up common patterns as I was trying to go through and
>> >> review the files... Mostly it was an exercise in finding a compact
>> >> representation for the delta, not trying to be a perfect conversion.
>> >> (I do think in retrospect, if we do something like this again, it
>> >> would be preferable to commit a script that does the auto-conversion
>> >> (maybe even with some patch files for manual changes) both for ease of
>> >> reviewing and to avoid the stop-the-world situation we're in now. (I'm
>> >> still worried that some changes will get lost in the shuffle.)
>>
>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

>
>
> > 1) Currently, the main blocker for merging is Staging Test Failures.
>
> That and finishing the review. (Is someone tracking/coordinating this?)
>

I am coordinating the work on the failed tests, but I would need other
committer's help to perform the review. @Ahmet, could you help us
prioritize the review for this PR?



> > Michal showed Nam how to handle the 1st test which was about Apache
> License missing.
> >
> > However, the 2nd and 3rd tests looked like some kind of permissions
> error on the Jenkins worker, not to be configured by code. For more details
> based on Jenkin logs, the 2nd test failed because of
> website/www/site/themes and the 3rd test failed because of
> website/www/node_modules, they are both auto-generated files on build. Can
> someone help Nam to look into this?
> >
> > RAT ("Run RAT PreCommit") — FAILURE
> > Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
> > Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
> >
> > 2) Are there any other blockers for merging? @Ahmet/Robert/others please
> share if there are any other blockers.
> >
> >
> > [1] https://github.com/gohugoio/hugo/pull/4494
> >
> >
> > On Wed, May 6, 2020 at 10:19 AM Robert Bradshaw 
> wrote:
> >>
> >> On Mon, May 4, 2020 at 7:07 PM Ahmet Altay  wrote:
> >> >
> >> >> On Mon, May 4, 2020 at 6:30 PM Robert Bradshaw 
> wrote:
> >> >>>
> >> >>> I took the massive commit and split it up into:
> >> >>>
> >> >>> (1) Infrastructure changes (basically everything outside of
> >> >>> (website/www/site/content)
> >> >>> (2) Sed script changes, and
> >> >>> (3) Manual changes (everything not in (1) and (2)).
> >> >
> >> >
> >> > Thank you Robert. This makes it much easier. What is the source of
> the sed script? I am not sure why some of those lines are there. It would
> be much easier for us to comment on the script source if it is reviewable
> somewhere.
> >>
> >> I just gathered up common patterns as I was trying to go through and
> >> review the files... Mostly it was an exercise in finding a compact
> >> representation for the delta, not trying to be a perfect conversion.
> >> (I do think in retrospect, if we do something like this again, it
> >> would be preferable to commit a script that does the auto-conversion
> >> (maybe even with some patch files for manual changes) both for ease of
> >> reviewing and to avoid the stop-the-world situation we're in now. (I'm
> >> still worried that some changes will get lost in the shuffle.)
>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Robert Bradshaw]

On Wed, May 6, 2020 at 1:01 PM Aizhamal Nurmamat kyzy
 wrote:
>
> Hi all,
>
> Nam and Brian have been working together on blog post names and the decision 
> was to keep them as they are for now, because Hugo doesn’t fully support the 
> feature that was mentioned earlier [1]. Also I believe this can be done after 
> merging the PR.
>
> 1) Currently, the main blocker for merging is Staging Test Failures.

That and finishing the review. (Is someone tracking/coordinating this?)

> Michal showed Nam how to handle the 1st test which was about Apache License 
> missing.
>
> However, the 2nd and 3rd tests looked like some kind of permissions error on 
> the Jenkins worker, not to be configured by code. For more details based on 
> Jenkin logs, the 2nd test failed because of website/www/site/themes and the 
> 3rd test failed because of website/www/node_modules, they are both 
> auto-generated files on build. Can someone help Nam to look into this?
>
> RAT ("Run RAT PreCommit") — FAILURE
> Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
> Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
>
> 2) Are there any other blockers for merging? @Ahmet/Robert/others please 
> share if there are any other blockers.
>
>
> [1] https://github.com/gohugoio/hugo/pull/4494
>
>
> On Wed, May 6, 2020 at 10:19 AM Robert Bradshaw  wrote:
>>
>> On Mon, May 4, 2020 at 7:07 PM Ahmet Altay  wrote:
>> >
>> >> On Mon, May 4, 2020 at 6:30 PM Robert Bradshaw  
>> >> wrote:
>> >>>
>> >>> I took the massive commit and split it up into:
>> >>>
>> >>> (1) Infrastructure changes (basically everything outside of
>> >>> (website/www/site/content)
>> >>> (2) Sed script changes, and
>> >>> (3) Manual changes (everything not in (1) and (2)).
>> >
>> >
>> > Thank you Robert. This makes it much easier. What is the source of the sed 
>> > script? I am not sure why some of those lines are there. It would be much 
>> > easier for us to comment on the script source if it is reviewable 
>> > somewhere.
>>
>> I just gathered up common patterns as I was trying to go through and
>> review the files... Mostly it was an exercise in finding a compact
>> representation for the delta, not trying to be a perfect conversion.
>> (I do think in retrospect, if we do something like this again, it
>> would be preferable to commit a script that does the auto-conversion
>> (maybe even with some patch files for manual changes) both for ease of
>> reviewing and to avoid the stop-the-world situation we're in now. (I'm
>> still worried that some changes will get lost in the shuffle.)

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Pablo Estrada]

I believe the troublesome tasks are these three:
https://github.com/apache/beam/blob/2592c8396ae1a68dadc351135c2a79397fb70942/website/build.gradle#L95-L108
(to avoid confusion, note that these are being added as part of the PR,
although they appear in a commit on apache/beam in the link).

Nam, can you change the gradle tasks to avoid using -u root in docker?


On Wed, May 6, 2020 at 1:24 PM Brian Hulette  wrote:

> I added some detail about the failures in the PR [1]. It seems for some
> reason this PR is causing those directories (node_modules and themes) to be
> created with root ownership. All subsequent runs of those jobs on the same
> worker (for other PRs as well) try to clean up the old workspace, and they
> fail with permissions errors. It looks like maybe +Udi Meiri
>  debugged something similar recently in [2]?
>
> [1] https://github.com/apache/beam/pull/11554#issuecomment-624346035
> [2] https://issues.apache.org/jira/browse/BEAM-9737
>
> On Wed, May 6, 2020 at 1:01 PM Aizhamal Nurmamat kyzy 
> wrote:
>
>> Hi all,
>>
>> Nam and Brian have been working together on blog post names and
>> the decision was to keep them as they are for now, because Hugo doesn’t
>> fully support the feature that was mentioned earlier [1]. Also I believe
>> this can be done after merging the PR.
>>
>> 1) Currently, the main blocker for merging is Staging Test Failures.
>> Michal showed Nam how to handle the 1st test which was about Apache License
>> missing.
>>
>> However, the 2nd and 3rd tests looked like some kind of permissions error
>> on the Jenkins worker, not to be configured by code. For more details based
>> on Jenkin logs, the 2nd test failed because of website/www/site/themes and
>> the 3rd test failed because of website/www/node_modules, they are both
>> auto-generated files on build. Can someone help Nam to look into this?
>>
>> RAT ("Run RAT PreCommit") — FAILURE
>> Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
>> Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
>>
>> 2) Are there any other blockers for merging? @Ahmet/Robert/others please
>> share if there are any other blockers.
>>
>>
>> [1] https://github.com/gohugoio/hugo/pull/4494
>>
>>
>> On Wed, May 6, 2020 at 10:19 AM Robert Bradshaw 
>> wrote:
>>
>>> On Mon, May 4, 2020 at 7:07 PM Ahmet Altay  wrote:
>>> >
>>> >> On Mon, May 4, 2020 at 6:30 PM Robert Bradshaw 
>>> wrote:
>>> >>>
>>> >>> I took the massive commit and split it up into:
>>> >>>
>>> >>> (1) Infrastructure changes (basically everything outside of
>>> >>> (website/www/site/content)
>>> >>> (2) Sed script changes, and
>>> >>> (3) Manual changes (everything not in (1) and (2)).
>>> >
>>> >
>>> > Thank you Robert. This makes it much easier. What is the source of the
>>> sed script? I am not sure why some of those lines are there. It would be
>>> much easier for us to comment on the script source if it is reviewable
>>> somewhere.
>>>
>>> I just gathered up common patterns as I was trying to go through and
>>> review the files... Mostly it was an exercise in finding a compact
>>> representation for the delta, not trying to be a perfect conversion.
>>> (I do think in retrospect, if we do something like this again, it
>>> would be preferable to commit a script that does the auto-conversion
>>> (maybe even with some patch files for manual changes) both for ease of
>>> reviewing and to avoid the stop-the-world situation we're in now. (I'm
>>> still worried that some changes will get lost in the shuffle.)
>>>
>>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Brian Hulette]

I added some detail about the failures in the PR [1]. It seems for some
reason this PR is causing those directories (node_modules and themes) to be
created with root ownership. All subsequent runs of those jobs on the same
worker (for other PRs as well) try to clean up the old workspace, and they
fail with permissions errors. It looks like maybe +Udi Meiri
 debugged something similar recently in [2]?

[1] https://github.com/apache/beam/pull/11554#issuecomment-624346035
[2] https://issues.apache.org/jira/browse/BEAM-9737

On Wed, May 6, 2020 at 1:01 PM Aizhamal Nurmamat kyzy 
wrote:

> Hi all,
>
> Nam and Brian have been working together on blog post names and
> the decision was to keep them as they are for now, because Hugo doesn’t
> fully support the feature that was mentioned earlier [1]. Also I believe
> this can be done after merging the PR.
>
> 1) Currently, the main blocker for merging is Staging Test Failures.
> Michal showed Nam how to handle the 1st test which was about Apache License
> missing.
>
> However, the 2nd and 3rd tests looked like some kind of permissions error
> on the Jenkins worker, not to be configured by code. For more details based
> on Jenkin logs, the 2nd test failed because of website/www/site/themes and
> the 3rd test failed because of website/www/node_modules, they are both
> auto-generated files on build. Can someone help Nam to look into this?
>
> RAT ("Run RAT PreCommit") — FAILURE
> Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
> Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
>
> 2) Are there any other blockers for merging? @Ahmet/Robert/others please
> share if there are any other blockers.
>
>
> [1] https://github.com/gohugoio/hugo/pull/4494
>
>
> On Wed, May 6, 2020 at 10:19 AM Robert Bradshaw 
> wrote:
>
>> On Mon, May 4, 2020 at 7:07 PM Ahmet Altay  wrote:
>> >
>> >> On Mon, May 4, 2020 at 6:30 PM Robert Bradshaw 
>> wrote:
>> >>>
>> >>> I took the massive commit and split it up into:
>> >>>
>> >>> (1) Infrastructure changes (basically everything outside of
>> >>> (website/www/site/content)
>> >>> (2) Sed script changes, and
>> >>> (3) Manual changes (everything not in (1) and (2)).
>> >
>> >
>> > Thank you Robert. This makes it much easier. What is the source of the
>> sed script? I am not sure why some of those lines are there. It would be
>> much easier for us to comment on the script source if it is reviewable
>> somewhere.
>>
>> I just gathered up common patterns as I was trying to go through and
>> review the files... Mostly it was an exercise in finding a compact
>> representation for the delta, not trying to be a perfect conversion.
>> (I do think in retrospect, if we do something like this again, it
>> would be preferable to commit a script that does the auto-conversion
>> (maybe even with some patch files for manual changes) both for ease of
>> reviewing and to avoid the stop-the-world situation we're in now. (I'm
>> still worried that some changes will get lost in the shuffle.)
>>
>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Hi all,

Nam and Brian have been working together on blog post names and
the decision was to keep them as they are for now, because Hugo doesn’t
fully support the feature that was mentioned earlier [1]. Also I believe
this can be done after merging the PR.

1) Currently, the main blocker for merging is Staging Test Failures.
Michal showed Nam how to handle the 1st test which was about Apache License
missing.

However, the 2nd and 3rd tests looked like some kind of permissions error
on the Jenkins worker, not to be configured by code. For more details based
on Jenkin logs, the 2nd test failed because of website/www/site/themes and
the 3rd test failed because of website/www/node_modules, they are both
auto-generated files on build. Can someone help Nam to look into this?

RAT ("Run RAT PreCommit") — FAILURE
Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE

2) Are there any other blockers for merging? @Ahmet/Robert/others please
share if there are any other blockers.


[1] https://github.com/gohugoio/hugo/pull/4494


On Wed, May 6, 2020 at 10:19 AM Robert Bradshaw  wrote:

> On Mon, May 4, 2020 at 7:07 PM Ahmet Altay  wrote:
> >
> >> On Mon, May 4, 2020 at 6:30 PM Robert Bradshaw 
> wrote:
> >>>
> >>> I took the massive commit and split it up into:
> >>>
> >>> (1) Infrastructure changes (basically everything outside of
> >>> (website/www/site/content)
> >>> (2) Sed script changes, and
> >>> (3) Manual changes (everything not in (1) and (2)).
> >
> >
> > Thank you Robert. This makes it much easier. What is the source of the
> sed script? I am not sure why some of those lines are there. It would be
> much easier for us to comment on the script source if it is reviewable
> somewhere.
>
> I just gathered up common patterns as I was trying to go through and
> review the files... Mostly it was an exercise in finding a compact
> representation for the delta, not trying to be a perfect conversion.
> (I do think in retrospect, if we do something like this again, it
> would be preferable to commit a script that does the auto-conversion
> (maybe even with some patch files for manual changes) both for ease of
> reviewing and to avoid the stop-the-world situation we're in now. (I'm
> still worried that some changes will get lost in the shuffle.)
>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Robert Bradshaw]

On Mon, May 4, 2020 at 7:07 PM Ahmet Altay  wrote:
>
>> On Mon, May 4, 2020 at 6:30 PM Robert Bradshaw  wrote:
>>>
>>> I took the massive commit and split it up into:
>>>
>>> (1) Infrastructure changes (basically everything outside of
>>> (website/www/site/content)
>>> (2) Sed script changes, and
>>> (3) Manual changes (everything not in (1) and (2)).
>
>
> Thank you Robert. This makes it much easier. What is the source of the sed 
> script? I am not sure why some of those lines are there. It would be much 
> easier for us to comment on the script source if it is reviewable somewhere.

I just gathered up common patterns as I was trying to go through and
review the files... Mostly it was an exercise in finding a compact
representation for the delta, not trying to be a perfect conversion.
(I do think in retrospect, if we do something like this again, it
would be preferable to commit a script that does the auto-conversion
(maybe even with some patch files for manual changes) both for ease of
reviewing and to avoid the stop-the-world situation we're in now. (I'm
still worried that some changes will get lost in the shuffle.)

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Ahmet Altay]

On Mon, May 4, 2020 at 6:58 PM Aizhamal Nurmamat kyzy 
wrote:

> Thanks everyone for your feedback and support with the review. Please add
> any other comments so we can address them soon, if not please share your
> LGTMs.
>
> @Robert, thanks for separating the PR!
>
> @Thomas, regarding your question "There are some changes missing though
> (for example [2]), are you planning to add more recent commits later?" -
> yes, after merging the PR we will update all of the recent changes that are
> missing.
>

If we are going to do this, could people continue editing website after
Wednesday if PR is still not merged?


>
> @Nam Bui  , can we look into using the feature from
> this PR [1] that Brian mentioned to keep dates in blog post file names?
>
> @everyone, Nam also had a question regarding staging functionality - it
> keeps showing the errors like below:
>
> RAT ("Run RAT PreCommit") — FAILURE
>

There are files without the license header. We either need to modify RAT
config or add license headers. See for example:

*13:01:08*   Printing headers for text files without a valid
license header...*13:01:08*   *13:01:08*
=*13:01:08*
== File: 
/home/jenkins/jenkins-slave/workspace/beam_PreCommit_RAT_Commit/src/website/www/site/static/js/bootstrap.min.js



> Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
>

Some links are failing with 404 errors. We need to update those urls.
Example:

*13:22:47* [=>  ] 1366
/ 1397  curl: (22) The requested URL returned error: 404 *13:22:47*
*13:22:47* 
https://www.talend.com/blog/2017/01/13/future-apache-beam-now-top-level-apache-software-foundation-project/*13:22:50*
[=>  ] 1367 / 1397
curl: (22) The requested URL returned error: 404 *13:22:50* *13:22:50*
https://www.talend.com/blog/2017/01/23/apache-beam-way-greater-data-agility/?utm_medium=socialpost_source=twitter_campaign=blog



> Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
>

Probably the same as above. Take a look at the logs, they usually have
sufficient information.


>
> The staging is working, but the jobs show up as failed. Does anyone have
> an idea what the failures are related to and how we can fix it?
>
> [1] https://github.com/gohugoio/hugo/pull/4494
>
>
>
> On Mon, May 4, 2020 at 6:30 PM Robert Bradshaw 
> wrote:
>
>> I took the massive commit and split it up into:
>>
>> (1) Infrastructure changes (basically everything outside of
>> (website/www/site/content)
>> (2) Sed script changes, and
>> (3) Manual changes (everything not in (1) and (2)).
>>
>
Thank you Robert. This makes it much easier. What is the source of the sed
script? I am not sure why some of those lines are there. It would be much
easier for us to comment on the script source if it is reviewable somewhere.


>
>> It does seem that (3) has a number of unintentional changes, some
>> stylistic (e.g. lost of removal of end-of-file newlines) and some
>> actual content that's not up to date. This cuts down the number of
>> lines to be reviewed by more than half (and, notably, the more
>> substantial ones).
>>
>> [1]
>> https://github.com/apache/beam/pull/11608/commits/1bcf519a0f041607dfa401f167164301acbca2ac
>> 72 files changed, 3546 insertions(+), 1472 deletions(-)
>> [2]
>> https://github.com/apache/beam/pull/11608/commits/8b9f488c519b97a11ca4c7e3b644bb9ffe12cb98
>> 252 files changed, 4136 insertions(+), 4684 deletions(-)
>> [3]
>> https://github.com/apache/beam/pull/11608/commits/f9d8bc13a0fda0a60a436aa56186139d0f71de4e
>> 228 files changed, 1859 insertions(+), 2370 deletions(-)
>>
>> I also separated out the compatibility matrix move, which was ~1700
>> lines.
>> https://github.com/apache/beam/pull/11608/commits/16516d036af047493445654d61940dea8d04eaaa
>>
>> On Mon, May 4, 2020 at 6:15 PM Robert Bradshaw 
>> wrote:
>> >
>> > On Mon, May 4, 2020 at 6:02 PM Thomas Weise 
>> wrote:
>> > >
>> > > I took a brief look at [1] and looks good overall.
>> > >
>> > > There are some changes missing though (for example [2]), are you
>> planning to add more recent commits later?
>> > >
>> > > Also, there was an earlier question from Brian regarding the
>> possibility to retain the post dates in blog file names. I would second
>> that, it would make the posts significantly easier to navigate.
>> >
>> > I'm OK with removing them from the URL if they're to distracting, but
>> > generally agree here. (If it's too difficult, it's not a huge issue.)
>> >
>> > > [1]
>> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/index.html
>> > > [2]
>> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/documentation/runners/flink/index.html
>> > >
>> > > Thomas
>> > >
>> > > On Mon, May 4, 2020 at 11:06 AM Hannah Jiang 
>> wrote:
>> > >>
>> > >> Hi Aizhamal,, yes, Wednesday sounds good to me. Thank you.
>> > >>
>> > >>
>> > >> On Mon, May 4, 2020 at 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Thanks everyone for your feedback and support with the review. Please add
any other comments so we can address them soon, if not please share your
LGTMs.

@Robert, thanks for separating the PR!

@Thomas, regarding your question "There are some changes missing though
(for example [2]), are you planning to add more recent commits later?" -
yes, after merging the PR we will update all of the recent changes that are
missing.

@Nam Bui  , can we look into using the feature from
this PR [1] that Brian mentioned to keep dates in blog post file names?

@everyone, Nam also had a question regarding staging functionality - it
keeps showing the errors like below:

RAT ("Run RAT PreCommit") — FAILURE
Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE
Website_Stage_GCS ("Run Website_Stage_GCS PreCommit") — FAILURE

The staging is working, but the jobs show up as failed. Does anyone have an
idea what the failures are related to and how we can fix it?

[1] https://github.com/gohugoio/hugo/pull/4494



On Mon, May 4, 2020 at 6:30 PM Robert Bradshaw  wrote:

> I took the massive commit and split it up into:
>
> (1) Infrastructure changes (basically everything outside of
> (website/www/site/content)
> (2) Sed script changes, and
> (3) Manual changes (everything not in (1) and (2)).
>
> It does seem that (3) has a number of unintentional changes, some
> stylistic (e.g. lost of removal of end-of-file newlines) and some
> actual content that's not up to date. This cuts down the number of
> lines to be reviewed by more than half (and, notably, the more
> substantial ones).
>
> [1]
> https://github.com/apache/beam/pull/11608/commits/1bcf519a0f041607dfa401f167164301acbca2ac
> 72 files changed, 3546 insertions(+), 1472 deletions(-)
> [2]
> https://github.com/apache/beam/pull/11608/commits/8b9f488c519b97a11ca4c7e3b644bb9ffe12cb98
> 252 files changed, 4136 insertions(+), 4684 deletions(-)
> [3]
> https://github.com/apache/beam/pull/11608/commits/f9d8bc13a0fda0a60a436aa56186139d0f71de4e
> 228 files changed, 1859 insertions(+), 2370 deletions(-)
>
> I also separated out the compatibility matrix move, which was ~1700
> lines.
> https://github.com/apache/beam/pull/11608/commits/16516d036af047493445654d61940dea8d04eaaa
>
> On Mon, May 4, 2020 at 6:15 PM Robert Bradshaw 
> wrote:
> >
> > On Mon, May 4, 2020 at 6:02 PM Thomas Weise 
> wrote:
> > >
> > > I took a brief look at [1] and looks good overall.
> > >
> > > There are some changes missing though (for example [2]), are you
> planning to add more recent commits later?
> > >
> > > Also, there was an earlier question from Brian regarding the
> possibility to retain the post dates in blog file names. I would second
> that, it would make the posts significantly easier to navigate.
> >
> > I'm OK with removing them from the URL if they're to distracting, but
> > generally agree here. (If it's too difficult, it's not a huge issue.)
> >
> > > [1]
> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/index.html
> > > [2]
> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/documentation/runners/flink/index.html
> > >
> > > Thomas
> > >
> > > On Mon, May 4, 2020 at 11:06 AM Hannah Jiang 
> wrote:
> > >>
> > >> Hi Aizhamal,, yes, Wednesday sounds good to me. Thank you.
> > >>
> > >>
> > >> On Mon, May 4, 2020 at 10:40 AM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
> > >>>
> > >>> Hannah,
> > >>>
> > >>> We don't have an exact date, but we are hoping to address all the
> comments and merge the PR by Wednesday. Will it be possible for you to wait
> until then?
> > >>>
> > >>> On Thu, Apr 30, 2020 at 4:29 PM Hannah Jiang 
> wrote:
> > >
> > > Since we want to move forward with the PR, I would like to ask the
> community to hold off changes to the current Beam website for a week, until
> we are able to review and merge the PR. Is this acceptable to everyone?
> > 
> >  Do we have an exact date when we can push changes to the website? I
> have PRs to update documents so would like to plan ahead.
> > 
> >  On Thu, Apr 30, 2020 at 1:17 PM Nam Bui 
> wrote:
> > >
> > > Hey guys,
> > >
> > > I tried my best to handle renamed files in Git. I have no clue why
> GitHub doesn't show it, but finally, I made this commit [1] (thanks for
> your idea @bhulette) so you guys can review changes with ease (there is no
> bunch of deleted markdown files anymore :D). Also, new staged version is
> deployed, you could check it out [2].
> > >
> > > In case you are interested in translation, here is the proof of
> concept [3] (the earth icon on the right corner is temporarily used for
> switching languages). You can take a look at the translation guide for this
> PoC [4].
> > >
> > > [1]
> https://github.com/apache/beam/pull/11554/commits/b267bb360866a723ac2536f408f23de648c7cd4d
> > > [2]
> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/index.html
> > > [3] 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Robert Bradshaw]

I took the massive commit and split it up into:

(1) Infrastructure changes (basically everything outside of
(website/www/site/content)
(2) Sed script changes, and
(3) Manual changes (everything not in (1) and (2)).

It does seem that (3) has a number of unintentional changes, some
stylistic (e.g. lost of removal of end-of-file newlines) and some
actual content that's not up to date. This cuts down the number of
lines to be reviewed by more than half (and, notably, the more
substantial ones).

[1] 
https://github.com/apache/beam/pull/11608/commits/1bcf519a0f041607dfa401f167164301acbca2ac
72 files changed, 3546 insertions(+), 1472 deletions(-)
[2] 
https://github.com/apache/beam/pull/11608/commits/8b9f488c519b97a11ca4c7e3b644bb9ffe12cb98
252 files changed, 4136 insertions(+), 4684 deletions(-)
[3] 
https://github.com/apache/beam/pull/11608/commits/f9d8bc13a0fda0a60a436aa56186139d0f71de4e
228 files changed, 1859 insertions(+), 2370 deletions(-)

I also separated out the compatibility matrix move, which was ~1700
lines. 
https://github.com/apache/beam/pull/11608/commits/16516d036af047493445654d61940dea8d04eaaa

On Mon, May 4, 2020 at 6:15 PM Robert Bradshaw  wrote:
>
> On Mon, May 4, 2020 at 6:02 PM Thomas Weise  wrote:
> >
> > I took a brief look at [1] and looks good overall.
> >
> > There are some changes missing though (for example [2]), are you planning 
> > to add more recent commits later?
> >
> > Also, there was an earlier question from Brian regarding the possibility to 
> > retain the post dates in blog file names. I would second that, it would 
> > make the posts significantly easier to navigate.
>
> I'm OK with removing them from the URL if they're to distracting, but
> generally agree here. (If it's too difficult, it's not a huge issue.)
>
> > [1] 
> > http://apache-beam-website-pull-requests.storage.googleapis.com/11554/index.html
> > [2] 
> > http://apache-beam-website-pull-requests.storage.googleapis.com/11554/documentation/runners/flink/index.html
> >
> > Thomas
> >
> > On Mon, May 4, 2020 at 11:06 AM Hannah Jiang  wrote:
> >>
> >> Hi Aizhamal,, yes, Wednesday sounds good to me. Thank you.
> >>
> >>
> >> On Mon, May 4, 2020 at 10:40 AM Aizhamal Nurmamat kyzy 
> >>  wrote:
> >>>
> >>> Hannah,
> >>>
> >>> We don't have an exact date, but we are hoping to address all the 
> >>> comments and merge the PR by Wednesday. Will it be possible for you to 
> >>> wait until then?
> >>>
> >>> On Thu, Apr 30, 2020 at 4:29 PM Hannah Jiang  
> >>> wrote:
> >
> > Since we want to move forward with the PR, I would like to ask the 
> > community to hold off changes to the current Beam website for a week, 
> > until we are able to review and merge the PR. Is this acceptable to 
> > everyone?
> 
>  Do we have an exact date when we can push changes to the website? I have 
>  PRs to update documents so would like to plan ahead.
> 
>  On Thu, Apr 30, 2020 at 1:17 PM Nam Bui  wrote:
> >
> > Hey guys,
> >
> > I tried my best to handle renamed files in Git. I have no clue why 
> > GitHub doesn't show it, but finally, I made this commit [1] (thanks for 
> > your idea @bhulette) so you guys can review changes with ease (there is 
> > no bunch of deleted markdown files anymore :D). Also, new staged 
> > version is deployed, you could check it out [2].
> >
> > In case you are interested in translation, here is the proof of concept 
> > [3] (the earth icon on the right corner is temporarily used for 
> > switching languages). You can take a look at the translation guide for 
> > this PoC [4].
> >
> > [1] 
> > https://github.com/apache/beam/pull/11554/commits/b267bb360866a723ac2536f408f23de648c7cd4d
> > [2] 
> > http://apache-beam-website-pull-requests.storage.googleapis.com/11554/index.html
> > [3] https://safe-relation.surge.sh/
> > [4] 
> > https://github.com/PolideaInternal/beam/blob/website-develop/website/CONTRIBUTE.md#translation-guide
> >
> >
> > On Thu, Apr 30, 2020 at 7:24 PM Brian Hulette  
> > wrote:
> >>
> >> Changing the URLs is fine with me as long as the old urls will work 
> >> too.
> >>
> >> But do we need to change the filenames for the blog posts to 
> >> accomplish that? It's nice that the blog post markdown files start 
> >> with a date so they naturally sort chronologically. It looks like this 
> >> hugo PR [1] made it possible to extract date metadata and slug (i.e. 
> >> dataflow-python-sdk-is-now-public) separately from the filename.
> >>
> >> [1] https://github.com/gohugoio/hugo/pull/4494
> >>
> >> On Thu, Apr 30, 2020 at 10:06 AM Ahmet Altay  wrote:
> >>>
> >>>
> >>>
> >>> On Thu, Apr 30, 2020 at 9:55 AM Thomas Weise  wrote:
> 
>  For changed URLs, will previous URLs be mapped to avoid broken 
>  external links?
> >>>
> >>>
> >>> I believe the answer is yes 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Robert Bradshaw]

On Mon, May 4, 2020 at 6:02 PM Thomas Weise  wrote:
>
> I took a brief look at [1] and looks good overall.
>
> There are some changes missing though (for example [2]), are you planning to 
> add more recent commits later?
>
> Also, there was an earlier question from Brian regarding the possibility to 
> retain the post dates in blog file names. I would second that, it would make 
> the posts significantly easier to navigate.

I'm OK with removing them from the URL if they're to distracting, but
generally agree here. (If it's too difficult, it's not a huge issue.)

> [1] 
> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/index.html
> [2] 
> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/documentation/runners/flink/index.html
>
> Thomas
>
> On Mon, May 4, 2020 at 11:06 AM Hannah Jiang  wrote:
>>
>> Hi Aizhamal,, yes, Wednesday sounds good to me. Thank you.
>>
>>
>> On Mon, May 4, 2020 at 10:40 AM Aizhamal Nurmamat kyzy  
>> wrote:
>>>
>>> Hannah,
>>>
>>> We don't have an exact date, but we are hoping to address all the comments 
>>> and merge the PR by Wednesday. Will it be possible for you to wait until 
>>> then?
>>>
>>> On Thu, Apr 30, 2020 at 4:29 PM Hannah Jiang  wrote:
>
> Since we want to move forward with the PR, I would like to ask the 
> community to hold off changes to the current Beam website for a week, 
> until we are able to review and merge the PR. Is this acceptable to 
> everyone?

 Do we have an exact date when we can push changes to the website? I have 
 PRs to update documents so would like to plan ahead.

 On Thu, Apr 30, 2020 at 1:17 PM Nam Bui  wrote:
>
> Hey guys,
>
> I tried my best to handle renamed files in Git. I have no clue why GitHub 
> doesn't show it, but finally, I made this commit [1] (thanks for your 
> idea @bhulette) so you guys can review changes with ease (there is no 
> bunch of deleted markdown files anymore :D). Also, new staged version is 
> deployed, you could check it out [2].
>
> In case you are interested in translation, here is the proof of concept 
> [3] (the earth icon on the right corner is temporarily used for switching 
> languages). You can take a look at the translation guide for this PoC [4].
>
> [1] 
> https://github.com/apache/beam/pull/11554/commits/b267bb360866a723ac2536f408f23de648c7cd4d
> [2] 
> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/index.html
> [3] https://safe-relation.surge.sh/
> [4] 
> https://github.com/PolideaInternal/beam/blob/website-develop/website/CONTRIBUTE.md#translation-guide
>
>
> On Thu, Apr 30, 2020 at 7:24 PM Brian Hulette  wrote:
>>
>> Changing the URLs is fine with me as long as the old urls will work too.
>>
>> But do we need to change the filenames for the blog posts to accomplish 
>> that? It's nice that the blog post markdown files start with a date so 
>> they naturally sort chronologically. It looks like this hugo PR [1] made 
>> it possible to extract date metadata and slug (i.e. 
>> dataflow-python-sdk-is-now-public) separately from the filename.
>>
>> [1] https://github.com/gohugoio/hugo/pull/4494
>>
>> On Thu, Apr 30, 2020 at 10:06 AM Ahmet Altay  wrote:
>>>
>>>
>>>
>>> On Thu, Apr 30, 2020 at 9:55 AM Thomas Weise  wrote:

 For changed URLs, will previous URLs be mapped to avoid broken 
 external links?
>>>
>>>
>>> I believe the answer is yes from Nam's response "For now, we keep the 
>>> old URLs working in terms of redirecting them". I very much agree that 
>>> this is very important and should work for all existing urls.
>>>



 On Thu, Apr 30, 2020 at 9:34 AM Aizhamal Nurmamat kyzy 
  wrote:
>
> Hi,
>
> To give a little more context regarding the URLs, the date should 
> still appear on the blog post, but not on the URL.
> For example, we'd have:
> https://beam.apache.org/beam/python/sdk/2016/02/25/python-sdk-now-public.html
>  become 
> https://beam.apache.org/blog/dataflow-python-sdk-is-now-public/.
>>>
>>>
>>> I am not a content marketer. IMO, this is a good change. In the past, a 
>>> few times, we edited dates on posts (e.g. a release date was entered 
>>> incorrectly) and we had to either have a mismatch between dates in the 
>>> url and the date in the blog, or change the url. This change 
>>> simplifies, by having date only in place (in content metadata).
>>>
>
>
> The blog posts would have a small header showing the title, author 
> and publish date. But the URL would not have it.
> Thoughts?
>
>
> On Thu, Apr 30, 2020 at 9:23 AM Nam Bui  wrote:
>>
>> Hi,
>>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Thomas Weise]

I took a brief look at [1] and looks good overall.

There are some changes missing though (for example [2]), are you planning
to add more recent commits later?

Also, there was an earlier question from Brian regarding the possibility to
retain the post dates in blog file names. I would second that, it would
make the posts significantly easier to navigate.

[1]
http://apache-beam-website-pull-requests.storage.googleapis.com/11554/index.html
[2]
http://apache-beam-website-pull-requests.storage.googleapis.com/11554/documentation/runners/flink/index.html

Thomas

On Mon, May 4, 2020 at 11:06 AM Hannah Jiang  wrote:

> Hi Aizhamal,, yes, Wednesday sounds good to me. Thank you.
>
>
> On Mon, May 4, 2020 at 10:40 AM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
>
>> Hannah,
>>
>> We don't have an exact date, but we are hoping to address all the
>> comments and merge the PR by Wednesday. Will it be possible for you to wait
>> until then?
>>
>> On Thu, Apr 30, 2020 at 4:29 PM Hannah Jiang 
>> wrote:
>>
>>> Since we want to move forward with the PR, I would like to ask the
 community to hold off changes to the current Beam website for a week, until
 we are able to review and merge the PR. Is this acceptable to everyone?
>>>
>>> Do we have an exact date when we can push changes to the website? I have
>>> PRs to update documents so would like to plan ahead.
>>>
>>> On Thu, Apr 30, 2020 at 1:17 PM Nam Bui  wrote:
>>>
 Hey guys,

 I tried my best to handle renamed files in Git. I have no clue why
 GitHub doesn't show it, but finally, I made this commit [1] (thanks for
 your idea @bhulette) so you guys can review changes with ease (there is no
 bunch of deleted markdown files anymore :D). Also, new staged version is
 deployed, you could check it out [2].

 In case you are interested in translation, here is the proof of concept
 [3] (the earth icon on the right corner is temporarily used for switching
 languages). You can take a look at the translation guide for this PoC [4].

 [1]
 https://github.com/apache/beam/pull/11554/commits/b267bb360866a723ac2536f408f23de648c7cd4d
 [2]
 http://apache-beam-website-pull-requests.storage.googleapis.com/11554/index.html
 [3] https://safe-relation.surge.sh/
 [4]
 https://github.com/PolideaInternal/beam/blob/website-develop/website/CONTRIBUTE.md#translation-guide


 On Thu, Apr 30, 2020 at 7:24 PM Brian Hulette 
 wrote:

> Changing the URLs is fine with me as long as the old urls will work
> too.
>
> But do we need to change the filenames for the blog posts to
> accomplish that? It's nice that the blog post markdown files start with a
> date so they naturally sort chronologically. It looks like this hugo PR 
> [1]
> made it possible to extract date metadata and slug
> (i.e. dataflow-python-sdk-is-now-public) separately from the filename.
>
> [1] https://github.com/gohugoio/hugo/pull/4494
>
> On Thu, Apr 30, 2020 at 10:06 AM Ahmet Altay  wrote:
>
>>
>>
>> On Thu, Apr 30, 2020 at 9:55 AM Thomas Weise  wrote:
>>
>>> For changed URLs, will previous URLs be mapped to avoid broken
>>> external links?
>>>
>>
>> I believe the answer is yes from Nam's response "For now, we keep the
>> old URLs working in terms of redirecting them". I very much agree that 
>> this
>> is very important and should work for all existing urls.
>>
>>
>>>
>>>
>>> On Thu, Apr 30, 2020 at 9:34 AM Aizhamal Nurmamat kyzy <
>>> aizha...@apache.org> wrote:
>>>
 Hi,

 To give a little more context regarding the URLs, the date should
 still appear on the blog post, but not on the URL.
 For example, we'd have:

 https://beam.apache.org/beam/python/sdk/2016/02/25/python-sdk-now-public.html
 become
 https://beam.apache.org/blog/dataflow-python-sdk-is-now-public/.

>>>
>> I am not a content marketer. IMO, this is a good change. In the past,
>> a few times, we edited dates on posts (e.g. a release date was entered
>> incorrectly) and we had to either have a mismatch between dates in the 
>> url
>> and the date in the blog, or change the url. This change simplifies, by
>> having date only in place (in content metadata).
>>
>>
>>>
 The blog posts would have a small header showing the title, author
 and publish date. But the URL would not have it.
 Thoughts?


 On Thu, Apr 30, 2020 at 9:23 AM Nam Bui 
 wrote:

> Hi,
>
> @altay: Hey hey. Yeah, I didn't expect the baseUrl of staging
> version is "
> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/;
> which also includes "/11554", and Hugo considers it as a path so it 
> breaks
> 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Hannah Jiang]

Hi Aizhamal,, yes, Wednesday sounds good to me. Thank you.


On Mon, May 4, 2020 at 10:40 AM Aizhamal Nurmamat kyzy 
wrote:

> Hannah,
>
> We don't have an exact date, but we are hoping to address all the comments
> and merge the PR by Wednesday. Will it be possible for you to wait until
> then?
>
> On Thu, Apr 30, 2020 at 4:29 PM Hannah Jiang 
> wrote:
>
>> Since we want to move forward with the PR, I would like to ask the
>>> community to hold off changes to the current Beam website for a week, until
>>> we are able to review and merge the PR. Is this acceptable to everyone?
>>
>> Do we have an exact date when we can push changes to the website? I have
>> PRs to update documents so would like to plan ahead.
>>
>> On Thu, Apr 30, 2020 at 1:17 PM Nam Bui  wrote:
>>
>>> Hey guys,
>>>
>>> I tried my best to handle renamed files in Git. I have no clue why
>>> GitHub doesn't show it, but finally, I made this commit [1] (thanks for
>>> your idea @bhulette) so you guys can review changes with ease (there is no
>>> bunch of deleted markdown files anymore :D). Also, new staged version is
>>> deployed, you could check it out [2].
>>>
>>> In case you are interested in translation, here is the proof of concept
>>> [3] (the earth icon on the right corner is temporarily used for switching
>>> languages). You can take a look at the translation guide for this PoC [4].
>>>
>>> [1]
>>> https://github.com/apache/beam/pull/11554/commits/b267bb360866a723ac2536f408f23de648c7cd4d
>>> [2]
>>> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/index.html
>>> [3] https://safe-relation.surge.sh/
>>> [4]
>>> https://github.com/PolideaInternal/beam/blob/website-develop/website/CONTRIBUTE.md#translation-guide
>>>
>>>
>>> On Thu, Apr 30, 2020 at 7:24 PM Brian Hulette 
>>> wrote:
>>>
 Changing the URLs is fine with me as long as the old urls will work too.

 But do we need to change the filenames for the blog posts to accomplish
 that? It's nice that the blog post markdown files start with a date so they
 naturally sort chronologically. It looks like this hugo PR [1] made it
 possible to extract date metadata and slug
 (i.e. dataflow-python-sdk-is-now-public) separately from the filename.

 [1] https://github.com/gohugoio/hugo/pull/4494

 On Thu, Apr 30, 2020 at 10:06 AM Ahmet Altay  wrote:

>
>
> On Thu, Apr 30, 2020 at 9:55 AM Thomas Weise  wrote:
>
>> For changed URLs, will previous URLs be mapped to avoid broken
>> external links?
>>
>
> I believe the answer is yes from Nam's response "For now, we keep the
> old URLs working in terms of redirecting them". I very much agree that 
> this
> is very important and should work for all existing urls.
>
>
>>
>>
>> On Thu, Apr 30, 2020 at 9:34 AM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>>
>>> Hi,
>>>
>>> To give a little more context regarding the URLs, the date should
>>> still appear on the blog post, but not on the URL.
>>> For example, we'd have:
>>>
>>> https://beam.apache.org/beam/python/sdk/2016/02/25/python-sdk-now-public.html
>>> become
>>> https://beam.apache.org/blog/dataflow-python-sdk-is-now-public/.
>>>
>>
> I am not a content marketer. IMO, this is a good change. In the past,
> a few times, we edited dates on posts (e.g. a release date was entered
> incorrectly) and we had to either have a mismatch between dates in the url
> and the date in the blog, or change the url. This change simplifies, by
> having date only in place (in content metadata).
>
>
>>
>>> The blog posts would have a small header showing the title, author
>>> and publish date. But the URL would not have it.
>>> Thoughts?
>>>
>>>
>>> On Thu, Apr 30, 2020 at 9:23 AM Nam Bui  wrote:
>>>
 Hi,

 @altay: Hey hey. Yeah, I didn't expect the baseUrl of staging
 version is "
 http://apache-beam-website-pull-requests.storage.googleapis.com/11554/;
 which also includes "/11554", and Hugo considers it as a path so it 
 breaks
 the path of "static files" (like images). We made a fix. Now I'm 
 working on
 "getting git to recognize files as renames" as you suggested.

 @robert: The dates are nice but it causes verbose/long/ugly URLs.
 We discussed with Aizhamal in the development stage and agreed to get 
 rid
 of this. For now, we keep the old URLs working in terms of redirecting
 them. However, from now on, we should change the name convention on 
 blog
 posts to have a fancy URL like "beam.apache.org/blog/myblogpost.md".
 :)



 On Thu, Apr 30, 2020 at 2:57 AM Robert Bradshaw <
 rober...@google.com> wrote:

> On Wed, Apr 29, 2020 at 5:08 PM Ahmet Altay 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Hannah,

We don't have an exact date, but we are hoping to address all the comments
and merge the PR by Wednesday. Will it be possible for you to wait until
then?

On Thu, Apr 30, 2020 at 4:29 PM Hannah Jiang  wrote:

> Since we want to move forward with the PR, I would like to ask the
>> community to hold off changes to the current Beam website for a week, until
>> we are able to review and merge the PR. Is this acceptable to everyone?
>
> Do we have an exact date when we can push changes to the website? I have
> PRs to update documents so would like to plan ahead.
>
> On Thu, Apr 30, 2020 at 1:17 PM Nam Bui  wrote:
>
>> Hey guys,
>>
>> I tried my best to handle renamed files in Git. I have no clue why GitHub
>> doesn't show it, but finally, I made this commit [1] (thanks for your
>> idea @bhulette) so you guys can review changes with ease (there is no bunch
>> of deleted markdown files anymore :D). Also, new staged version is
>> deployed, you could check it out [2].
>>
>> In case you are interested in translation, here is the proof of concept
>> [3] (the earth icon on the right corner is temporarily used for switching
>> languages). You can take a look at the translation guide for this PoC [4].
>>
>> [1]
>> https://github.com/apache/beam/pull/11554/commits/b267bb360866a723ac2536f408f23de648c7cd4d
>> [2]
>> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/index.html
>> [3] https://safe-relation.surge.sh/
>> [4]
>> https://github.com/PolideaInternal/beam/blob/website-develop/website/CONTRIBUTE.md#translation-guide
>>
>>
>> On Thu, Apr 30, 2020 at 7:24 PM Brian Hulette 
>> wrote:
>>
>>> Changing the URLs is fine with me as long as the old urls will work too.
>>>
>>> But do we need to change the filenames for the blog posts to accomplish
>>> that? It's nice that the blog post markdown files start with a date so they
>>> naturally sort chronologically. It looks like this hugo PR [1] made it
>>> possible to extract date metadata and slug
>>> (i.e. dataflow-python-sdk-is-now-public) separately from the filename.
>>>
>>> [1] https://github.com/gohugoio/hugo/pull/4494
>>>
>>> On Thu, Apr 30, 2020 at 10:06 AM Ahmet Altay  wrote:
>>>


 On Thu, Apr 30, 2020 at 9:55 AM Thomas Weise  wrote:

> For changed URLs, will previous URLs be mapped to avoid broken
> external links?
>

 I believe the answer is yes from Nam's response "For now, we keep the
 old URLs working in terms of redirecting them". I very much agree that this
 is very important and should work for all existing urls.


>
>
> On Thu, Apr 30, 2020 at 9:34 AM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
>
>> Hi,
>>
>> To give a little more context regarding the URLs, the date should
>> still appear on the blog post, but not on the URL.
>> For example, we'd have:
>>
>> https://beam.apache.org/beam/python/sdk/2016/02/25/python-sdk-now-public.html
>> become
>> https://beam.apache.org/blog/dataflow-python-sdk-is-now-public/.
>>
>
 I am not a content marketer. IMO, this is a good change. In the past, a
 few times, we edited dates on posts (e.g. a release date was entered
 incorrectly) and we had to either have a mismatch between dates in the url
 and the date in the blog, or change the url. This change simplifies, by
 having date only in place (in content metadata).


>
>> The blog posts would have a small header showing the title, author
>> and publish date. But the URL would not have it.
>> Thoughts?
>>
>>
>> On Thu, Apr 30, 2020 at 9:23 AM Nam Bui  wrote:
>>
>>> Hi,
>>>
>>> @altay: Hey hey. Yeah, I didn't expect the baseUrl of staging
>>> version is "
>>> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/;
>>> which also includes "/11554", and Hugo considers it as a path so it 
>>> breaks
>>> the path of "static files" (like images). We made a fix. Now I'm 
>>> working on
>>> "getting git to recognize files as renames" as you suggested.
>>>
>>> @robert: The dates are nice but it causes verbose/long/ugly URLs. We
>>> discussed with Aizhamal in the development stage and agreed to get rid 
>>> of
>>> this. For now, we keep the old URLs working in terms of redirecting 
>>> them.
>>> However, from now on, we should change the name convention on blog 
>>> posts to
>>> have a fancy URL like "beam.apache.org/blog/myblogpost.md". :)
>>>
>>>
>>>
>>> On Thu, Apr 30, 2020 at 2:57 AM Robert Bradshaw 
>>> wrote:
>>>
 On Wed, Apr 29, 2020 at 5:08 PM Ahmet Altay 
 wrote:

> Nam, this looks better. At least links are working, and the
> website visually looks similar and generally in good shape. I think 
> there
> are still issues. For example, I do not see any of the images (e.g. 
> the

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Nam Bui]

Hey Kenn. Thanks so much for your useful information and research. It's
great to know.

On Mon, May 4, 2020 at 6:33 PM Kenneth Knowles  wrote:

> Regarding the detection of renames, I now recall that I have encountered
> this before: it is controlled by the config diff.renameLimit. The default
> value these days is high enough to work for this PR. I've confirmed this:
>
> git diff --shortstat $(git merge-base github/pr/11554 github/master)
> github/pr/11554
>  631 files changed, 10360 insertions(+), 9938 deletions(-)
>
> (in case the commits change, that is: git diff --shortstat
> 763b7ccd17a420eb634d6799adcd3ecfcf33d6a7
> 0162c9db3e7faf0d0e243c580ffa5ca5f497db98)
>
> But the GitHub UI does not match this. I believe the reason it works for
> the individual commit and fails for the overall PR is that it is calculated
> as part of displaying the end-to-end diff. Since it is n^2 perhaps GitHub
> sets it lower. Git doesn't store anything about any of this, but always
> computes it on the fly (by design, so that improvements apply to old git
> repos automatically).
>
> Other relevant flags are `git diff --find-copies` which finds copied files
> if the original was modified in the commit and `git diff
> --find-copies-harder` which finds copied files from anywhere in the repo.
> These could support a copy --> modify new --> delete old workflow, but I
> doubt any such workflow would preserve `git blame` in the GitHub UI. (you
> can still use these flags with git blame offline to get better blame
> accuracy)
>
> Kenn
>
> On Mon, May 4, 2020 at 1:21 AM Nam Bui  wrote:
>
>> Hey guys,
>>
>> How was your weekend? Thanks for some of the compliments and also
>> recommendations.
>>
>> About the commits, as Brian said, we worked together on the-asf slack. It
>> was the tough one, we even did a few experiments. And finally came up with
>> a solution that preserved all commits and used `git mv`.
>> IMHO, I know it's really difficult to review all of them at first, even
>> though we made a commit [1] which helps you to compare changes since there
>> are tons of files. Therefore, I recommend to check out my work, take a look
>> at Hugo structure and you will link it to Jekyll one quickly. There are no
>> chances about file or directory names, just organize the structure. I write
>> a short details here, hope it would be helpful in terms of reviewing.
>>
>> 1. Syntax
>> - I strongly prefer this one [2]. He wrote about Hugo syntax which is
>> corresponding to Jekyll syntax. It would make sense to your overview,
>> instead of skimming one by one markdown file.
>>
>> 2. Project structure
>> - The main part of Hugo is in "website/www/site". You will briefly
>> confused a little bit here with many directories, so please read this one
>> [3] first, then you'll get into it very quickly. The most important thing
>> here is the flow. In Jekyll, you write a markdown file and then pick the
>> layout with "layout: home" in frontmatter as an example. In Hugo, we have
>> separated "content" and "layouts" directory, the "layouts" will mimic the
>> structure of the "content", and at the end, Hugo will know how to connect
>> each of them behind the scene.
>> - In Jekyll, the components are in "website/src/_include" and it will be
>> moved to "website/src/layouts/partials" in Hugo.
>>
>> 3. Shortcodes.
>> - Just thinking "shortcodes" as utility functions and we will reuse it
>> many times in markdown files. One of the unique features from Hugo, and
>> it's located at "website/www/layouts/shortcodes".
>>
>> A quick Q:
>> @Altay: there are some deleted files if you see them in [1]. Some of them
>> have the different behaviour in Hugo. For instance,
>> "_data/capabilitymatrix.md" will be used directly in
>> frontmatter "website/www/site/content/en/blog/capability-matrix.md", the
>> reason is, it will take more works in Hugo to retrieve data from files and
>> pass them into "shortcodes" in markdown files (other data files are not
>> deleted because they are used in "layouts" HTML files).
>> @Robert: thanks for your review and comments on GitHub. I will walk
>> through all of them today.
>>
>> Best regards,
>> Nam
>>
>>
>> [1]
>> https://github.com/apache/beam/pull/11554/commits/b267bb360866a723ac2536f408f23de648c7cd4d
>> [2] https://simpleit.rocks/golang/hugo/migrating-a-jekyll-blog-to-hugo/
>> [3] https://gohugo.io/getting-started/directory-structure/
>>
>> On Fri, May 1, 2020 at 6:24 PM Brian Hulette  wrote:
>>
>>> Regarding move detection: I worked with Nam on this some on the-asf
>>> slack. We couldn't make squashing into a single large commit work - when I
>>> did it, `git log` still showed many dropped and added files. Breaking out a
>>> single commit with the file moves was the best we could manage. I tested a
>>> PR that used this approach on a single file and the github UI did pick up
>>> on it [1]. Sadly it seems to give up on the larger PR.
>>>
>>> I figured this was good enough though, it's difficult to review all of
>>> the 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Kenneth Knowles]

Regarding the detection of renames, I now recall that I have encountered
this before: it is controlled by the config diff.renameLimit. The default
value these days is high enough to work for this PR. I've confirmed this:

git diff --shortstat $(git merge-base github/pr/11554 github/master)
github/pr/11554
 631 files changed, 10360 insertions(+), 9938 deletions(-)

(in case the commits change, that is: git diff --shortstat
763b7ccd17a420eb634d6799adcd3ecfcf33d6a7
0162c9db3e7faf0d0e243c580ffa5ca5f497db98)

But the GitHub UI does not match this. I believe the reason it works for
the individual commit and fails for the overall PR is that it is calculated
as part of displaying the end-to-end diff. Since it is n^2 perhaps GitHub
sets it lower. Git doesn't store anything about any of this, but always
computes it on the fly (by design, so that improvements apply to old git
repos automatically).

Other relevant flags are `git diff --find-copies` which finds copied files
if the original was modified in the commit and `git diff
--find-copies-harder` which finds copied files from anywhere in the repo.
These could support a copy --> modify new --> delete old workflow, but I
doubt any such workflow would preserve `git blame` in the GitHub UI. (you
can still use these flags with git blame offline to get better blame
accuracy)

Kenn

On Mon, May 4, 2020 at 1:21 AM Nam Bui  wrote:

> Hey guys,
>
> How was your weekend? Thanks for some of the compliments and also
> recommendations.
>
> About the commits, as Brian said, we worked together on the-asf slack. It
> was the tough one, we even did a few experiments. And finally came up with
> a solution that preserved all commits and used `git mv`.
> IMHO, I know it's really difficult to review all of them at first, even
> though we made a commit [1] which helps you to compare changes since there
> are tons of files. Therefore, I recommend to check out my work, take a look
> at Hugo structure and you will link it to Jekyll one quickly. There are no
> chances about file or directory names, just organize the structure. I write
> a short details here, hope it would be helpful in terms of reviewing.
>
> 1. Syntax
> - I strongly prefer this one [2]. He wrote about Hugo syntax which is
> corresponding to Jekyll syntax. It would make sense to your overview,
> instead of skimming one by one markdown file.
>
> 2. Project structure
> - The main part of Hugo is in "website/www/site". You will briefly
> confused a little bit here with many directories, so please read this one
> [3] first, then you'll get into it very quickly. The most important thing
> here is the flow. In Jekyll, you write a markdown file and then pick the
> layout with "layout: home" in frontmatter as an example. In Hugo, we have
> separated "content" and "layouts" directory, the "layouts" will mimic the
> structure of the "content", and at the end, Hugo will know how to connect
> each of them behind the scene.
> - In Jekyll, the components are in "website/src/_include" and it will be
> moved to "website/src/layouts/partials" in Hugo.
>
> 3. Shortcodes.
> - Just thinking "shortcodes" as utility functions and we will reuse it
> many times in markdown files. One of the unique features from Hugo, and
> it's located at "website/www/layouts/shortcodes".
>
> A quick Q:
> @Altay: there are some deleted files if you see them in [1]. Some of them
> have the different behaviour in Hugo. For instance,
> "_data/capabilitymatrix.md" will be used directly in
> frontmatter "website/www/site/content/en/blog/capability-matrix.md", the
> reason is, it will take more works in Hugo to retrieve data from files and
> pass them into "shortcodes" in markdown files (other data files are not
> deleted because they are used in "layouts" HTML files).
> @Robert: thanks for your review and comments on GitHub. I will walk
> through all of them today.
>
> Best regards,
> Nam
>
>
> [1]
> https://github.com/apache/beam/pull/11554/commits/b267bb360866a723ac2536f408f23de648c7cd4d
> [2] https://simpleit.rocks/golang/hugo/migrating-a-jekyll-blog-to-hugo/
> [3] https://gohugo.io/getting-started/directory-structure/
>
> On Fri, May 1, 2020 at 6:24 PM Brian Hulette  wrote:
>
>> Regarding move detection: I worked with Nam on this some on the-asf
>> slack. We couldn't make squashing into a single large commit work - when I
>> did it, `git log` still showed many dropped and added files. Breaking out a
>> single commit with the file moves was the best we could manage. I tested a
>> PR that used this approach on a single file and the github UI did pick up
>> on it [1]. Sadly it seems to give up on the larger PR.
>>
>> I figured this was good enough though, it's difficult to review all of
>> the changes at once, but you can at least review the individual commits
>> without being obfuscated by the moves.
>>
>> [1] https://github.com/apache/beam/pull/11579
>>
>>
>> On Fri, May 1, 2020 at 9:11 AM Robert Bradshaw 
>> wrote:
>>
>>> I just took a look, and added a 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Nam Bui]

Hey guys,

How was your weekend? Thanks for some of the compliments and also
recommendations.

About the commits, as Brian said, we worked together on the-asf slack. It
was the tough one, we even did a few experiments. And finally came up with
a solution that preserved all commits and used `git mv`.
IMHO, I know it's really difficult to review all of them at first, even
though we made a commit [1] which helps you to compare changes since there
are tons of files. Therefore, I recommend to check out my work, take a look
at Hugo structure and you will link it to Jekyll one quickly. There are no
chances about file or directory names, just organize the structure. I write
a short details here, hope it would be helpful in terms of reviewing.

1. Syntax
- I strongly prefer this one [2]. He wrote about Hugo syntax which is
corresponding to Jekyll syntax. It would make sense to your overview,
instead of skimming one by one markdown file.

2. Project structure
- The main part of Hugo is in "website/www/site". You will briefly confused
a little bit here with many directories, so please read this one [3] first,
then you'll get into it very quickly. The most important thing here is the
flow. In Jekyll, you write a markdown file and then pick the layout with
"layout: home" in frontmatter as an example. In Hugo, we have separated
"content" and "layouts" directory, the "layouts" will mimic the structure
of the "content", and at the end, Hugo will know how to connect each of
them behind the scene.
- In Jekyll, the components are in "website/src/_include" and it will be
moved to "website/src/layouts/partials" in Hugo.

3. Shortcodes.
- Just thinking "shortcodes" as utility functions and we will reuse it many
times in markdown files. One of the unique features from Hugo, and it's
located at "website/www/layouts/shortcodes".

A quick Q:
@Altay: there are some deleted files if you see them in [1]. Some of them
have the different behaviour in Hugo. For instance,
"_data/capabilitymatrix.md" will be used directly in
frontmatter "website/www/site/content/en/blog/capability-matrix.md", the
reason is, it will take more works in Hugo to retrieve data from files and
pass them into "shortcodes" in markdown files (other data files are not
deleted because they are used in "layouts" HTML files).
@Robert: thanks for your review and comments on GitHub. I will walk through
all of them today.

Best regards,
Nam


[1]
https://github.com/apache/beam/pull/11554/commits/b267bb360866a723ac2536f408f23de648c7cd4d
[2] https://simpleit.rocks/golang/hugo/migrating-a-jekyll-blog-to-hugo/
[3] https://gohugo.io/getting-started/directory-structure/

On Fri, May 1, 2020 at 6:24 PM Brian Hulette  wrote:

> Regarding move detection: I worked with Nam on this some on the-asf slack.
> We couldn't make squashing into a single large commit work - when I did it,
> `git log` still showed many dropped and added files. Breaking out a single
> commit with the file moves was the best we could manage. I tested a PR that
> used this approach on a single file and the github UI did pick up on it
> [1]. Sadly it seems to give up on the larger PR.
>
> I figured this was good enough though, it's difficult to review all of the
> changes at once, but you can at least review the individual commits without
> being obfuscated by the moves.
>
> [1] https://github.com/apache/beam/pull/11579
>
>
> On Fri, May 1, 2020 at 9:11 AM Robert Bradshaw 
> wrote:
>
>> I just took a look, and added a couple of comments, but it mostly looks
>> good. Thanks for creating a commit that preserves changes; that's a big
>> improvement.
>>
>> +1 to Ahmet's suggestion about braking the huge commit up a bit more. I
>> would suggest one that adds the mechanics (etc.), one that applies a script
>> to auto-convert the content (where we can review the script and that it's
>> application give the resulting diff), and a final one that takes care of
>> the things that the script wasn't able to handle (or messed up, rather than
>> spending a huge amount of time getting the script perfect).
>>
>> On Fri, May 1, 2020 at 6:44 AM Kenneth Knowles  wrote:
>>
>>> I believe taking Brian and Robert's advice to help git detect moves
>>> (even more than you already have) will make this much more manageable. I
>>> just tried it out and squashing commits brings it to "631 files changed,
>>> 10363 insertions(+), 9945 deletions(-)" according to git, so that is more
>>> manageable than +47k - 47k. I'm not saying that a total squash is best.
>>> There may be a better way to factor the changes.
>>>
>>> Kenn
>>>
>>> On Thu, Apr 30, 2020 at 8:09 PM Ahmet Altay  wrote:
>>>
 Nam,

  - Website looks good and looks the same as the current website.
 (Visually comparing a few pages, not a deep analysis.)
 - contribute.md looks good. (this is new content.)
 - website/Dockerfile and website/README.md changes look good.
 - I do not know what is the new version of some files, for example:
 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Brian Hulette]

Regarding move detection: I worked with Nam on this some on the-asf slack.
We couldn't make squashing into a single large commit work - when I did it,
`git log` still showed many dropped and added files. Breaking out a single
commit with the file moves was the best we could manage. I tested a PR that
used this approach on a single file and the github UI did pick up on it
[1]. Sadly it seems to give up on the larger PR.

I figured this was good enough though, it's difficult to review all of the
changes at once, but you can at least review the individual commits without
being obfuscated by the moves.

[1] https://github.com/apache/beam/pull/11579


On Fri, May 1, 2020 at 9:11 AM Robert Bradshaw  wrote:

> I just took a look, and added a couple of comments, but it mostly looks
> good. Thanks for creating a commit that preserves changes; that's a big
> improvement.
>
> +1 to Ahmet's suggestion about braking the huge commit up a bit more. I
> would suggest one that adds the mechanics (etc.), one that applies a script
> to auto-convert the content (where we can review the script and that it's
> application give the resulting diff), and a final one that takes care of
> the things that the script wasn't able to handle (or messed up, rather than
> spending a huge amount of time getting the script perfect).
>
> On Fri, May 1, 2020 at 6:44 AM Kenneth Knowles  wrote:
>
>> I believe taking Brian and Robert's advice to help git detect moves (even
>> more than you already have) will make this much more manageable. I just
>> tried it out and squashing commits brings it to "631 files changed, 10363
>> insertions(+), 9945 deletions(-)" according to git, so that is more
>> manageable than +47k - 47k. I'm not saying that a total squash is best.
>> There may be a better way to factor the changes.
>>
>> Kenn
>>
>> On Thu, Apr 30, 2020 at 8:09 PM Ahmet Altay  wrote:
>>
>>> Nam,
>>>
>>>  - Website looks good and looks the same as the current website.
>>> (Visually comparing a few pages, not a deep analysis.)
>>> - contribute.md looks good. (this is new content.)
>>> - website/Dockerfile and website/README.md changes look good.
>>> - I do not know what is the new version of some files, for example:
>>> website/src/_data/authors.yml,  website/src/_data/capability-matrix.yml --
>>> what replaces them?
>>>
>>> There are 887 file changes. It is not easy to review this. I wanted to
>>> go commit by commit, but that did not help much. How about we try to
>>> organize this review as reviewable commits.
>>> - Changes to the mechanics (jekyll to hugo), themes, build files,
>>> website related readmes etc. This will likely be a smaller change in number
>>> of files. (This will likely have many completed new, and completely deleted
>>> files. Only a few files have meaningful diffs.)
>>> - Changes to the content. This might be a large number of files with
>>> minimal changes. I do not think we can manually review each file, but at
>>> least a quick review of minimal changes to each file would be good enough.
>>>
>>> What do you think?
>>>
>>> Ahmet
>>>
>>> On Thu, Apr 30, 2020 at 4:29 PM Hannah Jiang 
>>> wrote:
>>>
 Since we want to move forward with the PR, I would like to ask the
> community to hold off changes to the current Beam website for a week, 
> until
> we are able to review and merge the PR. Is this acceptable to everyone?

 Do we have an exact date when we can push changes to the website? I
 have PRs to update documents so would like to plan ahead.

 On Thu, Apr 30, 2020 at 1:17 PM Nam Bui  wrote:

> Hey guys,
>
> I tried my best to handle renamed files in Git. I have no clue why
> GitHub doesn't show it, but finally, I made this commit [1] (thanks for
> your idea @bhulette) so you guys can review changes with ease (there is no
> bunch of deleted markdown files anymore :D). Also, new staged version is
> deployed, you could check it out [2].
>
> In case you are interested in translation, here is the proof of
> concept [3] (the earth icon on the right corner is temporarily used for
> switching languages). You can take a look at the translation guide for 
> this
> PoC [4].
>
> [1]
> https://github.com/apache/beam/pull/11554/commits/b267bb360866a723ac2536f408f23de648c7cd4d
> [2]
> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/index.html
> [3] https://safe-relation.surge.sh/
> [4]
> https://github.com/PolideaInternal/beam/blob/website-develop/website/CONTRIBUTE.md#translation-guide
>
>
> On Thu, Apr 30, 2020 at 7:24 PM Brian Hulette 
> wrote:
>
>> Changing the URLs is fine with me as long as the old urls will work
>> too.
>>
>> But do we need to change the filenames for the blog posts to
>> accomplish that? It's nice that the blog post markdown files start with a
>> date so they naturally sort chronologically. It looks like this hugo PR 
>> 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Robert Bradshaw]

I just took a look, and added a couple of comments, but it mostly looks
good. Thanks for creating a commit that preserves changes; that's a big
improvement.

+1 to Ahmet's suggestion about braking the huge commit up a bit more. I
would suggest one that adds the mechanics (etc.), one that applies a script
to auto-convert the content (where we can review the script and that it's
application give the resulting diff), and a final one that takes care of
the things that the script wasn't able to handle (or messed up, rather than
spending a huge amount of time getting the script perfect).

On Fri, May 1, 2020 at 6:44 AM Kenneth Knowles  wrote:

> I believe taking Brian and Robert's advice to help git detect moves (even
> more than you already have) will make this much more manageable. I just
> tried it out and squashing commits brings it to "631 files changed, 10363
> insertions(+), 9945 deletions(-)" according to git, so that is more
> manageable than +47k - 47k. I'm not saying that a total squash is best.
> There may be a better way to factor the changes.
>
> Kenn
>
> On Thu, Apr 30, 2020 at 8:09 PM Ahmet Altay  wrote:
>
>> Nam,
>>
>>  - Website looks good and looks the same as the current website.
>> (Visually comparing a few pages, not a deep analysis.)
>> - contribute.md looks good. (this is new content.)
>> - website/Dockerfile and website/README.md changes look good.
>> - I do not know what is the new version of some files, for example:
>> website/src/_data/authors.yml,  website/src/_data/capability-matrix.yml --
>> what replaces them?
>>
>> There are 887 file changes. It is not easy to review this. I wanted to go
>> commit by commit, but that did not help much. How about we try to organize
>> this review as reviewable commits.
>> - Changes to the mechanics (jekyll to hugo), themes, build files, website
>> related readmes etc. This will likely be a smaller change in number of
>> files. (This will likely have many completed new, and completely deleted
>> files. Only a few files have meaningful diffs.)
>> - Changes to the content. This might be a large number of files with
>> minimal changes. I do not think we can manually review each file, but at
>> least a quick review of minimal changes to each file would be good enough.
>>
>> What do you think?
>>
>> Ahmet
>>
>> On Thu, Apr 30, 2020 at 4:29 PM Hannah Jiang 
>> wrote:
>>
>>> Since we want to move forward with the PR, I would like to ask the
 community to hold off changes to the current Beam website for a week, until
 we are able to review and merge the PR. Is this acceptable to everyone?
>>>
>>> Do we have an exact date when we can push changes to the website? I have
>>> PRs to update documents so would like to plan ahead.
>>>
>>> On Thu, Apr 30, 2020 at 1:17 PM Nam Bui  wrote:
>>>
 Hey guys,

 I tried my best to handle renamed files in Git. I have no clue why
 GitHub doesn't show it, but finally, I made this commit [1] (thanks for
 your idea @bhulette) so you guys can review changes with ease (there is no
 bunch of deleted markdown files anymore :D). Also, new staged version is
 deployed, you could check it out [2].

 In case you are interested in translation, here is the proof of concept
 [3] (the earth icon on the right corner is temporarily used for switching
 languages). You can take a look at the translation guide for this PoC [4].

 [1]
 https://github.com/apache/beam/pull/11554/commits/b267bb360866a723ac2536f408f23de648c7cd4d
 [2]
 http://apache-beam-website-pull-requests.storage.googleapis.com/11554/index.html
 [3] https://safe-relation.surge.sh/
 [4]
 https://github.com/PolideaInternal/beam/blob/website-develop/website/CONTRIBUTE.md#translation-guide


 On Thu, Apr 30, 2020 at 7:24 PM Brian Hulette 
 wrote:

> Changing the URLs is fine with me as long as the old urls will work
> too.
>
> But do we need to change the filenames for the blog posts to
> accomplish that? It's nice that the blog post markdown files start with a
> date so they naturally sort chronologically. It looks like this hugo PR 
> [1]
> made it possible to extract date metadata and slug
> (i.e. dataflow-python-sdk-is-now-public) separately from the filename.
>
> [1] https://github.com/gohugoio/hugo/pull/4494
>
> On Thu, Apr 30, 2020 at 10:06 AM Ahmet Altay  wrote:
>
>>
>>
>> On Thu, Apr 30, 2020 at 9:55 AM Thomas Weise  wrote:
>>
>>> For changed URLs, will previous URLs be mapped to avoid broken
>>> external links?
>>>
>>
>> I believe the answer is yes from Nam's response "For now, we keep the
>> old URLs working in terms of redirecting them". I very much agree that 
>> this
>> is very important and should work for all existing urls.
>>
>>
>>>
>>>
>>> On Thu, Apr 30, 2020 at 9:34 AM Aizhamal Nurmamat kyzy <
>>> aizha...@apache.org> wrote:
>>>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Kenneth Knowles]

I believe taking Brian and Robert's advice to help git detect moves (even
more than you already have) will make this much more manageable. I just
tried it out and squashing commits brings it to "631 files changed, 10363
insertions(+), 9945 deletions(-)" according to git, so that is more
manageable than +47k - 47k. I'm not saying that a total squash is best.
There may be a better way to factor the changes.

Kenn

On Thu, Apr 30, 2020 at 8:09 PM Ahmet Altay  wrote:

> Nam,
>
>  - Website looks good and looks the same as the current website. (Visually
> comparing a few pages, not a deep analysis.)
> - contribute.md looks good. (this is new content.)
> - website/Dockerfile and website/README.md changes look good.
> - I do not know what is the new version of some files, for example:
> website/src/_data/authors.yml,  website/src/_data/capability-matrix.yml --
> what replaces them?
>
> There are 887 file changes. It is not easy to review this. I wanted to go
> commit by commit, but that did not help much. How about we try to organize
> this review as reviewable commits.
> - Changes to the mechanics (jekyll to hugo), themes, build files, website
> related readmes etc. This will likely be a smaller change in number of
> files. (This will likely have many completed new, and completely deleted
> files. Only a few files have meaningful diffs.)
> - Changes to the content. This might be a large number of files with
> minimal changes. I do not think we can manually review each file, but at
> least a quick review of minimal changes to each file would be good enough.
>
> What do you think?
>
> Ahmet
>
> On Thu, Apr 30, 2020 at 4:29 PM Hannah Jiang 
> wrote:
>
>> Since we want to move forward with the PR, I would like to ask the
>>> community to hold off changes to the current Beam website for a week, until
>>> we are able to review and merge the PR. Is this acceptable to everyone?
>>
>> Do we have an exact date when we can push changes to the website? I have
>> PRs to update documents so would like to plan ahead.
>>
>> On Thu, Apr 30, 2020 at 1:17 PM Nam Bui  wrote:
>>
>>> Hey guys,
>>>
>>> I tried my best to handle renamed files in Git. I have no clue why
>>> GitHub doesn't show it, but finally, I made this commit [1] (thanks for
>>> your idea @bhulette) so you guys can review changes with ease (there is no
>>> bunch of deleted markdown files anymore :D). Also, new staged version is
>>> deployed, you could check it out [2].
>>>
>>> In case you are interested in translation, here is the proof of concept
>>> [3] (the earth icon on the right corner is temporarily used for switching
>>> languages). You can take a look at the translation guide for this PoC [4].
>>>
>>> [1]
>>> https://github.com/apache/beam/pull/11554/commits/b267bb360866a723ac2536f408f23de648c7cd4d
>>> [2]
>>> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/index.html
>>> [3] https://safe-relation.surge.sh/
>>> [4]
>>> https://github.com/PolideaInternal/beam/blob/website-develop/website/CONTRIBUTE.md#translation-guide
>>>
>>>
>>> On Thu, Apr 30, 2020 at 7:24 PM Brian Hulette 
>>> wrote:
>>>
 Changing the URLs is fine with me as long as the old urls will work too.

 But do we need to change the filenames for the blog posts to accomplish
 that? It's nice that the blog post markdown files start with a date so they
 naturally sort chronologically. It looks like this hugo PR [1] made it
 possible to extract date metadata and slug
 (i.e. dataflow-python-sdk-is-now-public) separately from the filename.

 [1] https://github.com/gohugoio/hugo/pull/4494

 On Thu, Apr 30, 2020 at 10:06 AM Ahmet Altay  wrote:

>
>
> On Thu, Apr 30, 2020 at 9:55 AM Thomas Weise  wrote:
>
>> For changed URLs, will previous URLs be mapped to avoid broken
>> external links?
>>
>
> I believe the answer is yes from Nam's response "For now, we keep the
> old URLs working in terms of redirecting them". I very much agree that 
> this
> is very important and should work for all existing urls.
>
>
>>
>>
>> On Thu, Apr 30, 2020 at 9:34 AM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>>
>>> Hi,
>>>
>>> To give a little more context regarding the URLs, the date should
>>> still appear on the blog post, but not on the URL.
>>> For example, we'd have:
>>>
>>> https://beam.apache.org/beam/python/sdk/2016/02/25/python-sdk-now-public.html
>>> become
>>> https://beam.apache.org/blog/dataflow-python-sdk-is-now-public/.
>>>
>>
> I am not a content marketer. IMO, this is a good change. In the past,
> a few times, we edited dates on posts (e.g. a release date was entered
> incorrectly) and we had to either have a mismatch between dates in the url
> and the date in the blog, or change the url. This change simplifies, by
> having date only in place (in content metadata).
>
>
>>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Ahmet Altay]

Nam,

 - Website looks good and looks the same as the current website. (Visually
comparing a few pages, not a deep analysis.)
- contribute.md looks good. (this is new content.)
- website/Dockerfile and website/README.md changes look good.
- I do not know what is the new version of some files, for example:
website/src/_data/authors.yml,  website/src/_data/capability-matrix.yml --
what replaces them?

There are 887 file changes. It is not easy to review this. I wanted to go
commit by commit, but that did not help much. How about we try to organize
this review as reviewable commits.
- Changes to the mechanics (jekyll to hugo), themes, build files, website
related readmes etc. This will likely be a smaller change in number of
files. (This will likely have many completed new, and completely deleted
files. Only a few files have meaningful diffs.)
- Changes to the content. This might be a large number of files with
minimal changes. I do not think we can manually review each file, but at
least a quick review of minimal changes to each file would be good enough.

What do you think?

Ahmet

On Thu, Apr 30, 2020 at 4:29 PM Hannah Jiang  wrote:

> Since we want to move forward with the PR, I would like to ask the
>> community to hold off changes to the current Beam website for a week, until
>> we are able to review and merge the PR. Is this acceptable to everyone?
>
> Do we have an exact date when we can push changes to the website? I have
> PRs to update documents so would like to plan ahead.
>
> On Thu, Apr 30, 2020 at 1:17 PM Nam Bui  wrote:
>
>> Hey guys,
>>
>> I tried my best to handle renamed files in Git. I have no clue why GitHub
>> doesn't show it, but finally, I made this commit [1] (thanks for your
>> idea @bhulette) so you guys can review changes with ease (there is no bunch
>> of deleted markdown files anymore :D). Also, new staged version is
>> deployed, you could check it out [2].
>>
>> In case you are interested in translation, here is the proof of concept
>> [3] (the earth icon on the right corner is temporarily used for switching
>> languages). You can take a look at the translation guide for this PoC [4].
>>
>> [1]
>> https://github.com/apache/beam/pull/11554/commits/b267bb360866a723ac2536f408f23de648c7cd4d
>> [2]
>> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/index.html
>> [3] https://safe-relation.surge.sh/
>> [4]
>> https://github.com/PolideaInternal/beam/blob/website-develop/website/CONTRIBUTE.md#translation-guide
>>
>>
>> On Thu, Apr 30, 2020 at 7:24 PM Brian Hulette 
>> wrote:
>>
>>> Changing the URLs is fine with me as long as the old urls will work too.
>>>
>>> But do we need to change the filenames for the blog posts to accomplish
>>> that? It's nice that the blog post markdown files start with a date so they
>>> naturally sort chronologically. It looks like this hugo PR [1] made it
>>> possible to extract date metadata and slug
>>> (i.e. dataflow-python-sdk-is-now-public) separately from the filename.
>>>
>>> [1] https://github.com/gohugoio/hugo/pull/4494
>>>
>>> On Thu, Apr 30, 2020 at 10:06 AM Ahmet Altay  wrote:
>>>


 On Thu, Apr 30, 2020 at 9:55 AM Thomas Weise  wrote:

> For changed URLs, will previous URLs be mapped to avoid broken
> external links?
>

 I believe the answer is yes from Nam's response "For now, we keep the
 old URLs working in terms of redirecting them". I very much agree that this
 is very important and should work for all existing urls.


>
>
> On Thu, Apr 30, 2020 at 9:34 AM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
>
>> Hi,
>>
>> To give a little more context regarding the URLs, the date should
>> still appear on the blog post, but not on the URL.
>> For example, we'd have:
>>
>> https://beam.apache.org/beam/python/sdk/2016/02/25/python-sdk-now-public.html
>> become
>> https://beam.apache.org/blog/dataflow-python-sdk-is-now-public/.
>>
>
 I am not a content marketer. IMO, this is a good change. In the past, a
 few times, we edited dates on posts (e.g. a release date was entered
 incorrectly) and we had to either have a mismatch between dates in the url
 and the date in the blog, or change the url. This change simplifies, by
 having date only in place (in content metadata).


>
>> The blog posts would have a small header showing the title, author
>> and publish date. But the URL would not have it.
>> Thoughts?
>>
>>
>> On Thu, Apr 30, 2020 at 9:23 AM Nam Bui  wrote:
>>
>>> Hi,
>>>
>>> @altay: Hey hey. Yeah, I didn't expect the baseUrl of staging
>>> version is "
>>> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/;
>>> which also includes "/11554", and Hugo considers it as a path so it 
>>> breaks
>>> the path of "static files" (like images). We made a fix. Now I'm 
>>> working on
>>> 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Hannah Jiang]

>
> Since we want to move forward with the PR, I would like to ask the
> community to hold off changes to the current Beam website for a week, until
> we are able to review and merge the PR. Is this acceptable to everyone?

Do we have an exact date when we can push changes to the website? I have
PRs to update documents so would like to plan ahead.

On Thu, Apr 30, 2020 at 1:17 PM Nam Bui  wrote:

> Hey guys,
>
> I tried my best to handle renamed files in Git. I have no clue why GitHub
> doesn't show it, but finally, I made this commit [1] (thanks for your
> idea @bhulette) so you guys can review changes with ease (there is no bunch
> of deleted markdown files anymore :D). Also, new staged version is
> deployed, you could check it out [2].
>
> In case you are interested in translation, here is the proof of concept
> [3] (the earth icon on the right corner is temporarily used for switching
> languages). You can take a look at the translation guide for this PoC [4].
>
> [1]
> https://github.com/apache/beam/pull/11554/commits/b267bb360866a723ac2536f408f23de648c7cd4d
> [2]
> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/index.html
> [3] https://safe-relation.surge.sh/
> [4]
> https://github.com/PolideaInternal/beam/blob/website-develop/website/CONTRIBUTE.md#translation-guide
>
>
> On Thu, Apr 30, 2020 at 7:24 PM Brian Hulette  wrote:
>
>> Changing the URLs is fine with me as long as the old urls will work too.
>>
>> But do we need to change the filenames for the blog posts to accomplish
>> that? It's nice that the blog post markdown files start with a date so they
>> naturally sort chronologically. It looks like this hugo PR [1] made it
>> possible to extract date metadata and slug
>> (i.e. dataflow-python-sdk-is-now-public) separately from the filename.
>>
>> [1] https://github.com/gohugoio/hugo/pull/4494
>>
>> On Thu, Apr 30, 2020 at 10:06 AM Ahmet Altay  wrote:
>>
>>>
>>>
>>> On Thu, Apr 30, 2020 at 9:55 AM Thomas Weise  wrote:
>>>
 For changed URLs, will previous URLs be mapped to avoid broken external
 links?

>>>
>>> I believe the answer is yes from Nam's response "For now, we keep the
>>> old URLs working in terms of redirecting them". I very much agree that this
>>> is very important and should work for all existing urls.
>>>
>>>


 On Thu, Apr 30, 2020 at 9:34 AM Aizhamal Nurmamat kyzy <
 aizha...@apache.org> wrote:

> Hi,
>
> To give a little more context regarding the URLs, the date should
> still appear on the blog post, but not on the URL.
> For example, we'd have:
>
> https://beam.apache.org/beam/python/sdk/2016/02/25/python-sdk-now-public.html
> become https://beam.apache.org/blog/dataflow-python-sdk-is-now-public/
> .
>

>>> I am not a content marketer. IMO, this is a good change. In the past, a
>>> few times, we edited dates on posts (e.g. a release date was entered
>>> incorrectly) and we had to either have a mismatch between dates in the url
>>> and the date in the blog, or change the url. This change simplifies, by
>>> having date only in place (in content metadata).
>>>
>>>

> The blog posts would have a small header showing the title, author and
> publish date. But the URL would not have it.
> Thoughts?
>
>
> On Thu, Apr 30, 2020 at 9:23 AM Nam Bui  wrote:
>
>> Hi,
>>
>> @altay: Hey hey. Yeah, I didn't expect the baseUrl of staging version
>> is "
>> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/;
>> which also includes "/11554", and Hugo considers it as a path so it 
>> breaks
>> the path of "static files" (like images). We made a fix. Now I'm working 
>> on
>> "getting git to recognize files as renames" as you suggested.
>>
>> @robert: The dates are nice but it causes verbose/long/ugly URLs. We
>> discussed with Aizhamal in the development stage and agreed to get rid of
>> this. For now, we keep the old URLs working in terms of redirecting them.
>> However, from now on, we should change the name convention on blog posts 
>> to
>> have a fancy URL like "beam.apache.org/blog/myblogpost.md". :)
>>
>>
>>
>> On Thu, Apr 30, 2020 at 2:57 AM Robert Bradshaw 
>> wrote:
>>
>>> On Wed, Apr 29, 2020 at 5:08 PM Ahmet Altay 
>>> wrote:
>>>
 Nam, this looks better. At least links are working, and the website
 visually looks similar and generally in good shape. I think there are 
 still
 issues. For example, I do not see any of the images (e.g. the beam 
 logo on
 top left is missing.)

 On Wed, Apr 29, 2020 at 3:11 PM Brian Hulette 
 wrote:

> I left a comment on the PR [1]. I think the reason all of the
> website content is not being tracked as file renames is because there 
> was a
> series of commits that created files in the new 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Nam Bui]

Hey guys,

I tried my best to handle renamed files in Git. I have no clue why GitHub
doesn't show it, but finally, I made this commit [1] (thanks for your
idea @bhulette) so you guys can review changes with ease (there is no bunch
of deleted markdown files anymore :D). Also, new staged version is
deployed, you could check it out [2].

In case you are interested in translation, here is the proof of concept [3]
(the earth icon on the right corner is temporarily used for switching
languages). You can take a look at the translation guide for this PoC [4].

[1]
https://github.com/apache/beam/pull/11554/commits/b267bb360866a723ac2536f408f23de648c7cd4d
[2]
http://apache-beam-website-pull-requests.storage.googleapis.com/11554/index.html
[3] https://safe-relation.surge.sh/
[4]
https://github.com/PolideaInternal/beam/blob/website-develop/website/CONTRIBUTE.md#translation-guide


On Thu, Apr 30, 2020 at 7:24 PM Brian Hulette  wrote:

> Changing the URLs is fine with me as long as the old urls will work too.
>
> But do we need to change the filenames for the blog posts to accomplish
> that? It's nice that the blog post markdown files start with a date so they
> naturally sort chronologically. It looks like this hugo PR [1] made it
> possible to extract date metadata and slug
> (i.e. dataflow-python-sdk-is-now-public) separately from the filename.
>
> [1] https://github.com/gohugoio/hugo/pull/4494
>
> On Thu, Apr 30, 2020 at 10:06 AM Ahmet Altay  wrote:
>
>>
>>
>> On Thu, Apr 30, 2020 at 9:55 AM Thomas Weise  wrote:
>>
>>> For changed URLs, will previous URLs be mapped to avoid broken external
>>> links?
>>>
>>
>> I believe the answer is yes from Nam's response "For now, we keep the old
>> URLs working in terms of redirecting them". I very much agree that this is
>> very important and should work for all existing urls.
>>
>>
>>>
>>>
>>> On Thu, Apr 30, 2020 at 9:34 AM Aizhamal Nurmamat kyzy <
>>> aizha...@apache.org> wrote:
>>>
 Hi,

 To give a little more context regarding the URLs, the date should still
 appear on the blog post, but not on the URL.
 For example, we'd have:

 https://beam.apache.org/beam/python/sdk/2016/02/25/python-sdk-now-public.html
 become https://beam.apache.org/blog/dataflow-python-sdk-is-now-public/.

>>>
>> I am not a content marketer. IMO, this is a good change. In the past, a
>> few times, we edited dates on posts (e.g. a release date was entered
>> incorrectly) and we had to either have a mismatch between dates in the url
>> and the date in the blog, or change the url. This change simplifies, by
>> having date only in place (in content metadata).
>>
>>
>>>
 The blog posts would have a small header showing the title, author and
 publish date. But the URL would not have it.
 Thoughts?


 On Thu, Apr 30, 2020 at 9:23 AM Nam Bui  wrote:

> Hi,
>
> @altay: Hey hey. Yeah, I didn't expect the baseUrl of staging version
> is "
> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/;
> which also includes "/11554", and Hugo considers it as a path so it breaks
> the path of "static files" (like images). We made a fix. Now I'm working 
> on
> "getting git to recognize files as renames" as you suggested.
>
> @robert: The dates are nice but it causes verbose/long/ugly URLs. We
> discussed with Aizhamal in the development stage and agreed to get rid of
> this. For now, we keep the old URLs working in terms of redirecting them.
> However, from now on, we should change the name convention on blog posts 
> to
> have a fancy URL like "beam.apache.org/blog/myblogpost.md". :)
>
>
>
> On Thu, Apr 30, 2020 at 2:57 AM Robert Bradshaw 
> wrote:
>
>> On Wed, Apr 29, 2020 at 5:08 PM Ahmet Altay  wrote:
>>
>>> Nam, this looks better. At least links are working, and the website
>>> visually looks similar and generally in good shape. I think there are 
>>> still
>>> issues. For example, I do not see any of the images (e.g. the beam logo 
>>> on
>>> top left is missing.)
>>>
>>> On Wed, Apr 29, 2020 at 3:11 PM Brian Hulette 
>>> wrote:
>>>
 I left a comment on the PR [1]. I think the reason all of the
 website content is not being tracked as file renames is because there 
 was a
 series of commits that created files in the new directory, and then one
 commit that deleted the old directory. If there were a single commit 
 with
 all of the deleted and new files, git would surely recognize they are
 effectively renameds and mark them as such. Maybe we just need to get 
 all
 these commits squashed into one?

 [1]
 https://github.com/apache/beam/pull/11554#issuecomment-621489844

>>>
>>> Nam, could you try this? If we can get git to recognize these as
>>> renames, review process would be 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Brian Hulette]

Changing the URLs is fine with me as long as the old urls will work too.

But do we need to change the filenames for the blog posts to accomplish
that? It's nice that the blog post markdown files start with a date so they
naturally sort chronologically. It looks like this hugo PR [1] made it
possible to extract date metadata and slug
(i.e. dataflow-python-sdk-is-now-public) separately from the filename.

[1] https://github.com/gohugoio/hugo/pull/4494

On Thu, Apr 30, 2020 at 10:06 AM Ahmet Altay  wrote:

>
>
> On Thu, Apr 30, 2020 at 9:55 AM Thomas Weise  wrote:
>
>> For changed URLs, will previous URLs be mapped to avoid broken external
>> links?
>>
>
> I believe the answer is yes from Nam's response "For now, we keep the old
> URLs working in terms of redirecting them". I very much agree that this is
> very important and should work for all existing urls.
>
>
>>
>>
>> On Thu, Apr 30, 2020 at 9:34 AM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>>
>>> Hi,
>>>
>>> To give a little more context regarding the URLs, the date should still
>>> appear on the blog post, but not on the URL.
>>> For example, we'd have:
>>>
>>> https://beam.apache.org/beam/python/sdk/2016/02/25/python-sdk-now-public.html
>>> become https://beam.apache.org/blog/dataflow-python-sdk-is-now-public/.
>>>
>>
> I am not a content marketer. IMO, this is a good change. In the past, a
> few times, we edited dates on posts (e.g. a release date was entered
> incorrectly) and we had to either have a mismatch between dates in the url
> and the date in the blog, or change the url. This change simplifies, by
> having date only in place (in content metadata).
>
>
>>
>>> The blog posts would have a small header showing the title, author and
>>> publish date. But the URL would not have it.
>>> Thoughts?
>>>
>>>
>>> On Thu, Apr 30, 2020 at 9:23 AM Nam Bui  wrote:
>>>
 Hi,

 @altay: Hey hey. Yeah, I didn't expect the baseUrl of staging version
 is "
 http://apache-beam-website-pull-requests.storage.googleapis.com/11554/;
 which also includes "/11554", and Hugo considers it as a path so it breaks
 the path of "static files" (like images). We made a fix. Now I'm working on
 "getting git to recognize files as renames" as you suggested.

 @robert: The dates are nice but it causes verbose/long/ugly URLs. We
 discussed with Aizhamal in the development stage and agreed to get rid of
 this. For now, we keep the old URLs working in terms of redirecting them.
 However, from now on, we should change the name convention on blog posts to
 have a fancy URL like "beam.apache.org/blog/myblogpost.md". :)



 On Thu, Apr 30, 2020 at 2:57 AM Robert Bradshaw 
 wrote:

> On Wed, Apr 29, 2020 at 5:08 PM Ahmet Altay  wrote:
>
>> Nam, this looks better. At least links are working, and the website
>> visually looks similar and generally in good shape. I think there are 
>> still
>> issues. For example, I do not see any of the images (e.g. the beam logo 
>> on
>> top left is missing.)
>>
>> On Wed, Apr 29, 2020 at 3:11 PM Brian Hulette 
>> wrote:
>>
>>> I left a comment on the PR [1]. I think the reason all of the
>>> website content is not being tracked as file renames is because there 
>>> was a
>>> series of commits that created files in the new directory, and then one
>>> commit that deleted the old directory. If there were a single commit 
>>> with
>>> all of the deleted and new files, git would surely recognize they are
>>> effectively renameds and mark them as such. Maybe we just need to get 
>>> all
>>> these commits squashed into one?
>>>
>>> [1] https://github.com/apache/beam/pull/11554#issuecomment-621489844
>>>
>>
>> Nam, could you try this? If we can get git to recognize these as
>> renames, review process would be much easier.
>>
>
> +1.
>
> Alternatively, create a commit that just moves the files into a new
> location (which git can always detect), then sit the edits on top of that
> (which should preserve history better).
>
> Also, is there a reason the dates were removed from the blog post
> filenames? For content like that, the dates are nice.
>
>
>>
>>
>>>
>>> On Wed, Apr 29, 2020 at 10:39 AM Nam Bui 
>>> wrote:
>>>
 Hi guys,

 I'm Nam - from the responsible team of Apache Beam website
 migration. I am pleased to answer some of the questions here.

 @aizhamal: Thanks for informing to the community. :)
 @altay, @robertwb: Yes. there is a problem with the staged version
 at the moment. We didn't expect some behaviours on the build process. 
 So,
 we fixed it today and been waiting for @pablo to re-run it again. The
 purpose of this PR is to migrate completely Beam site from Jekyll to 
 Hugo.

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Ahmet Altay]

On Thu, Apr 30, 2020 at 9:55 AM Thomas Weise  wrote:

> For changed URLs, will previous URLs be mapped to avoid broken external
> links?
>

I believe the answer is yes from Nam's response "For now, we keep the old
URLs working in terms of redirecting them". I very much agree that this is
very important and should work for all existing urls.


>
>
> On Thu, Apr 30, 2020 at 9:34 AM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
>
>> Hi,
>>
>> To give a little more context regarding the URLs, the date should still
>> appear on the blog post, but not on the URL.
>> For example, we'd have:
>>
>> https://beam.apache.org/beam/python/sdk/2016/02/25/python-sdk-now-public.html
>> become https://beam.apache.org/blog/dataflow-python-sdk-is-now-public/.
>>
>
I am not a content marketer. IMO, this is a good change. In the past, a few
times, we edited dates on posts (e.g. a release date was entered
incorrectly) and we had to either have a mismatch between dates in the url
and the date in the blog, or change the url. This change simplifies, by
having date only in place (in content metadata).


>
>> The blog posts would have a small header showing the title, author and
>> publish date. But the URL would not have it.
>> Thoughts?
>>
>>
>> On Thu, Apr 30, 2020 at 9:23 AM Nam Bui  wrote:
>>
>>> Hi,
>>>
>>> @altay: Hey hey. Yeah, I didn't expect the baseUrl of staging version is
>>> "http://apache-beam-website-pull-requests.storage.googleapis.com/11554/;
>>> which also includes "/11554", and Hugo considers it as a path so it breaks
>>> the path of "static files" (like images). We made a fix. Now I'm working on
>>> "getting git to recognize files as renames" as you suggested.
>>>
>>> @robert: The dates are nice but it causes verbose/long/ugly URLs. We
>>> discussed with Aizhamal in the development stage and agreed to get rid of
>>> this. For now, we keep the old URLs working in terms of redirecting them.
>>> However, from now on, we should change the name convention on blog posts to
>>> have a fancy URL like "beam.apache.org/blog/myblogpost.md". :)
>>>
>>>
>>>
>>> On Thu, Apr 30, 2020 at 2:57 AM Robert Bradshaw 
>>> wrote:
>>>
 On Wed, Apr 29, 2020 at 5:08 PM Ahmet Altay  wrote:

> Nam, this looks better. At least links are working, and the website
> visually looks similar and generally in good shape. I think there are 
> still
> issues. For example, I do not see any of the images (e.g. the beam logo on
> top left is missing.)
>
> On Wed, Apr 29, 2020 at 3:11 PM Brian Hulette 
> wrote:
>
>> I left a comment on the PR [1]. I think the reason all of the website
>> content is not being tracked as file renames is because there was a 
>> series
>> of commits that created files in the new directory, and then one commit
>> that deleted the old directory. If there were a single commit with all of
>> the deleted and new files, git would surely recognize they are 
>> effectively
>> renameds and mark them as such. Maybe we just need to get all these 
>> commits
>> squashed into one?
>>
>> [1] https://github.com/apache/beam/pull/11554#issuecomment-621489844
>>
>
> Nam, could you try this? If we can get git to recognize these as
> renames, review process would be much easier.
>

 +1.

 Alternatively, create a commit that just moves the files into a new
 location (which git can always detect), then sit the edits on top of that
 (which should preserve history better).

 Also, is there a reason the dates were removed from the blog post
 filenames? For content like that, the dates are nice.


>
>
>>
>> On Wed, Apr 29, 2020 at 10:39 AM Nam Bui  wrote:
>>
>>> Hi guys,
>>>
>>> I'm Nam - from the responsible team of Apache Beam website
>>> migration. I am pleased to answer some of the questions here.
>>>
>>> @aizhamal: Thanks for informing to the community. :)
>>> @altay, @robertwb: Yes. there is a problem with the staged version
>>> at the moment. We didn't expect some behaviours on the build process. 
>>> So,
>>> we fixed it today and been waiting for @pablo to re-run it again. The
>>> purpose of this PR is to migrate completely Beam site from Jekyll to 
>>> Hugo.
>>> Therefore, a bunch of deleted markdown files are from Jekyll which was
>>> located at `beam/website/src`, and Hugo is located at `beam/website/www`
>>> now. In `beam/website/README.md`, I wrote down about running the Hugo
>>> website locally, although it is actually same as Jekyll (because it's 
>>> also
>>> set up with Docker & Gradle). In `beam/website/CONTRIBUTE.md`, I guided
>>> people on how to get started with Hugo on the Beam website. There is 
>>> also a
>>> link in the "Translation Guide" section which points to a branch of
>>> multilingual provenance, and it will become a next PR soon.
>>>
>>> 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Thomas Weise]

For changed URLs, will previous URLs be mapped to avoid broken external
links?


On Thu, Apr 30, 2020 at 9:34 AM Aizhamal Nurmamat kyzy 
wrote:

> Hi,
>
> To give a little more context regarding the URLs, the date should still
> appear on the blog post, but not on the URL.
> For example, we'd have:
>
> https://beam.apache.org/beam/python/sdk/2016/02/25/python-sdk-now-public.html
> become https://beam.apache.org/blog/dataflow-python-sdk-is-now-public/.
>
> The blog posts would have a small header showing the title, author and
> publish date. But the URL would not have it.
> Thoughts?
>
>
> On Thu, Apr 30, 2020 at 9:23 AM Nam Bui  wrote:
>
>> Hi,
>>
>> @altay: Hey hey. Yeah, I didn't expect the baseUrl of staging version is "
>> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/;
>> which also includes "/11554", and Hugo considers it as a path so it breaks
>> the path of "static files" (like images). We made a fix. Now I'm working on
>> "getting git to recognize files as renames" as you suggested.
>>
>> @robert: The dates are nice but it causes verbose/long/ugly URLs. We
>> discussed with Aizhamal in the development stage and agreed to get rid of
>> this. For now, we keep the old URLs working in terms of redirecting them.
>> However, from now on, we should change the name convention on blog posts to
>> have a fancy URL like "beam.apache.org/blog/myblogpost.md". :)
>>
>>
>>
>> On Thu, Apr 30, 2020 at 2:57 AM Robert Bradshaw 
>> wrote:
>>
>>> On Wed, Apr 29, 2020 at 5:08 PM Ahmet Altay  wrote:
>>>
 Nam, this looks better. At least links are working, and the website
 visually looks similar and generally in good shape. I think there are still
 issues. For example, I do not see any of the images (e.g. the beam logo on
 top left is missing.)

 On Wed, Apr 29, 2020 at 3:11 PM Brian Hulette 
 wrote:

> I left a comment on the PR [1]. I think the reason all of the website
> content is not being tracked as file renames is because there was a series
> of commits that created files in the new directory, and then one commit
> that deleted the old directory. If there were a single commit with all of
> the deleted and new files, git would surely recognize they are effectively
> renameds and mark them as such. Maybe we just need to get all these 
> commits
> squashed into one?
>
> [1] https://github.com/apache/beam/pull/11554#issuecomment-621489844
>

 Nam, could you try this? If we can get git to recognize these as
 renames, review process would be much easier.

>>>
>>> +1.
>>>
>>> Alternatively, create a commit that just moves the files into a new
>>> location (which git can always detect), then sit the edits on top of that
>>> (which should preserve history better).
>>>
>>> Also, is there a reason the dates were removed from the blog post
>>> filenames? For content like that, the dates are nice.
>>>
>>>


>
> On Wed, Apr 29, 2020 at 10:39 AM Nam Bui  wrote:
>
>> Hi guys,
>>
>> I'm Nam - from the responsible team of Apache Beam website migration.
>> I am pleased to answer some of the questions here.
>>
>> @aizhamal: Thanks for informing to the community. :)
>> @altay, @robertwb: Yes. there is a problem with the staged version at
>> the moment. We didn't expect some behaviours on the build process. So, we
>> fixed it today and been waiting for @pablo to re-run it again. The 
>> purpose
>> of this PR is to migrate completely Beam site from Jekyll to Hugo.
>> Therefore, a bunch of deleted markdown files are from Jekyll which was
>> located at `beam/website/src`, and Hugo is located at `beam/website/www`
>> now. In `beam/website/README.md`, I wrote down about running the Hugo
>> website locally, although it is actually same as Jekyll (because it's 
>> also
>> set up with Docker & Gradle). In `beam/website/CONTRIBUTE.md`, I guided
>> people on how to get started with Hugo on the Beam website. There is 
>> also a
>> link in the "Translation Guide" section which points to a branch of
>> multilingual provenance, and it will become a next PR soon.
>>
>> Please let me know if you need more details. Feel free to ask any
>> questions and I will get back to you with answers. I'm so sorry if I 
>> answer
>> a little bit due to the timezone. :)
>>
>> Best regards,
>> Nam
>>
>>
>>
>> On Tue, Apr 28, 2020 at 8:49 PM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>>
>>> Adding +Nam Bui  and +Karolina Rosół
>>>  to follow up on questions.
>>>
>>> On Tue, Apr 28, 2020 at 11:34 AM Ahmet Altay 
>>> wrote:
>>>
 I am having trouble reviewing the staged version. What is the best
 way to review this change?

 Do we expect any changes to markdown files, beyond some metadata?

 On Tue, Apr 28, 2020 at 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Hi,

To give a little more context regarding the URLs, the date should still
appear on the blog post, but not on the URL.
For example, we'd have:
https://beam.apache.org/beam/python/sdk/2016/02/25/python-sdk-now-public.html
become https://beam.apache.org/blog/dataflow-python-sdk-is-now-public/.

The blog posts would have a small header showing the title, author and
publish date. But the URL would not have it.
Thoughts?


On Thu, Apr 30, 2020 at 9:23 AM Nam Bui  wrote:

> Hi,
>
> @altay: Hey hey. Yeah, I didn't expect the baseUrl of staging version is "
> http://apache-beam-website-pull-requests.storage.googleapis.com/11554/;
> which also includes "/11554", and Hugo considers it as a path so it breaks
> the path of "static files" (like images). We made a fix. Now I'm working on
> "getting git to recognize files as renames" as you suggested.
>
> @robert: The dates are nice but it causes verbose/long/ugly URLs. We
> discussed with Aizhamal in the development stage and agreed to get rid of
> this. For now, we keep the old URLs working in terms of redirecting them.
> However, from now on, we should change the name convention on blog posts to
> have a fancy URL like "beam.apache.org/blog/myblogpost.md". :)
>
>
>
> On Thu, Apr 30, 2020 at 2:57 AM Robert Bradshaw 
> wrote:
>
>> On Wed, Apr 29, 2020 at 5:08 PM Ahmet Altay  wrote:
>>
>>> Nam, this looks better. At least links are working, and the website
>>> visually looks similar and generally in good shape. I think there are still
>>> issues. For example, I do not see any of the images (e.g. the beam logo on
>>> top left is missing.)
>>>
>>> On Wed, Apr 29, 2020 at 3:11 PM Brian Hulette 
>>> wrote:
>>>
 I left a comment on the PR [1]. I think the reason all of the website
 content is not being tracked as file renames is because there was a series
 of commits that created files in the new directory, and then one commit
 that deleted the old directory. If there were a single commit with all of
 the deleted and new files, git would surely recognize they are effectively
 renameds and mark them as such. Maybe we just need to get all these commits
 squashed into one?

 [1] https://github.com/apache/beam/pull/11554#issuecomment-621489844

>>>
>>> Nam, could you try this? If we can get git to recognize these as
>>> renames, review process would be much easier.
>>>
>>
>> +1.
>>
>> Alternatively, create a commit that just moves the files into a new
>> location (which git can always detect), then sit the edits on top of that
>> (which should preserve history better).
>>
>> Also, is there a reason the dates were removed from the blog post
>> filenames? For content like that, the dates are nice.
>>
>>
>>>
>>>

 On Wed, Apr 29, 2020 at 10:39 AM Nam Bui  wrote:

> Hi guys,
>
> I'm Nam - from the responsible team of Apache Beam website migration.
> I am pleased to answer some of the questions here.
>
> @aizhamal: Thanks for informing to the community. :)
> @altay, @robertwb: Yes. there is a problem with the staged version at
> the moment. We didn't expect some behaviours on the build process. So, we
> fixed it today and been waiting for @pablo to re-run it again. The purpose
> of this PR is to migrate completely Beam site from Jekyll to Hugo.
> Therefore, a bunch of deleted markdown files are from Jekyll which was
> located at `beam/website/src`, and Hugo is located at `beam/website/www`
> now. In `beam/website/README.md`, I wrote down about running the Hugo
> website locally, although it is actually same as Jekyll (because it's also
> set up with Docker & Gradle). In `beam/website/CONTRIBUTE.md`, I guided
> people on how to get started with Hugo on the Beam website. There is also 
> a
> link in the "Translation Guide" section which points to a branch of
> multilingual provenance, and it will become a next PR soon.
>
> Please let me know if you need more details. Feel free to ask any
> questions and I will get back to you with answers. I'm so sorry if I 
> answer
> a little bit due to the timezone. :)
>
> Best regards,
> Nam
>
>
>
> On Tue, Apr 28, 2020 at 8:49 PM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
>
>> Adding +Nam Bui  and +Karolina Rosół
>>  to follow up on questions.
>>
>> On Tue, Apr 28, 2020 at 11:34 AM Ahmet Altay 
>> wrote:
>>
>>> I am having trouble reviewing the staged version. What is the best
>>> way to review this change?
>>>
>>> Do we expect any changes to markdown files, beyond some metadata?
>>>
>>> On Tue, Apr 28, 2020 at 10:45 AM Robert Bradshaw <
>>> rober...@google.com> wrote:
>>>
 Thanks. It'll be great to better support more languages.

 I looked at the PR and there seems to be no provenance/history.
 E.g. all the content seems to be entirely new files rather than diffs 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Nam Bui]

Hi,

@altay: Hey hey. Yeah, I didn't expect the baseUrl of staging version is "
http://apache-beam-website-pull-requests.storage.googleapis.com/11554/;
which also includes "/11554", and Hugo considers it as a path so it breaks
the path of "static files" (like images). We made a fix. Now I'm working on
"getting git to recognize files as renames" as you suggested.

@robert: The dates are nice but it causes verbose/long/ugly URLs. We
discussed with Aizhamal in the development stage and agreed to get rid of
this. For now, we keep the old URLs working in terms of redirecting them.
However, from now on, we should change the name convention on blog posts to
have a fancy URL like "beam.apache.org/blog/myblogpost.md". :)



On Thu, Apr 30, 2020 at 2:57 AM Robert Bradshaw  wrote:

> On Wed, Apr 29, 2020 at 5:08 PM Ahmet Altay  wrote:
>
>> Nam, this looks better. At least links are working, and the website
>> visually looks similar and generally in good shape. I think there are still
>> issues. For example, I do not see any of the images (e.g. the beam logo on
>> top left is missing.)
>>
>> On Wed, Apr 29, 2020 at 3:11 PM Brian Hulette 
>> wrote:
>>
>>> I left a comment on the PR [1]. I think the reason all of the website
>>> content is not being tracked as file renames is because there was a series
>>> of commits that created files in the new directory, and then one commit
>>> that deleted the old directory. If there were a single commit with all of
>>> the deleted and new files, git would surely recognize they are effectively
>>> renameds and mark them as such. Maybe we just need to get all these commits
>>> squashed into one?
>>>
>>> [1] https://github.com/apache/beam/pull/11554#issuecomment-621489844
>>>
>>
>> Nam, could you try this? If we can get git to recognize these as renames,
>> review process would be much easier.
>>
>
> +1.
>
> Alternatively, create a commit that just moves the files into a new
> location (which git can always detect), then sit the edits on top of that
> (which should preserve history better).
>
> Also, is there a reason the dates were removed from the blog post
> filenames? For content like that, the dates are nice.
>
>
>>
>>
>>>
>>> On Wed, Apr 29, 2020 at 10:39 AM Nam Bui  wrote:
>>>
 Hi guys,

 I'm Nam - from the responsible team of Apache Beam website migration. I
 am pleased to answer some of the questions here.

 @aizhamal: Thanks for informing to the community. :)
 @altay, @robertwb: Yes. there is a problem with the staged version at
 the moment. We didn't expect some behaviours on the build process. So, we
 fixed it today and been waiting for @pablo to re-run it again. The purpose
 of this PR is to migrate completely Beam site from Jekyll to Hugo.
 Therefore, a bunch of deleted markdown files are from Jekyll which was
 located at `beam/website/src`, and Hugo is located at `beam/website/www`
 now. In `beam/website/README.md`, I wrote down about running the Hugo
 website locally, although it is actually same as Jekyll (because it's also
 set up with Docker & Gradle). In `beam/website/CONTRIBUTE.md`, I guided
 people on how to get started with Hugo on the Beam website. There is also a
 link in the "Translation Guide" section which points to a branch of
 multilingual provenance, and it will become a next PR soon.

 Please let me know if you need more details. Feel free to ask any
 questions and I will get back to you with answers. I'm so sorry if I answer
 a little bit due to the timezone. :)

 Best regards,
 Nam



 On Tue, Apr 28, 2020 at 8:49 PM Aizhamal Nurmamat kyzy <
 aizha...@apache.org> wrote:

> Adding +Nam Bui  and +Karolina Rosół
>  to follow up on questions.
>
> On Tue, Apr 28, 2020 at 11:34 AM Ahmet Altay  wrote:
>
>> I am having trouble reviewing the staged version. What is the best
>> way to review this change?
>>
>> Do we expect any changes to markdown files, beyond some metadata?
>>
>> On Tue, Apr 28, 2020 at 10:45 AM Robert Bradshaw 
>> wrote:
>>
>>> Thanks. It'll be great to better support more languages.
>>>
>>> I looked at the PR and there seems to be no provenance/history. E.g.
>>> all the content seems to be entirely new files rather than diffs from 
>>> the
>>> old. (There also seems to be a huge amount of auto-generated js code as
>>> well.)
>>>
>>
>> I agree. This makes it very hard to review. I also see a bunch of
>> deleted markdown files. Are they not getting migrated?
>>
>>
>>>
>>> On Tue, Apr 28, 2020 at 10:23 AM Aizhamal Nurmamat kyzy <
>>> aizha...@apache.org> wrote:
>>>
 Hello everybody,

 We are almost done migrating the Apache Beam website from Jekyll to
 Hugo. You can see the PR in [1], and we'd love to hear your
 feedback/comments on the PR. It includes  detailed 

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Robert Bradshaw]

On Wed, Apr 29, 2020 at 5:08 PM Ahmet Altay  wrote:

> Nam, this looks better. At least links are working, and the website
> visually looks similar and generally in good shape. I think there are still
> issues. For example, I do not see any of the images (e.g. the beam logo on
> top left is missing.)
>
> On Wed, Apr 29, 2020 at 3:11 PM Brian Hulette  wrote:
>
>> I left a comment on the PR [1]. I think the reason all of the website
>> content is not being tracked as file renames is because there was a series
>> of commits that created files in the new directory, and then one commit
>> that deleted the old directory. If there were a single commit with all of
>> the deleted and new files, git would surely recognize they are effectively
>> renameds and mark them as such. Maybe we just need to get all these commits
>> squashed into one?
>>
>> [1] https://github.com/apache/beam/pull/11554#issuecomment-621489844
>>
>
> Nam, could you try this? If we can get git to recognize these as renames,
> review process would be much easier.
>

+1.

Alternatively, create a commit that just moves the files into a new
location (which git can always detect), then sit the edits on top of that
(which should preserve history better).

Also, is there a reason the dates were removed from the blog post
filenames? For content like that, the dates are nice.


>
>
>>
>> On Wed, Apr 29, 2020 at 10:39 AM Nam Bui  wrote:
>>
>>> Hi guys,
>>>
>>> I'm Nam - from the responsible team of Apache Beam website migration. I
>>> am pleased to answer some of the questions here.
>>>
>>> @aizhamal: Thanks for informing to the community. :)
>>> @altay, @robertwb: Yes. there is a problem with the staged version at
>>> the moment. We didn't expect some behaviours on the build process. So, we
>>> fixed it today and been waiting for @pablo to re-run it again. The purpose
>>> of this PR is to migrate completely Beam site from Jekyll to Hugo.
>>> Therefore, a bunch of deleted markdown files are from Jekyll which was
>>> located at `beam/website/src`, and Hugo is located at `beam/website/www`
>>> now. In `beam/website/README.md`, I wrote down about running the Hugo
>>> website locally, although it is actually same as Jekyll (because it's also
>>> set up with Docker & Gradle). In `beam/website/CONTRIBUTE.md`, I guided
>>> people on how to get started with Hugo on the Beam website. There is also a
>>> link in the "Translation Guide" section which points to a branch of
>>> multilingual provenance, and it will become a next PR soon.
>>>
>>> Please let me know if you need more details. Feel free to ask any
>>> questions and I will get back to you with answers. I'm so sorry if I answer
>>> a little bit due to the timezone. :)
>>>
>>> Best regards,
>>> Nam
>>>
>>>
>>>
>>> On Tue, Apr 28, 2020 at 8:49 PM Aizhamal Nurmamat kyzy <
>>> aizha...@apache.org> wrote:
>>>
 Adding +Nam Bui  and +Karolina Rosół
  to follow up on questions.

 On Tue, Apr 28, 2020 at 11:34 AM Ahmet Altay  wrote:

> I am having trouble reviewing the staged version. What is the best way
> to review this change?
>
> Do we expect any changes to markdown files, beyond some metadata?
>
> On Tue, Apr 28, 2020 at 10:45 AM Robert Bradshaw 
> wrote:
>
>> Thanks. It'll be great to better support more languages.
>>
>> I looked at the PR and there seems to be no provenance/history. E.g.
>> all the content seems to be entirely new files rather than diffs from the
>> old. (There also seems to be a huge amount of auto-generated js code as
>> well.)
>>
>
> I agree. This makes it very hard to review. I also see a bunch of
> deleted markdown files. Are they not getting migrated?
>
>
>>
>> On Tue, Apr 28, 2020 at 10:23 AM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>>
>>> Hello everybody,
>>>
>>> We are almost done migrating the Apache Beam website from Jekyll to
>>> Hugo. You can see the PR in [1], and we'd love to hear your
>>> feedback/comments on the PR. It includes  detailed guidelines on
>>> contributing to the new Hugo-based website and adding translations to 
>>> pages
>>> [2]. For those who are curious about adding new languages, we will 
>>> provide
>>> a proof of concept in the next couple of days in this thread.
>>>
>>> Since we want to move forward with the PR, I would like to ask the
>>> community to hold off changes to the current Beam website for a week, 
>>> until
>>> we are able to review and merge the PR. Is this acceptable to everyone?
>>>
>>> In case anyone missed my previous email with the background for the
>>> website migration, you can find more context here [3].
>>>
>>> Thanks,
>>> Aizhamal
>>>
>>> [1] https://github.com/apache/beam/pull/11554
>>> [2]
>>> https://github.com/apache/beam/blob/256b7042bf504b94f161ca03b388a2ba247918d9/website/CONTRIBUTE.md
>>> [3]

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Ahmet Altay]

Nam, this looks better. At least links are working, and the website
visually looks similar and generally in good shape. I think there are still
issues. For example, I do not see any of the images (e.g. the beam logo on
top left is missing.)

On Wed, Apr 29, 2020 at 3:11 PM Brian Hulette  wrote:

> I left a comment on the PR [1]. I think the reason all of the website
> content is not being tracked as file renames is because there was a series
> of commits that created files in the new directory, and then one commit
> that deleted the old directory. If there were a single commit with all of
> the deleted and new files, git would surely recognize they are effectively
> renameds and mark them as such. Maybe we just need to get all these commits
> squashed into one?
>
> [1] https://github.com/apache/beam/pull/11554#issuecomment-621489844
>

Nam, could you try this? If we can get git to recognize these as renames,
review process would be much easier.


>
> On Wed, Apr 29, 2020 at 10:39 AM Nam Bui  wrote:
>
>> Hi guys,
>>
>> I'm Nam - from the responsible team of Apache Beam website migration. I
>> am pleased to answer some of the questions here.
>>
>> @aizhamal: Thanks for informing to the community. :)
>> @altay, @robertwb: Yes. there is a problem with the staged version at the
>> moment. We didn't expect some behaviours on the build process. So, we fixed
>> it today and been waiting for @pablo to re-run it again. The purpose of
>> this PR is to migrate completely Beam site from Jekyll to Hugo. Therefore,
>> a bunch of deleted markdown files are from Jekyll which was located at
>> `beam/website/src`, and Hugo is located at `beam/website/www` now. In
>> `beam/website/README.md`, I wrote down about running the Hugo website
>> locally, although it is actually same as Jekyll (because it's also set
>> up with Docker & Gradle). In `beam/website/CONTRIBUTE.md`, I guided people
>> on how to get started with Hugo on the Beam website. There is also a link
>> in the "Translation Guide" section which points to a branch of multilingual
>> provenance, and it will become a next PR soon.
>>
>> Please let me know if you need more details. Feel free to ask any
>> questions and I will get back to you with answers. I'm so sorry if I answer
>> a little bit due to the timezone. :)
>>
>> Best regards,
>> Nam
>>
>>
>>
>> On Tue, Apr 28, 2020 at 8:49 PM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>>
>>> Adding +Nam Bui  and +Karolina Rosół
>>>  to follow up on questions.
>>>
>>> On Tue, Apr 28, 2020 at 11:34 AM Ahmet Altay  wrote:
>>>
 I am having trouble reviewing the staged version. What is the best way
 to review this change?

 Do we expect any changes to markdown files, beyond some metadata?

 On Tue, Apr 28, 2020 at 10:45 AM Robert Bradshaw 
 wrote:

> Thanks. It'll be great to better support more languages.
>
> I looked at the PR and there seems to be no provenance/history. E.g.
> all the content seems to be entirely new files rather than diffs from the
> old. (There also seems to be a huge amount of auto-generated js code as
> well.)
>

 I agree. This makes it very hard to review. I also see a bunch of
 deleted markdown files. Are they not getting migrated?


>
> On Tue, Apr 28, 2020 at 10:23 AM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
>
>> Hello everybody,
>>
>> We are almost done migrating the Apache Beam website from Jekyll to
>> Hugo. You can see the PR in [1], and we'd love to hear your
>> feedback/comments on the PR. It includes  detailed guidelines on
>> contributing to the new Hugo-based website and adding translations to 
>> pages
>> [2]. For those who are curious about adding new languages, we will 
>> provide
>> a proof of concept in the next couple of days in this thread.
>>
>> Since we want to move forward with the PR, I would like to ask the
>> community to hold off changes to the current Beam website for a week, 
>> until
>> we are able to review and merge the PR. Is this acceptable to everyone?
>>
>> In case anyone missed my previous email with the background for the
>> website migration, you can find more context here [3].
>>
>> Thanks,
>> Aizhamal
>>
>> [1] https://github.com/apache/beam/pull/11554
>> [2]
>> https://github.com/apache/beam/blob/256b7042bf504b94f161ca03b388a2ba247918d9/website/CONTRIBUTE.md
>> [3]
>> https://lists.apache.org/thread.html/r7fa6d710c0a1959cce5108e460d71c306ce5756cf96af818b41cb7ca%40%3Cdev.beam.apache.org%3E
>>
>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Brian Hulette]

I left a comment on the PR [1]. I think the reason all of the website
content is not being tracked as file renames is because there was a series
of commits that created files in the new directory, and then one commit
that deleted the old directory. If there were a single commit with all of
the deleted and new files, git would surely recognize they are effectively
renameds and mark them as such. Maybe we just need to get all these commits
squashed into one?

[1] https://github.com/apache/beam/pull/11554#issuecomment-621489844

On Wed, Apr 29, 2020 at 10:39 AM Nam Bui  wrote:

> Hi guys,
>
> I'm Nam - from the responsible team of Apache Beam website migration. I am
> pleased to answer some of the questions here.
>
> @aizhamal: Thanks for informing to the community. :)
> @altay, @robertwb: Yes. there is a problem with the staged version at the
> moment. We didn't expect some behaviours on the build process. So, we fixed
> it today and been waiting for @pablo to re-run it again. The purpose of
> this PR is to migrate completely Beam site from Jekyll to Hugo. Therefore,
> a bunch of deleted markdown files are from Jekyll which was located at
> `beam/website/src`, and Hugo is located at `beam/website/www` now. In
> `beam/website/README.md`, I wrote down about running the Hugo website
> locally, although it is actually same as Jekyll (because it's also set
> up with Docker & Gradle). In `beam/website/CONTRIBUTE.md`, I guided people
> on how to get started with Hugo on the Beam website. There is also a link
> in the "Translation Guide" section which points to a branch of multilingual
> provenance, and it will become a next PR soon.
>
> Please let me know if you need more details. Feel free to ask any
> questions and I will get back to you with answers. I'm so sorry if I answer
> a little bit due to the timezone. :)
>
> Best regards,
> Nam
>
>
>
> On Tue, Apr 28, 2020 at 8:49 PM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
>
>> Adding +Nam Bui  and +Karolina Rosół
>>  to follow up on questions.
>>
>> On Tue, Apr 28, 2020 at 11:34 AM Ahmet Altay  wrote:
>>
>>> I am having trouble reviewing the staged version. What is the best way
>>> to review this change?
>>>
>>> Do we expect any changes to markdown files, beyond some metadata?
>>>
>>> On Tue, Apr 28, 2020 at 10:45 AM Robert Bradshaw 
>>> wrote:
>>>
 Thanks. It'll be great to better support more languages.

 I looked at the PR and there seems to be no provenance/history. E.g.
 all the content seems to be entirely new files rather than diffs from the
 old. (There also seems to be a huge amount of auto-generated js code as
 well.)

>>>
>>> I agree. This makes it very hard to review. I also see a bunch of
>>> deleted markdown files. Are they not getting migrated?
>>>
>>>

 On Tue, Apr 28, 2020 at 10:23 AM Aizhamal Nurmamat kyzy <
 aizha...@apache.org> wrote:

> Hello everybody,
>
> We are almost done migrating the Apache Beam website from Jekyll to
> Hugo. You can see the PR in [1], and we'd love to hear your
> feedback/comments on the PR. It includes  detailed guidelines on
> contributing to the new Hugo-based website and adding translations to 
> pages
> [2]. For those who are curious about adding new languages, we will provide
> a proof of concept in the next couple of days in this thread.
>
> Since we want to move forward with the PR, I would like to ask the
> community to hold off changes to the current Beam website for a week, 
> until
> we are able to review and merge the PR. Is this acceptable to everyone?
>
> In case anyone missed my previous email with the background for the
> website migration, you can find more context here [3].
>
> Thanks,
> Aizhamal
>
> [1] https://github.com/apache/beam/pull/11554
> [2]
> https://github.com/apache/beam/blob/256b7042bf504b94f161ca03b388a2ba247918d9/website/CONTRIBUTE.md
> [3]
> https://lists.apache.org/thread.html/r7fa6d710c0a1959cce5108e460d71c306ce5756cf96af818b41cb7ca%40%3Cdev.beam.apache.org%3E
>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Nam Bui]

Hi guys,

I'm Nam - from the responsible team of Apache Beam website migration. I am
pleased to answer some of the questions here.

@aizhamal: Thanks for informing to the community. :)
@altay, @robertwb: Yes. there is a problem with the staged version at the
moment. We didn't expect some behaviours on the build process. So, we fixed
it today and been waiting for @pablo to re-run it again. The purpose of
this PR is to migrate completely Beam site from Jekyll to Hugo. Therefore,
a bunch of deleted markdown files are from Jekyll which was located at
`beam/website/src`, and Hugo is located at `beam/website/www` now. In
`beam/website/README.md`, I wrote down about running the Hugo website
locally, although it is actually same as Jekyll (because it's also set
up with Docker & Gradle). In `beam/website/CONTRIBUTE.md`, I guided people
on how to get started with Hugo on the Beam website. There is also a link
in the "Translation Guide" section which points to a branch of multilingual
provenance, and it will become a next PR soon.

Please let me know if you need more details. Feel free to ask any questions
and I will get back to you with answers. I'm so sorry if I answer a little
bit due to the timezone. :)

Best regards,
Nam



On Tue, Apr 28, 2020 at 8:49 PM Aizhamal Nurmamat kyzy 
wrote:

> Adding +Nam Bui  and +Karolina Rosół
>  to follow up on questions.
>
> On Tue, Apr 28, 2020 at 11:34 AM Ahmet Altay  wrote:
>
>> I am having trouble reviewing the staged version. What is the best way to
>> review this change?
>>
>> Do we expect any changes to markdown files, beyond some metadata?
>>
>> On Tue, Apr 28, 2020 at 10:45 AM Robert Bradshaw 
>> wrote:
>>
>>> Thanks. It'll be great to better support more languages.
>>>
>>> I looked at the PR and there seems to be no provenance/history. E.g. all
>>> the content seems to be entirely new files rather than diffs from the old.
>>> (There also seems to be a huge amount of auto-generated js code as well.)
>>>
>>
>> I agree. This makes it very hard to review. I also see a bunch of deleted
>> markdown files. Are they not getting migrated?
>>
>>
>>>
>>> On Tue, Apr 28, 2020 at 10:23 AM Aizhamal Nurmamat kyzy <
>>> aizha...@apache.org> wrote:
>>>
 Hello everybody,

 We are almost done migrating the Apache Beam website from Jekyll to
 Hugo. You can see the PR in [1], and we'd love to hear your
 feedback/comments on the PR. It includes  detailed guidelines on
 contributing to the new Hugo-based website and adding translations to pages
 [2]. For those who are curious about adding new languages, we will provide
 a proof of concept in the next couple of days in this thread.

 Since we want to move forward with the PR, I would like to ask the
 community to hold off changes to the current Beam website for a week, until
 we are able to review and merge the PR. Is this acceptable to everyone?

 In case anyone missed my previous email with the background for the
 website migration, you can find more context here [3].

 Thanks,
 Aizhamal

 [1] https://github.com/apache/beam/pull/11554
 [2]
 https://github.com/apache/beam/blob/256b7042bf504b94f161ca03b388a2ba247918d9/website/CONTRIBUTE.md
 [3]
 https://lists.apache.org/thread.html/r7fa6d710c0a1959cce5108e460d71c306ce5756cf96af818b41cb7ca%40%3Cdev.beam.apache.org%3E

>>>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Adding +Nam Bui  and +Karolina Rosół
 to follow up on questions.

On Tue, Apr 28, 2020 at 11:34 AM Ahmet Altay  wrote:

> I am having trouble reviewing the staged version. What is the best way to
> review this change?
>
> Do we expect any changes to markdown files, beyond some metadata?
>
> On Tue, Apr 28, 2020 at 10:45 AM Robert Bradshaw 
> wrote:
>
>> Thanks. It'll be great to better support more languages.
>>
>> I looked at the PR and there seems to be no provenance/history. E.g. all
>> the content seems to be entirely new files rather than diffs from the old.
>> (There also seems to be a huge amount of auto-generated js code as well.)
>>
>
> I agree. This makes it very hard to review. I also see a bunch of deleted
> markdown files. Are they not getting migrated?
>
>
>>
>> On Tue, Apr 28, 2020 at 10:23 AM Aizhamal Nurmamat kyzy <
>> aizha...@apache.org> wrote:
>>
>>> Hello everybody,
>>>
>>> We are almost done migrating the Apache Beam website from Jekyll to
>>> Hugo. You can see the PR in [1], and we'd love to hear your
>>> feedback/comments on the PR. It includes  detailed guidelines on
>>> contributing to the new Hugo-based website and adding translations to pages
>>> [2]. For those who are curious about adding new languages, we will provide
>>> a proof of concept in the next couple of days in this thread.
>>>
>>> Since we want to move forward with the PR, I would like to ask the
>>> community to hold off changes to the current Beam website for a week, until
>>> we are able to review and merge the PR. Is this acceptable to everyone?
>>>
>>> In case anyone missed my previous email with the background for the
>>> website migration, you can find more context here [3].
>>>
>>> Thanks,
>>> Aizhamal
>>>
>>> [1] https://github.com/apache/beam/pull/11554
>>> [2]
>>> https://github.com/apache/beam/blob/256b7042bf504b94f161ca03b388a2ba247918d9/website/CONTRIBUTE.md
>>> [3]
>>> https://lists.apache.org/thread.html/r7fa6d710c0a1959cce5108e460d71c306ce5756cf96af818b41cb7ca%40%3Cdev.beam.apache.org%3E
>>>
>>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Ahmet Altay]

I am having trouble reviewing the staged version. What is the best way to
review this change?

Do we expect any changes to markdown files, beyond some metadata?

On Tue, Apr 28, 2020 at 10:45 AM Robert Bradshaw 
wrote:

> Thanks. It'll be great to better support more languages.
>
> I looked at the PR and there seems to be no provenance/history. E.g. all
> the content seems to be entirely new files rather than diffs from the old.
> (There also seems to be a huge amount of auto-generated js code as well.)
>

I agree. This makes it very hard to review. I also see a bunch of deleted
markdown files. Are they not getting migrated?


>
> On Tue, Apr 28, 2020 at 10:23 AM Aizhamal Nurmamat kyzy <
> aizha...@apache.org> wrote:
>
>> Hello everybody,
>>
>> We are almost done migrating the Apache Beam website from Jekyll to Hugo.
>> You can see the PR in [1], and we'd love to hear your feedback/comments on
>> the PR. It includes  detailed guidelines on contributing to the new
>> Hugo-based website and adding translations to pages [2]. For those who are
>> curious about adding new languages, we will provide a proof of concept in
>> the next couple of days in this thread.
>>
>> Since we want to move forward with the PR, I would like to ask the
>> community to hold off changes to the current Beam website for a week, until
>> we are able to review and merge the PR. Is this acceptable to everyone?
>>
>> In case anyone missed my previous email with the background for the
>> website migration, you can find more context here [3].
>>
>> Thanks,
>> Aizhamal
>>
>> [1] https://github.com/apache/beam/pull/11554
>> [2]
>> https://github.com/apache/beam/blob/256b7042bf504b94f161ca03b388a2ba247918d9/website/CONTRIBUTE.md
>> [3]
>> https://lists.apache.org/thread.html/r7fa6d710c0a1959cce5108e460d71c306ce5756cf96af818b41cb7ca%40%3Cdev.beam.apache.org%3E
>>
>

Re: [REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Robert Bradshaw]

Thanks. It'll be great to better support more languages.

I looked at the PR and there seems to be no provenance/history. E.g. all
the content seems to be entirely new files rather than diffs from the old.
(There also seems to be a huge amount of auto-generated js code as well.)

On Tue, Apr 28, 2020 at 10:23 AM Aizhamal Nurmamat kyzy 
wrote:

> Hello everybody,
>
> We are almost done migrating the Apache Beam website from Jekyll to Hugo.
> You can see the PR in [1], and we'd love to hear your feedback/comments on
> the PR. It includes  detailed guidelines on contributing to the new
> Hugo-based website and adding translations to pages [2]. For those who are
> curious about adding new languages, we will provide a proof of concept in
> the next couple of days in this thread.
>
> Since we want to move forward with the PR, I would like to ask the
> community to hold off changes to the current Beam website for a week, until
> we are able to review and merge the PR. Is this acceptable to everyone?
>
> In case anyone missed my previous email with the background for the
> website migration, you can find more context here [3].
>
> Thanks,
> Aizhamal
>
> [1] https://github.com/apache/beam/pull/11554
> [2]
> https://github.com/apache/beam/blob/256b7042bf504b94f161ca03b388a2ba247918d9/website/CONTRIBUTE.md
> [3]
> https://lists.apache.org/thread.html/r7fa6d710c0a1959cce5108e460d71c306ce5756cf96af818b41cb7ca%40%3Cdev.beam.apache.org%3E
>

[REVIEW][please pause website changes] Migrated the Beam website to Hugo

[Aizhamal Nurmamat kyzy]

Hello everybody,

We are almost done migrating the Apache Beam website from Jekyll to Hugo.
You can see the PR in [1], and we'd love to hear your feedback/comments on
the PR. It includes  detailed guidelines on contributing to the new
Hugo-based website and adding translations to pages [2]. For those who are
curious about adding new languages, we will provide a proof of concept in
the next couple of days in this thread.

Since we want to move forward with the PR, I would like to ask the
community to hold off changes to the current Beam website for a week, until
we are able to review and merge the PR. Is this acceptable to everyone?

In case anyone missed my previous email with the background for the website
migration, you can find more context here [3].

Thanks,
Aizhamal

[1] https://github.com/apache/beam/pull/11554
[2]
https://github.com/apache/beam/blob/256b7042bf504b94f161ca03b388a2ba247918d9/website/CONTRIBUTE.md
[3]
https://lists.apache.org/thread.html/r7fa6d710c0a1959cce5108e460d71c306ce5756cf96af818b41cb7ca%40%3Cdev.beam.apache.org%3E