On 03.10.2017 23:32, Johan Corveleyn wrote: > The recent work on our quick-start.html page by Pavel Lyalyakin > prompted some thinking about how to better organize our site editing. > Pavel asked about lightweight branching and Daniel suggested to copy > site/publish to site/staging and having it served as > http://subversion.staging.apache.org/ to facilitate previewing [1]. > > I think that's a great idea (I've sometimes wanted something like this > myself, for instance when working on a difficult FAQ entry). So, if > we'd have such a staging site, how should we use it? > > How about a very simple workflow like this? > > 1) Commit to staging. Other devs get the commit mail via the > notifications@ list. > > 2) Wait for others to review (the commit mail is the notification that > something needs to be reviewed). In case of large or sensitive > changes, preferably send a mail to dev@ to draw extra attention. > > 3) If any other committer says +1, go ahead and "promote" (merge) to > the live site. > > 4) If no response after 1 week? 3 days? ...? go ahead and promote to > live site (lazy consensus). > > Small changes and corrections can go directly to the live site. Maybe > we'll need some exceptions for things like news, release notes and > security pages, which are usually updated as part of releases and get > a lot of eyes already. > > Thoughts?
Something that has most (all?) merges going in one direction and no cherry-picks. Except for security announcements, everything else can be tested on staging first. -- Brane