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). -- Johan
