On Thu, Oct 5, 2017 at 11:42 PM, Branko Čibej <br...@apache.org> wrote: > 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
Sorry, I dropped this on the floor trying to catch some other things. I'll try to pick up the pieces now :-) ... svn cp $URL/site/publish $URL/site/staging open infra ticket for serving /site/staging on subversion-staging.a.o put a short description of our desired workflow in /site/README -- Johan