OK, so the current status is that changes are being reviewed and merged into a separate website-revamp branch. There are several reasons we could want to do this (e.g. could the changes not be made incrementally, or was there a strong desire to launch the new site "all at once"), but at some point we will want to merge this back into master.
My take is that it is on those who created this branch and are trying to push the changes in to be responsible for resolving any conflicts with master, just as it is with every other change anyone else takes on to make to the codebase. This can be done in whatever way is easiest for those making the change, either pushing changes upstream to master (to reduce the delta), resolving conflicts by merging master into website-revamp, or (probably the easiest for that which cannot be upstreamed) regularly merging master into website-revamp and resolving conflicts as PRs are merged into website-revamp. This is assuming that website-revamp is being managed in such a way that incompatible changes are flagged as merge conflicts, rather than silently getting dropped. This doesn't require arbitrary deadlines or freezes--all conflict resolution happens in website-revamp on its own time and it is (cleanly) merged back into master when it is ready (and of course there's no need to do this all at once--any ready parts can be merged before others to reduce the burden of maintaining a fork). The community can help out by refraining from large-scale refactorings that would be difficult to reconcile, but run-of-the-mill content improvements need not be put off. It should be noted that getting the changes merged back into master is a critical piece of completing the task--the job is not "done" just because the changes have been made with the expectation of handing them off to someone else to get it merged. In my experience with open source projects (dating well before Apache Beam), taking the easy route of snapshotting the project at some point, making all your changes there, and then hoping to merge things in is easier at first but at the end of the day more often than not ends up being more work (and frustration) than working on a copy that stays close to head (whether that be the actual master branch, or one that is regularly merged in). These look like good improvements and I'm just wanting to get them in as smoothly as possible. - Robert On Wed, Jan 13, 2021 at 9:09 AM Jakub Sadowski <jakub.sadow...@polidea.com> wrote: > 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 >>>>>> >>>>>
