subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <>
Subject Re: Workflow for editing the subversion website
Date Tue, 03 Oct 2017 21:37:44 GMT
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
> 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

Except for security announcements, everything else can be tested on
staging first.

-- Brane

View raw message