You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Dave Fisher <da...@comcast.net> on 2012/08/19 19:52:04 UTC
Re: svn commit: r829379 - in /websites/production/ooo-site: cgi-bin/ content/
We were supposed to wait to publish.
Regards,
Dave
On Aug 19, 2012, at 8:08 AM, pescetti@apache.org wrote:
> Author: pescetti
> Date: Sun Aug 19 15:08:26 2012
> New Revision: 829379
>
> Log:
> Publishing svnmucc operation to ooo-site site by pescetti
>
> Added:
> websites/production/ooo-site/cgi-bin/
> - copied from r829378, websites/staging/ooo-site/trunk/cgi-bin/
> websites/production/ooo-site/content/
> - copied from r829378, websites/staging/ooo-site/trunk/content/
>
Re: svn commit: r829379 - in /websites/production/ooo-site: cgi-bin/ content/
Posted by Rob Weir <ro...@apache.org>.
On Sun, Aug 19, 2012 at 4:45 PM, Andrea Pescetti <pe...@apache.org> wrote:
> Dave Fisher wrote:
>>
>> We were supposed to wait to publish.
>>>
>>> Author: pescetti
>>>
>>> Date: Sun Aug 19 15:08:26 2012
>>> New Revision: 829379
>
>
> What did I publish? If it was only (like the diff showed)
> http://www.openoffice.org/it/stampa/comunicati/aoo341.html
> then it's OK to have it online. It's not linked and I prefer to prepare
> pages online in advance and only link them at the last minute.
>
Well, now there is a link, in our archives ;-)
> If I accidentally published something else, just let me know, but from the
> diff it seemed I was only going to publish the page above and that was
> intentional... Unless we want to keep the pages offline (on staging) until
> the announcement, but then there's the risk that we cannot catch errors in
> internal links.
>
> Regards,
> Andrea.
Re: svn commit: r829379 - in /websites/production/ooo-site: cgi-bin/ content/
Posted by Kay Schenk <ka...@gmail.com>.
On Sun, Aug 19, 2012 at 1:45 PM, Andrea Pescetti <pe...@apache.org>wrote:
> Dave Fisher wrote:
>
>> We were supposed to wait to publish.
>>
>>> Author: pescetti
>>> Date: Sun Aug 19 15:08:26 2012
>>> New Revision: 829379
>>>
>>
> What did I publish? If it was only (like the diff showed)
> http://www.openoffice.org/it/**stampa/comunicati/aoo341.html<http://www.openoffice.org/it/stampa/comunicati/aoo341.html>
> then it's OK to have it online. It's not linked and I prefer to prepare
> pages online in advance and only link them at the last minute.
>
> If I accidentally published something else, just let me know, but from the
> diff it seemed I was only going to publish the page above and that was
> intentional... Unless we want to keep the pages offline (on staging) until
> the announcement, but then there's the risk that we cannot catch errors in
> internal links.
>
> Regards,
> Andrea.
>
Andrea (and Dave), as an FYI...I basically did the same thing with the
writeup for the 3.4.1 release notes. It's not linked in to anything, it's
just out there, and announced here for folks to make further modifications
if necessary.
Since it takes a little bit of futzing to convert from cwiki to html, I
didn't want to leave this until the last minute.
--
----------------------------------------------------------------------------------------
MzK
"Never express yourself more clearly than you are able to think."
--
Niels Bohr
Re: svn commit: r829379 - in /websites/production/ooo-site: cgi-bin/
content/
Posted by Andrea Pescetti <pe...@apache.org>.
Marcus (OOo) wrote:
> - 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?)
Yes, and I consider it a bug (an inconvenience, say). But anyway, the
most reasonable option to me is preparing the full site, including all
new pages, and wait until to the last minute only for updating links
from the home page. So everything will be ready but final links will be
added when we release.
Otherwise, it's OK for me if we decide not to publish, but internal
links will need some guesswork. Anyway, I can perfectly avoid publish
operations in the next days (it's actually easier for me, since I tend
to use SVN directly to create and edit pages, and I have to use the CMS
only for publishing; this is just a matter of personal habits, nothing
related to the CMS performance or operations).
Regards,
Andrea.
Re: svn commit: r829379 - in /websites/production/ooo-site: cgi-bin/ content/
Posted by Rob Weir <ro...@apache.org>.
On Wed, Aug 22, 2012 at 5:54 AM, sebb <se...@gmail.com> wrote:
> On 22 August 2012 07:05, Andrea Pescetti <pe...@apache.org> wrote:
>> sebb wrote:
>>
>>> On 21 August 2012 22:23, Daniel Shahaf wrote:
>>>>
>>>> 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.
>>
>>
>> No, this thread started because people (including me) who did want to
>> publish their changes only, and who routinely used the "Diff" command in the
>> CMS to examine what would be published, were forced to take the "all or
>> nothing" approach (you will find me noting this in the log messages too).
>
> I was going by the following comments:
>
>>> >> >> 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:
>
I think either solution would work for us;
A) Ability to lock publication either of the entire /ooo-site or at
the level of a specific subdir. But I suppose from perspective of
Infra, everything is a subdir.
B) Ability in CMS for user to check off which files are actually
published, e.g., which subset. If it can default to select the files
that were modified in the current session, that is even better.
>>
>>> If the purpose of the enhancement is to prevent this happening, then
>>> there needs to be some barrier that prevents inadvertent publication.
>>
>>
>> This would be an extra guarantee, but probably an unnecessary complication
>> for what we have seen so far. Ability to publish one directory only would
>> already help a lot.
>>
>> Regards,
>> Andrea.
Re: svn commit: r829379 - in /websites/production/ooo-site: cgi-bin/ content/
Posted by sebb <se...@gmail.com>.
On 22 August 2012 07:05, Andrea Pescetti <pe...@apache.org> wrote:
> sebb wrote:
>
>> On 21 August 2012 22:23, Daniel Shahaf wrote:
>>>
>>> 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.
>
>
> No, this thread started because people (including me) who did want to
> publish their changes only, and who routinely used the "Diff" command in the
> CMS to examine what would be published, were forced to take the "all or
> nothing" approach (you will find me noting this in the log messages too).
I was going by the following comments:
>> >> >> 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:
>
>> If the purpose of the enhancement is to prevent this happening, then
>> there needs to be some barrier that prevents inadvertent publication.
>
>
> This would be an extra guarantee, but probably an unnecessary complication
> for what we have seen so far. Ability to publish one directory only would
> already help a lot.
>
> Regards,
> Andrea.
Re: svn commit: r829379 - in /websites/production/ooo-site: cgi-bin/
content/
Posted by Andrea Pescetti <pe...@apache.org>.
sebb wrote:
> On 21 August 2012 22:23, Daniel Shahaf wrote:
>> 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.
No, this thread started because people (including me) who did want to
publish their changes only, and who routinely used the "Diff" command in
the CMS to examine what would be published, were forced to take the "all
or nothing" approach (you will find me noting this in the log messages too).
> If the purpose of the enhancement is to prevent this happening, then
> there needs to be some barrier that prevents inadvertent publication.
This would be an extra guarantee, but probably an unnecessary
complication for what we have seen so far. Ability to publish one
directory only would already help a lot.
Regards,
Andrea.
Re: svn commit: r829379 - in /websites/production/ooo-site: cgi-bin/ content/
Posted by sebb <se...@gmail.com>.
On 21 August 2012 22:23, Daniel Shahaf <da...@apache.org> wrote:
> sebb wrote on Tue, Aug 21, 2012 at 16:04:12 +0100:
>> On 21 August 2012 13:43, Daniel Shahaf <da...@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
Re: svn commit: r829379 - in /websites/production/ooo-site: cgi-bin/
content/
Posted by Daniel Shahaf <da...@apache.org>.
sebb wrote on Tue, Aug 21, 2012 at 16:04:12 +0100:
> On 21 August 2012 13:43, Daniel Shahaf <da...@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
Re: svn commit: r829379 - in /websites/production/ooo-site: cgi-bin/ content/
Posted by sebb <se...@gmail.com>.
On 21 August 2012 13:43, Daniel Shahaf <da...@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.
>
>> Juergen
Re: svn commit: r829379 - in /websites/production/ooo-site: cgi-bin/
content/
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 08/21/2012 02:43 PM, schrieb Daniel Shahaf:
> 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?
Wow, yes. That would be a great feature. :-)
Marcus
Re: svn commit: r829379 - in /websites/production/ooo-site: cgi-bin/
content/
Posted by Daniel Shahaf <da...@apache.org>.
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?
> Juergen
Re: svn commit: r829379 - in /websites/production/ooo-site: cgi-bin/
content/
Posted by Jürgen Schmidt <jo...@gmail.com>.
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.
Juergen
Re: svn commit: r829379 - in /websites/production/ooo-site: cgi-bin/
content/
Posted by Daniel Shahaf <da...@apache.org>.
Ariel Constenla-Haile wrote on Mon, Aug 20, 2012 at 17:02:19 -0300:
> 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
I think you can hackily achieve that right now by adding a nonexistent
path to extpaths.txt (see cmsref for details on the latter).
CC please
> 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.
Re: svn commit: r829379 - in /websites/production/ooo-site: cgi-bin/
content/
Posted by Ariel Constenla-Haile <ar...@apache.org>.
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.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: svn commit: r829379 - in /websites/production/ooo-site: cgi-bin/
content/
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 08/19/2012 10:45 PM, schrieb Andrea Pescetti:
> Dave Fisher wrote:
>> We were supposed to wait to publish.
>>> Author: pescetti
>>> Date: Sun Aug 19 15:08:26 2012
>>> New Revision: 829379
>
> What did I publish? If it was only (like the diff showed)
> http://www.openoffice.org/it/stampa/comunicati/aoo341.html
> then it's OK to have it online. It's not linked and I prefer to prepare
> pages online in advance and only link them at the last minute.
>
> If I accidentally published something else, just let me know, but from
> the diff it seemed I was only going to publish the page above and that
> was intentional... Unless we want to keep the pages offline (on staging)
> until the announcement, but then there's the risk that we cannot catch
> errors in internal links.
@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?
My 2 ct.
Marcus
Re: svn commit: r829379 - in /websites/production/ooo-site: cgi-bin/
content/
Posted by Andrea Pescetti <pe...@apache.org>.
Dave Fisher wrote:
> We were supposed to wait to publish.
>> Author: pescetti
>> Date: Sun Aug 19 15:08:26 2012
>> New Revision: 829379
What did I publish? If it was only (like the diff showed)
http://www.openoffice.org/it/stampa/comunicati/aoo341.html
then it's OK to have it online. It's not linked and I prefer to prepare
pages online in advance and only link them at the last minute.
If I accidentally published something else, just let me know, but from
the diff it seemed I was only going to publish the page above and that
was intentional... Unless we want to keep the pages offline (on staging)
until the announcement, but then there's the risk that we cannot catch
errors in internal links.
Regards,
Andrea.