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
Received on 2017-10-03 23:37:47 CEST