[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Workflow for editing the subversion website

From: Branko Čibej <brane_at_apache.org>
Date: Thu, 5 Oct 2017 23:42:09 +0200

On 05.10.2017 22:36, Johan Corveleyn wrote:
> On Thu, Oct 5, 2017 at 12:30 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>> Devil's advocate hat on, and in light of Brane's sibling reply, let me
>> describe how an svnmucc workflow might work.
> Thanks, but I prefer the merge workflow. It seems more natural to me,
> and I think it's more likely to be used by other svn users out there,
> in case they have such a workflow. So it seems like the more
> interesting dog food to me :-).
>
> I'm not very good at writing down an accurate procedure, but I still
> think it should be something like I wrote in my first mail in this
> thread:
>
>> 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).
> As Brane suggested, let's do everything in this direction (test on
> staging first, then merge to publish), except for security
> announcements.
>
> And as Daniel suggested, let's serve the staging site via
> https://subversion-staging.apache.org/ (I'd say we ask infra to set
> this up for us).

Sounds like a plan.

-- Brane
Received on 2017-10-05 23:42:12 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.