incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <danie...@apache.org>
Subject Re: svn commit: r829379 - in /websites/production/ooo-site: cgi-bin/ content/
Date Tue, 21 Aug 2012 21:23:14 GMT
sebb wrote on Tue, Aug 21, 2012 at 16:04:12 +0100:
> On 21 August 2012 13:43, Daniel Shahaf <danielsh@apache.org> wrote:
> > J├╝rgen Schmidt wrote on Tue, Aug 21, 2012 at 14:38:34 +0200:
> >> On 8/20/12 10:02 PM, Ariel Constenla-Haile wrote:
> >> > On Mon, Aug 20, 2012 at 09:49:52PM +0200, Marcus (OOo) wrote:
> >> >> @all:
> >> >>
> >> >> Sorry but IMHO this process failed. Just today evening (Hamburg
> >> >> time) someone has published again website changes.
> >> >>
> >> >> If we rely on a process that is so fragile, then IMHO we shouldn't
> >> >> do this. Because there will be always somebody:
> >> >>
> >> >> - who doesn't know this
> >> >>
> >> >> - who isn't aware of the consequences of her/his changes
> >> >>   (do you all know that a change on a NL webpage will also
> >> >>   publish everything else in staging?)
> >> >>
> >> >> - who hasn't seen a "please don't publish the website until further
> >> >>   notice" mail
> >> >>   (to be honest, I haven't seen a clear note that is
> >> >>   forbidden at the moment, too)
> >> >>
> >> >> - etc.
> >> >>
> >> >> The other solution would be to completely not change anything (incl.
> >> >> no commits) to the website until the release is, e.g., 1 hour away
> >> >> which is also nothing I would like to see as it's not flexible
> >> >> enough.
> >> >>
> >> >> Are there other opinions/suggestions?
> >> >
> >> > The ideal would be if the CMS could have an option to lock publishing so
> >> > that no-one publishes the site, not even by mistake. Sure someone from
> >> > knows if this is possible or just an ideal, though impossible solution.
> >> >
> >>
> >> or even a more fine grained publishing process by marking the files
> >> explicitly. I think of 2 mode, publish all or selected files only.
> >>
> >
> > That would be easy to implement (given a list of filenames you'd just
> > svnmucc copy those files from staging/ to production/); check with Joe
> > what he thinks of such a potential feature?
> 
> This may be obvious to all readers, but just in case:
> For this to be fool-proof, I think there would need to be some way to
> prevent anyone bypassing the selection.
> 

Why?  Could very well have a "publish all changes" mode (the current
only option) alongside the "cherry picking" (publish only selected file)
mode.

BTW Joe, the equivalent code in svn should be the commit harvester in
the client.

> >
> >> Juergen

Mime
View raw message