On Mon, Jan 11, 2021 at 11:00 AM Robert Bradshaw <rober...@google.com> wrote:
> On Mon, Jan 11, 2021 at 10:38 AM Brian Hulette <bhule...@google.com> > wrote: > >> I spoke with Gris and Agnieszka about this on Friday. I should probably >> fill in the background a bit. >> >> The strategy we've adopted ro review the new designs so far is pretty >> similar to what Robert proposed, except rather than having a separate >> directory and merging PRs to the master branch, they've been sending PRs to >> merge into a separate `website-revamp` branch [1]. I've been keeping >> `website-revamp` synced to master, and I've been careful about only merging >> PRs that edit the website style (e.g. css and html templates) and not >> changes to the content (markdown files), to avoid merge conflicts when we >> finally bring the website-revamp branch into master. >> > > Ah, that sounds good. For some reason I completely missed that there was a > separate branch being used here. > > >> (Conflicts in style changes can be easily resolved, conflicts in content >> are much more difficult to tease apart) >> >> Unfortunately some of the recent PRs make changes to the markdown files >> as well. I spoke with Gris and Agnieszka about this and they indicated >> there will likely be more content changes as they edit copy and split up >> pages. >> >> On Friday we discussed a couple different options: >> 1) Make content changes on the master branch, completely separate from >> the style changes, or >> 2) Have a *planned* freeze in website changes to finalize the new design >> >> Honestly my preference is for (1), but I'm hesitant to push for it as it >> puts more burden on the website developers, who'd need to make sure content >> changes work in two website layouts. (2) on the other hand puts time >> pressure on the reviewers (myself and Pablo so far). >> > > My preference would be for (1) as well; and in addition presumably the > content changes would improve the current website as well as the new. There > is also option (3) which is allowing development to continue on the dev > branch (rather than a freeze) and placing the responsibility of correctly > recognizing and resolving conflicts on the owners of the website-revamp > branch. > I see myself (and all Beam committers) as the owner of the website-revamp branch, It's in the apache/beam repo. > > It might be worth highlighting an example of a content change that makes > any of these workflows difficult. > The most compelling example is the extensive changes to the contribution guide here: https://github.com/apache/beam/pull/13565/files#diff-3f46c575ca6547b8deef533eb8e191507edcf806529f7faecb4a56a246063af6 The PR was already missing the changes made to the contribution guide in https://github.com/apache/beam/pull/13308. I also just merged master into website-revamp, and the PR now has a merge conflict with the changes from https://github.com/apache/beam/pull/13420. > > >> [1] https://github.com/apache/beam/tree/website-revamp >> >> On Mon, Jan 11, 2021 at 10:03 AM Robert Bradshaw <rober...@google.com> >> wrote: >> >>> A site-wide freeze during which there was a huge, rushed code dump was >>> not the most effective way to manage or review the large website changes >>> last time, and I don't think it would be a good idea to attempt that again. >>> >>> Instead, can we create a parallel directory/site in our repo, >>> incrementally build/commit/review it in there, and once everyone is happy >>> with it do a single switch with a small redirection commit (followed by >>> deleting the old content). As for incorporating changes that happen during >>> development, this is what every developer is already doing (on the code >>> side) and we should take advantage of the revision control systems we use >>> to make sure nothing is lost. >>> >>> - Robert >>> >>> >>> >>> On Sun, Jan 10, 2021 at 4:07 PM Griselda Cuevas <g...@apache.org> wrote: >>> >>>> Hi folks, >>>> >>>> As you know we've been working on a revamp for the website, and we're >>>> getting ready to commit the work we've done. In order to minimize the risk >>>> of losing changes other contributors make during this period, we'd like to >>>> plan a freeze so we can work on making the revamp commits. A freeze in this >>>> context would mean that we give notice to our dev community to do not make >>>> any PRs or change to the site during this period. >>>> >>>> I'd like to propose we have a one-week freeze during the last week of >>>> January or the first week in February. >>>> >>>> What do you think? >>>> >>>> G >>>> >>>
