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?

[1] https://svn.haxx.se/dev/archive-2017-10/0004.shtml

-- 
Johan

Reply via email to