On 05.10.2017 22:36, Johan Corveleyn wrote: > On Thu, Oct 5, 2017 at 12:30 PM, Daniel Shahaf <d...@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