Hi guys, unfortunately option 1 is not really possible, because most of the new content files are importing shortcodes files so if we merge only content without layouts, these pages won't compile. The only reasonable option is to freeze the website and merge it then. My proposition is to merge it as follows: - firstly just swap the existing scss,js and html files and add the new ones, because most of the changes made by users are in content files and we want the continuity of design. - next are content files and here we just need to focus on couple of pages which were changed, most of these pages are main pages of each section and their purpose is to look legibly and nice, so we shouldn't add there more text, we can only check if the short description was changed recently and swap it for the newer version. The rest of the content pages where the most information is, weren't changed so we want to take them from the master branch.
This whole work was dedicated to change the design of the whole website, content which is changed is just displayed nicer for the user and is only on main pages, some of them have specially arranged texts to match new design, even if there are some new texts in these files on master branch they don't really have to match the new sites. - Jakub On Wed, Jan 13, 2021 at 3:59 AM Brian Hulette <bhule...@google.com> wrote: > > > 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 >>>>> >>>>
