incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: svn commit: r829379 - in /websites/production/ooo-site: cgi-bin/ content/
Date Tue, 21 Aug 2012 23:39:25 GMT
On 21 August 2012 22:23, Daniel Shahaf <danielsh@apache.org> wrote:
> 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.

This thread started because something was published inadvertently.

If the purpose of the enhancement is to prevent this happening, then
there needs to be some barrier that prevents inadvertent publication.

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

Mime
View raw message