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 <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.)
>>>
>>
