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
> 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
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).
Received on 2017-10-05 22:37:13 CEST