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 <nam....@polidea.com> 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 <al...@google.com> 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 <nam....@polidea.com> 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 <nam....@polidea.com> 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 <nam....@polidea.com> 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 <al...@google.com> 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 <rober...@google.com> >>>>>> 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 <rober...@google.com> >>>>>>> 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 < >>>>>>>> rober...@google.com> 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 <bhule...@google.com> >>>>>>>>>> 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 < >>>>>>>>>>> rober...@google.com> 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 >>>>>>>>>>>> <aizha...@apache.org> 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 <al...@google.com> >>>>>>>>>>>> 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 < >>>>>>>>>>>> al...@google.com> 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 < >>>>>>>>>>>> rober...@google.com> wrote: >>>>>>>>>>>> >>>>>> >> >>>>>>>>>>>> >>>>>> >> On Mon, May 4, 2020 at 7:07 PM Ahmet Altay < >>>>>>>>>>>> al...@google.com> 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 >>>>>>>>>>>> >>>>>> >> 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.) >>>>>>>>>>>> >>>>>>>>>>>
