You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Rob Weir <ro...@apache.org> on 2014/03/07 15:22:21 UTC
Anything we can do about premature redistribution?
Evidently we're already released, on some websites at least:
http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml
How much do we care about this? The risk, I suppose, is on
Softpedia, that we could find a last-minute defect in the NOTICE or
other legal files, and they find themselves distributing a package
that is not correct. But the practical risk there is small.
The greater risk is to users, that we find a last-minute fatal bug
that causes us to cancel the vote, but there are versions of the
Release Candidate still floating around. That can hurt the AOO
reputation if that happened.
I'm not sure we can prevent this from happening, and still have an
open and transparent voting process. But maybe there is something we
can do to discourage it?
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Alexandro Colorado <jz...@oooes.org>.
On 3/7/14, Rob Weir <ro...@apache.org> wrote:
> Evidently we're already released, on some websites at least:
>
> http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml
>
> How much do we care about this? The risk, I suppose, is on
> Softpedia, that we could find a last-minute defect in the NOTICE or
> other legal files, and they find themselves distributing a package
> that is not correct. But the practical risk there is small.
>
> The greater risk is to users, that we find a last-minute fatal bug
> that causes us to cancel the vote, but there are versions of the
> Release Candidate still floating around. That can hurt the AOO
> reputation if that happened.
This is implied on the 'Beta' label that was added on softpedia. Every
beta product assumes that bugs, even critical could surface.
>
> I'm not sure we can prevent this from happening, and still have an
> open and transparent voting process. But maybe there is something we
> can do to discourage it?
At the bottom of the website it says Feedback. Of course you could
legally contact the parent company about the issue but I dont think
that's necessary.
>
> -Rob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
Alexandro Colorado
Apache OpenOffice Contributor
http://www.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Alexandro Colorado <jz...@oooes.org>.
On 3/7/14, Rob Weir <ro...@apache.org> wrote:
> On Fri, Mar 7, 2014 at 10:23 AM, Jürgen Schmidt <jo...@gmail.com>
> wrote:
>> On 3/7/14 4:21 PM, Oliver-Rainer Wittmann wrote:
>>> Hi,
>>>
>>> On 07.03.2014 15:22, Rob Weir wrote:
>>>> Evidently we're already released, on some websites at least:
>>>>
>>>> http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml
>>>>
>>>>
>>>> How much do we care about this? The risk, I suppose, is on
>>>> Softpedia, that we could find a last-minute defect in the NOTICE or
>>>> other legal files, and they find themselves distributing a package
>>>> that is not correct. But the practical risk there is small.
>>>>
>>>> The greater risk is to users, that we find a last-minute fatal bug
>>>> that causes us to cancel the vote, but there are versions of the
>>>> Release Candidate still floating around. That can hurt the AOO
>>>> reputation if that happened.
>>>>
>>>> I'm not sure we can prevent this from happening, and still have an
>>>> open and transparent voting process. But maybe there is something we
>>>> can do to discourage it?
>>>>
>>>
>>>
>>> softpedia is not the only one:
>>> - http://www.chip.de/downloads/OpenOffice_14324674.html
>>> - http://www.computerbase.de/downloads/office/
>>>
>>
>> I think we can create a blog explaining the voting procedure and make
>> clear where we are in the process and that it is the RC of the Beta only.
>>
>
> Or maybe a disclaimer in the voting thread email? Next time we could
> say something like:
>
> "Note: All Apache releases require a vote of the PMC lasting at
> least 72-hours. We do not officially release until after that vote
> has concluded. We appreciate the enthusiasm of our users and 3rd
> party distributors and their efforts to publicize our releases and
> share them with a broader audience. But we ask that you do not
> publicize a release until the vote has concluded and the vote results
> posted. This is for the safety of the users. It is always possible
> for a last minute defect to be reported in a Release Candidate causing
> us to cancel an in-progress vote. in fact this has occurred before.
> So be safe and wait for the release process to conclude."
>
> I'm guessing that they hear about the RC from the email list, not the
> wiki, so it might make sense to put a message like this in the vote
> email.
Not sure email would be as effective as on the website (in this case,
the cWiki page). Do softpedia find out about these RCs from the ML or
the wiki?
>
> -Rob
>
>
>> But I don't know if this would really help to avoid confusion.
>>
>> Juergen
>>
>>
>>>
>>> Best regards, Oliver.
>>>
>>>> -Rob
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
Alexandro Colorado
Apache OpenOffice Contributor
http://www.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 03/08/2014 12:29 AM, schrieb Vladislav Stevanovic:
> When somebody want to download beta version of AOO it will be good aproach
> to show pop-up dialog with warnings that this is not stable version and it
> only for testing. We can not stopped other to write what they write about
> AOO but we can protect potential users with info dialog when they press
> link for downloading beta version.
That will be done on the download webpage - when the Beta is actually
available.
Marcus
> 2014-03-08 0:09 GMT+01:00 Andrea Pescetti<pe...@apache.org>:
>
>> Rob Weir wrote:
>>
>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>> Apache-OpenOffice-253.shtml
>>>>>>
>>>>> Or maybe a disclaimer in the voting thread email?
>>>
>>
>> Andrew's comments show clearly that these editors do not care to be
>> careful or factual, or even read those disclaimers, unfortunately.
>>
>> We can be successful only if we manage to block their downloads. They link
>> to our binaries hosted on SourceForge (which is fine). Just thinking loud,
>> but if it was possible (on the Sourceforge side) to deny all download
>> requests that do not come from the openoffice.org or the sourceforge.netdomains, then the project would effectively be in control. The embargo
>> could be lifted just after the release.
>>
>> Sure, sites could still copy all binaries being voted upon and offer them
>> locally, but this would require a more significant effort. on their side.
>>
>> Regards,
>> Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Vladislav Stevanovic <st...@gmail.com>.
When somebody want to download beta version of AOO it will be good aproach
to show pop-up dialog with warnings that this is not stable version and it
only for testing. We can not stopped other to write what they write about
AOO but we can protect potential users with info dialog when they press
link for downloading beta version.
Regards,
Wlada
2014-03-08 0:09 GMT+01:00 Andrea Pescetti <pe...@apache.org>:
> Rob Weir wrote:
>
>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>> Apache-OpenOffice-253.shtml
>>>>>
>>>> Or maybe a disclaimer in the voting thread email?
>>
>
> Andrew's comments show clearly that these editors do not care to be
> careful or factual, or even read those disclaimers, unfortunately.
>
> We can be successful only if we manage to block their downloads. They link
> to our binaries hosted on SourceForge (which is fine). Just thinking loud,
> but if it was possible (on the Sourceforge side) to deny all download
> requests that do not come from the openoffice.org or the sourceforge.netdomains, then the project would effectively be in control. The embargo
> could be lifted just after the release.
>
> Sure, sites could still copy all binaries being voted upon and offer them
> locally, but this would require a more significant effort. on their side.
>
> Regards,
> Andrea.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Anything we can do about premature redistribution?
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 03/10/2014 08:57 AM, schrieb Andre Fischer:
> On 10.03.2014 08:32, Jürgen Schmidt wrote:
>> On 3/9/14 8:49 PM, Marcus (OOo) wrote:
>>> Am 03/09/2014 07:33 PM, schrieb Kay Schenk:
>>>> On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo)<ma...@wtnet.de>
>>>> wrote:
>>>>
>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>>
>>>>>> Rob Weir wrote:
>>>>>>
>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>>
>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>> Andrew's comments show clearly that these editors do not care to be
>>>>>> careful or factual, or even read those disclaimers, unfortunately.
>>>>>>
>>>>>> We can be successful only if we manage to block their downloads. They
>>>>>> link to our binaries hosted on SourceForge (which is fine). Just
>>>>>> thinking loud, but if it was possible (on the Sourceforge side) to
>>>>>> deny
>>>>>> all download requests that do not come from the openoffice.org or the
>>>>>> sourceforge.net domains, then the project would effectively be in
>>>>>> control. The embargo could be lifted just after the release.
>>>>>>
>>>> I'm a bit confused by this statement. There are MANY sites the
>>>> re-route to
>>>> SourceForge for our downloads, and this is perfectly fine. The
>>>> concern is
>>>> for the inadvertent download of not yet released Beta which is
>>>> available
>>>> from the following URL space which is not even SourceForge:
>>>>
>>>> http://ci.apache.org/projects/openoffice/milestones
>>> OK, for the Beta release in special this is true. It's not yet available
>>> on Sourceforge - at least I cannot see it.
>> it is there as well, hdu started the synch when the bits where ready on
>> the Apache server for some further testing purposes (especially upload
>> performance). And of course to have them in place in time for today.
>>
>> It was probably a little bit early but independent where we upload the
>> bits they will be grabbed immediately. Which is not necessarily bad if
>> they would do their job a little bit better ;-) There was no official
>> release announcement.
>
> Is it possible to upload to some kind of staging area on sourceforge
> that is not accessible to the public? Keep the bits there until our vote
> has finished and them move them to the download area?
Yes, you can create a new folder and give it a staging bit. Then you can
use it (e.g., upload things into it) but it is not visible to the outside.
Marcus
>>> In general, they link to our binaries at Sourceforge.
>>>
>>>> Correct? So, I think the restriction would need to be from
>>>> ci.apache.org,
>>>> not SourceForge.
>>> For the Beta release this is true.
>>>
>>> However, I don't know how long this makes sense.
>>>
>>> Marcus
>>>
>>>
>>>
>>>>> For me this sounds like a great idea.
>>>>>
>>>>> Maybe we should start with denying all download requests that some
>>>>> from
>>>>> these bad websites.
>>>>>
>>>>> @Roberto:
>>>>> Can you tell us if this possible? If yes, is it much effort for you?
>>>>>
>>>>> Sure, sites could still copy all binaries being voted upon and offer
>>>>>> them locally, but this would require a more significant effort. on
>>>>>> their
>>>>>> side.
>>>>>>
>>>>> And more HDD space and more own bandwith - which is also not what they
>>>>> want.
>>>>>
>>>>> Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Andre Fischer <aw...@gmail.com>.
On 10.03.2014 08:32, Jürgen Schmidt wrote:
> On 3/9/14 8:49 PM, Marcus (OOo) wrote:
>> Am 03/09/2014 07:33 PM, schrieb Kay Schenk:
>>> On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo)<ma...@wtnet.de>
>>> wrote:
>>>
>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>
>>>>> Rob Weir wrote:
>>>>>
>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>
>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>> Andrew's comments show clearly that these editors do not care to be
>>>>> careful or factual, or even read those disclaimers, unfortunately.
>>>>>
>>>>> We can be successful only if we manage to block their downloads. They
>>>>> link to our binaries hosted on SourceForge (which is fine). Just
>>>>> thinking loud, but if it was possible (on the Sourceforge side) to deny
>>>>> all download requests that do not come from the openoffice.org or the
>>>>> sourceforge.net domains, then the project would effectively be in
>>>>> control. The embargo could be lifted just after the release.
>>>>>
>>> I'm a bit confused by this statement. There are MANY sites the
>>> re-route to
>>> SourceForge for our downloads, and this is perfectly fine. The concern is
>>> for the inadvertent download of not yet released Beta which is available
>>> from the following URL space which is not even SourceForge:
>>>
>>> http://ci.apache.org/projects/openoffice/milestones
>> OK, for the Beta release in special this is true. It's not yet available
>> on Sourceforge - at least I cannot see it.
> it is there as well, hdu started the synch when the bits where ready on
> the Apache server for some further testing purposes (especially upload
> performance). And of course to have them in place in time for today.
>
> It was probably a little bit early but independent where we upload the
> bits they will be grabbed immediately. Which is not necessarily bad if
> they would do their job a little bit better ;-) There was no official
> release announcement.
Is it possible to upload to some kind of staging area on sourceforge
that is not accessible to the public? Keep the bits there until our
vote has finished and them move them to the download area?
-Andre
>
> Juergen
>
>
>> In general, they link to our binaries at Sourceforge.
>>
>>> Correct? So, I think the restriction would need to be from ci.apache.org,
>>> not SourceForge.
>> For the Beta release this is true.
>>
>> However, I don't know how long this makes sense.
>>
>> Marcus
>>
>>
>>
>>>> For me this sounds like a great idea.
>>>>
>>>> Maybe we should start with denying all download requests that some from
>>>> these bad websites.
>>>>
>>>> @Roberto:
>>>> Can you tell us if this possible? If yes, is it much effort for you?
>>>>
>>>> Sure, sites could still copy all binaries being voted upon and offer
>>>>> them locally, but this would require a more significant effort. on
>>>>> their
>>>>> side.
>>>>>
>>>> And more HDD space and more own bandwith - which is also not what they
>>>> want.
>>>>
>>>> Marcus
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 03/10/2014 08:32 AM, schrieb Jürgen Schmidt:
> On 3/9/14 8:49 PM, Marcus (OOo) wrote:
>> Am 03/09/2014 07:33 PM, schrieb Kay Schenk:
>>> On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo)<ma...@wtnet.de>
>>> wrote:
>>>
>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>
>>>>> Rob Weir wrote:
>>>>>
>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>
>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>>
>>>>>
>>>>> Andrew's comments show clearly that these editors do not care to be
>>>>> careful or factual, or even read those disclaimers, unfortunately.
>>>>>
>>>>> We can be successful only if we manage to block their downloads. They
>>>>> link to our binaries hosted on SourceForge (which is fine). Just
>>>>> thinking loud, but if it was possible (on the Sourceforge side) to deny
>>>>> all download requests that do not come from the openoffice.org or the
>>>>> sourceforge.net domains, then the project would effectively be in
>>>>> control. The embargo could be lifted just after the release.
>>>>>
>>>>
>>> I'm a bit confused by this statement. There are MANY sites the
>>> re-route to
>>> SourceForge for our downloads, and this is perfectly fine. The concern is
>>> for the inadvertent download of not yet released Beta which is available
>>> from the following URL space which is not even SourceForge:
>>>
>>> http://ci.apache.org/projects/openoffice/milestones
>>
>> OK, for the Beta release in special this is true. It's not yet available
>> on Sourceforge - at least I cannot see it.
>
> it is there as well, hdu started the synch when the bits where ready on
> the Apache server for some further testing purposes (especially upload
> performance). And of course to have them in place in time for today.
I've expected this. But what scares me is that I cannot see anything
about the Beta even when I'm logged-in as admin.
Marcus
> It was probably a little bit early but independent where we upload the
> bits they will be grabbed immediately. Which is not necessarily bad if
> they would do their job a little bit better ;-) There was no official
> release announcement.
>
> Juergen
>
>
>>
>> In general, they link to our binaries at Sourceforge.
>>
>>> Correct? So, I think the restriction would need to be from ci.apache.org,
>>> not SourceForge.
>>
>> For the Beta release this is true.
>>
>> However, I don't know how long this makes sense.
>>
>> Marcus
>>
>>
>>
>>>> For me this sounds like a great idea.
>>>>
>>>> Maybe we should start with denying all download requests that some from
>>>> these bad websites.
>>>>
>>>> @Roberto:
>>>> Can you tell us if this possible? If yes, is it much effort for you?
>>>>
>>>> Sure, sites could still copy all binaries being voted upon and offer
>>>>> them locally, but this would require a more significant effort. on
>>>>> their
>>>>> side.
>>>>>
>>>>
>>>> And more HDD space and more own bandwith - which is also not what they
>>>> want.
>>>>
>>>> Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 3/9/14 8:49 PM, Marcus (OOo) wrote:
> Am 03/09/2014 07:33 PM, schrieb Kay Schenk:
>> On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo)<ma...@wtnet.de>
>> wrote:
>>
>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>
>>>> Rob Weir wrote:
>>>>
>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>
>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>
>>>>
>>>> Andrew's comments show clearly that these editors do not care to be
>>>> careful or factual, or even read those disclaimers, unfortunately.
>>>>
>>>> We can be successful only if we manage to block their downloads. They
>>>> link to our binaries hosted on SourceForge (which is fine). Just
>>>> thinking loud, but if it was possible (on the Sourceforge side) to deny
>>>> all download requests that do not come from the openoffice.org or the
>>>> sourceforge.net domains, then the project would effectively be in
>>>> control. The embargo could be lifted just after the release.
>>>>
>>>
>> I'm a bit confused by this statement. There are MANY sites the
>> re-route to
>> SourceForge for our downloads, and this is perfectly fine. The concern is
>> for the inadvertent download of not yet released Beta which is available
>> from the following URL space which is not even SourceForge:
>>
>> http://ci.apache.org/projects/openoffice/milestones
>
> OK, for the Beta release in special this is true. It's not yet available
> on Sourceforge - at least I cannot see it.
it is there as well, hdu started the synch when the bits where ready on
the Apache server for some further testing purposes (especially upload
performance). And of course to have them in place in time for today.
It was probably a little bit early but independent where we upload the
bits they will be grabbed immediately. Which is not necessarily bad if
they would do their job a little bit better ;-) There was no official
release announcement.
Juergen
>
> In general, they link to our binaries at Sourceforge.
>
>> Correct? So, I think the restriction would need to be from ci.apache.org,
>> not SourceForge.
>
> For the Beta release this is true.
>
> However, I don't know how long this makes sense.
>
> Marcus
>
>
>
>>> For me this sounds like a great idea.
>>>
>>> Maybe we should start with denying all download requests that some from
>>> these bad websites.
>>>
>>> @Roberto:
>>> Can you tell us if this possible? If yes, is it much effort for you?
>>>
>>> Sure, sites could still copy all binaries being voted upon and offer
>>>> them locally, but this would require a more significant effort. on
>>>> their
>>>> side.
>>>>
>>>
>>> And more HDD space and more own bandwith - which is also not what they
>>> want.
>>>
>>> Marcus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 03/09/2014 07:33 PM, schrieb Kay Schenk:
> On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo)<ma...@wtnet.de> wrote:
>
>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>
>>> Rob Weir wrote:
>>>
>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>
>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>
>>>
>>> Andrew's comments show clearly that these editors do not care to be
>>> careful or factual, or even read those disclaimers, unfortunately.
>>>
>>> We can be successful only if we manage to block their downloads. They
>>> link to our binaries hosted on SourceForge (which is fine). Just
>>> thinking loud, but if it was possible (on the Sourceforge side) to deny
>>> all download requests that do not come from the openoffice.org or the
>>> sourceforge.net domains, then the project would effectively be in
>>> control. The embargo could be lifted just after the release.
>>>
>>
> I'm a bit confused by this statement. There are MANY sites the re-route to
> SourceForge for our downloads, and this is perfectly fine. The concern is
> for the inadvertent download of not yet released Beta which is available
> from the following URL space which is not even SourceForge:
>
> http://ci.apache.org/projects/openoffice/milestones
OK, for the Beta release in special this is true. It's not yet available
on Sourceforge - at least I cannot see it.
In general, they link to our binaries at Sourceforge.
> Correct? So, I think the restriction would need to be from ci.apache.org,
> not SourceForge.
For the Beta release this is true.
However, I don't know how long this makes sense.
Marcus
>> For me this sounds like a great idea.
>>
>> Maybe we should start with denying all download requests that some from
>> these bad websites.
>>
>> @Roberto:
>> Can you tell us if this possible? If yes, is it much effort for you?
>>
>> Sure, sites could still copy all binaries being voted upon and offer
>>> them locally, but this would require a more significant effort. on their
>>> side.
>>>
>>
>> And more HDD space and more own bandwith - which is also not what they
>> want.
>>
>> Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Andrea Pescetti <pe...@apache.org>.
On 09/03/2014 Kay Schenk wrote:
> The concern is
> for the inadvertent download of not yet released Beta which is available
> from the following URL space which is not even SourceForge:
> http://ci.apache.org/projects/openoffice/milestones
> Correct?
No. The link Rob posted at the beginning of this discussion
http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml
will redirect you for download to something under
http://sourceforge.net/projects/openofficeorg.mirror/files/milestones/4.1.0-beta/binaries/en-US/
which, I assume, is the location we will advertise on the main download
page for Beta downloads (otherwise Infra will be quite upset if we link
to Apache servers!).
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Kay Schenk <ka...@gmail.com>.
On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo) <ma...@wtnet.de> wrote:
> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>
>> Rob Weir wrote:
>>
>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>> Apache-OpenOffice-253.shtml
>>>>>>
>>>>>> Or maybe a disclaimer in the voting thread email?
>>>
>>
>> Andrew's comments show clearly that these editors do not care to be
>> careful or factual, or even read those disclaimers, unfortunately.
>>
>> We can be successful only if we manage to block their downloads. They
>> link to our binaries hosted on SourceForge (which is fine). Just
>> thinking loud, but if it was possible (on the Sourceforge side) to deny
>> all download requests that do not come from the openoffice.org or the
>> sourceforge.net domains, then the project would effectively be in
>> control. The embargo could be lifted just after the release.
>>
>
I'm a bit confused by this statement. There are MANY sites the re-route to
SourceForge for our downloads, and this is perfectly fine. The concern is
for the inadvertent download of not yet released Beta which is available
from the following URL space which is not even SourceForge:
http://ci.apache.org/projects/openoffice/milestones
Correct? So, I think the restriction would need to be from ci.apache.org,
not SourceForge.
> For me this sounds like a great idea.
>
> Maybe we should start with denying all download requests that some from
> these bad websites.
>
> @Roberto:
> Can you tell us if this possible? If yes, is it much effort for you?
>
> Sure, sites could still copy all binaries being voted upon and offer
>> them locally, but this would require a more significant effort. on their
>> side.
>>
>
> And more HDD space and more own bandwith - which is also not what they
> want.
>
> Marcus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
-------------------------------------------------------------------------------------------------
MzK
"Cats do not have to be shown how to have a good time,
for they are unfailing ingenious in that respect."
-- James Mason
Re: Anything we can do about premature redistribution?
Posted by Jürgen Lange <jl...@juergen-lange.de>.
+1 I like this way
Am 31.03.2014 22:48, schrieb Rob Weir:
> On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) <ma...@wtnet.de> wrote:
>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
>>
>>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<ma...@wtnet.de>:
>>>
>>>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
>>>>
>>>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
>>>>>
>>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>>>
>>>>>>> Rob Weir wrote:
>>>>>>>
>>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>>>>
>>>>>>> Andrew's comments show clearly that these editors do not care to be
>>>>>>> careful or factual, or even read those disclaimers, unfortunately.
>>>>>>>
>>>>>>> We can be successful only if we manage to block their downloads. They
>>>>>>> link to our binaries hosted on SourceForge (which is fine). Just
>>>>>>> thinking loud, but if it was possible (on the Sourceforge side) to
>>>>>>> deny
>>>>>>> all download requests that do not come from the openoffice.org or the
>>>>>>> sourceforge.net domains, then the project would effectively be in
>>>>>>> control. The embargo could be lifted just after the release.
>>>>>>>
>>>>>> For me this sounds like a great idea.
>>>>>>
>>>>>> Maybe we should start with denying all download requests that some from
>>>>>> these bad websites.
>>>>>>
>>>>>> @Roberto:
>>>>>> Can you tell us if this possible? If yes, is it much effort for you?
>>>>>>
>>>>> Do you see a chance to get this implemented? I think it could help to
>>>>> stop some bad websites to do bad things with our software.
>>>>>
>>>> @Roberto:
>>>> Maybe you haven't seen this up to now.
>>>>
>>> Thanks for heads up Marcus, sorry for not having noticed this thread
>>> before.
>>>
>>>
>>>
>>>> It would be great if you can tell us if it's possible to exclude some
>>>> domains / IP addresses from downloading our software?
>>>>
>>> I need the domain list and I'll check out with our SiteOps if that's
>>> doable. Feel free to send me a list with a direct message.
>>
>> - chip.de
>> - computerbase.de
>> - softpedia.com
>>
>> This would be the domains from this thread that could be blocked from
>> downloading from Sourceforge. Obviously needs to be extended in the future.
>> Remember, the next will happen with the AOO 4.1.0 RC. ;-)
>>
>> *Of course*, this is just for the time frame as long as the new version is
>> not officially announced. As soon as the release is public, the block will
>> be removed.
>>
>> @all:
>> I think this could help to limit the downloadability like we want to see
>> until the official release. What you think?
>>
> I don't know. Won't this just cause confusion? They point to the
> files, go to test them, see the links don't work, and then get weird
> errors and spend an hour trying to debug it. We don't want to
> needlessly annoy them, since their only fault is enthusiasm. Is
> there a way we can give a useful error message in this case like,
> "This version of Apache OpenOffice has not yet been officially
> released. Links to these files are disallowed until the release is
> officially approved" or something like that?
>
> -Rob
>
>> Marcus
>>
>>
>>
>>
>>>> Then we can exclude requester that we don't want (e.g., malware
>>>> "distributors").
>>>>
>>>> Also in time frames with Beta or RC releases it can help us to steer who
>>>> is able and when it is possible to download OpenOffice like we want to
>>>> see
>>>> until the real release date is reached.
>>>
>>>
>>>> Thanks
>>>>
>>>> Marcus
>>>>
>>>>
>>>>
>>>> Sure, sites could still copy all binaries being voted upon and offer
>>>>>>> them locally, but this would require a more significant effort. on
>>>>>>> their
>>>>>>> side.
>>>>>>>
>>>>>> And more HDD space and more own bandwith - which is also not what they
>>>>>> want.
>>>>>>
>>>>>> Marcus
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
Re: Anything we can do about premature redistribution?
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 04/03/2014 11:12 PM, schrieb Roberto Galoppini:
> 2014-04-03 21:44 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>
>> Am 04/03/2014 12:57 PM, schrieb Jürgen Schmidt:
>>
>> On 4/3/14 12:09 PM, Roberto Galoppini wrote:
>>>
>>>> 2014-04-03 8:52 GMT+02:00 Jürgen Schmidt<jo...@gmail.com>:
>>>>
>>>> On 4/2/14 11:19 PM, Marcus (OOo) wrote:
>>>>>
>>>>>> Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:
>>>>>>
>>>>>>> 2014-04-02 21:15 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>>>
>>>>>>> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:
>>>>>>>>
>>>>>>>> 2014-04-01 21:30 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<ro...@apache.org>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Mon, Mar 31, 2014 at 4:43 PM, Marcus
>>>>>>>>>>> (OOo)<ma...@wtnet.de>
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<
>>>>>>>>>>>>> marcus.mail@wtnet.de>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Rob Weir wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Andrew's comments show clearly that these editors do
>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>> care
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>>>>>> careful or factual, or even read those disclaimers,
>>>>>>>>>>>>>>>>>> unfortunately.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> We can be successful only if we manage to block their
>>>>>>>>>>>>>>>>>> downloads.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> They
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> link to our binaries hosted on SourceForge (which is
>>>>>>>>>>>> fine). Just
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> thinking loud, but if it was possible (on the Sourceforge side)
>>>>>>>>>>>>>>
>>>>>>>>>>>>> to
>>>>>
>>>>>> deny
>>>>>>>>>>>>>>>>>> all download requests that do not come from the
>>>>>>>>>>>>>>>>>> openoffice.orgor
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> sourceforge.net domains, then the project would
>>>>>>>>>>>> effectively be
>>>>>>>>>>>>
>>>>>>>>>>> in
>>>>>
>>>>>>
>>>>>>>>>>>>> control. The embargo could be lifted just after the release.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> For me this sounds like a great idea.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Maybe we should start with denying all download requests
>>>>>>>>>>>>>>>>> that some
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> these bad websites.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> @Roberto:
>>>>>>>>>>>>>>>>> Can you tell us if this possible? If yes, is it much effort
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> for
>>>>>
>>>>>> you?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Do you see a chance to get this implemented? I think it
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> could
>>>>>
>>>>>> help to
>>>>>>>>>>>>>>>> stop some bad websites to do bad things with our software.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> @Roberto:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Maybe you haven't seen this up to now.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks for heads up Marcus, sorry for not having noticed
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> thread
>>>>>>>>>>>>>> before.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It would be great if you can tell us if it's possible to
>>>>>>>>>>>>>>
>>>>>>>>>>>>> exclude
>>>>>
>>>>>> some
>>>>>>>>>>>>>>> domains / IP addresses from downloading our software?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I need the domain list and I'll check out with our SiteOps
>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> that's
>>>>>>>>>>>>>> doable. Feel free to send me a list with a direct message.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> - chip.de
>>>>>>>>>>>>> - computerbase.de
>>>>>>>>>>>>> - softpedia.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> This would be the domains from this thread that could be blocked
>>>>>>>>>>>>> from
>>>>>>>>>>>>> downloading from Sourceforge. Obviously needs to be extended in
>>>>>>>>>>>>>
>>>>>>>>>>>> the
>>>>>
>>>>>>
>>>>>>>>>>>>> future.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Remember, the next will happen with the AOO 4.1.0 RC. ;-)
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Of course*, this is just for the time frame as long as the new
>>>>>>>>>>>>> version
>>>>>>>>>>>>>
>>>>>>>>>>>>> is
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> not officially announced. As soon as the release is public,
>>>>>>>>>>>> the
>>>>>>>>>>>> block
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> will
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> be removed.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> @all:
>>>>>>>>>>>>> I think this could help to limit the downloadability like we
>>>>>>>>>>>>> want to
>>>>>>>>>>>>> see
>>>>>>>>>>>>> until the official release. What you think?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don't know. Won't this just cause confusion? They point
>>>>>>>>>>>>> to
>>>>>>>>>>>>> the
>>>>>>>>>>>>>
>>>>>>>>>>>> files, go to test them, see the links don't work, and then get
>>>>>>>>>>>>
>>>>>>>>>>> weird
>>>>>
>>>>>> errors and spend an hour trying to debug it. We don't want to
>>>>>>>>>>>> needlessly annoy them, since their only fault is enthusiasm. Is
>>>>>>>>>>>> there a way we can give a useful error message in this case like,
>>>>>>>>>>>> "This version of Apache OpenOffice has not yet been officially
>>>>>>>>>>>> released. Links to these files are disallowed until the release
>>>>>>>>>>>> is
>>>>>>>>>>>> officially approved" or something like that?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> To be honest, I don't care about a few days were a special
>>>>>>>>>>> set of
>>>>>>>>>>>
>>>>>>>>>> domains
>>>>>>>>>> were not able to access for a few days. For me they are a bit too
>>>>>>>>>> enthusiastic. And as you said in a previous post it's to protect us
>>>>>>>>>>
>>>>>>>>> as
>>>>>
>>>>>> best
>>>>>>>>>> as possible.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> +1 This seems sufficient to me.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> @Roberto:
>>>>>>>>>> Do you see a technical way to return a predefined error message
>>>>>>>>>> when the
>>>>>>>>>> release builds are already on Sourceforge but not yet officially
>>>>>>>>>> released
>>>>>>>>>> and published?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Our SiteOps team looked into this, here our findings:
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Great :-)
>>>>>>>>
>>>>>>>>
>>>>>>>> One provider (chip.de) serves via Akamai CDN, one provider (
>>>>>>>>
>>>>>>>>> computerbase.de)
>>>>>>>>> serves via their own FTP server, and softpedia.com lists
>>>>>>>>> SourceForge
>>>>>>>>>
>>>>>>>> as
>>>>>
>>>>>> an
>>>>>>>>> external mirror and passes traffic through our download redirector
>>>>>>>>>
>>>>>>>> flow
>>>>>
>>>>>> (not direct to a mirror).
>>>>>>>>>
>>>>>>>>> The first two cases are things we can't control.
>>>>>>>>>
>>>>>>>>> In the third case, we can indeed redirect this traffic by referrer
>>>>>>>>> to
>>>>>>>>>
>>>>>>>> a
>>>>>
>>>>>> different landing page if one is provided. Maybe we want to have a
>>>>>>>>> openoffice.org page explaining that's a release-candidate and it's
>>>>>>>>> served
>>>>>>>>> only for testing purposes and its use on a daily basis it is not
>>>>>>>>> recommended.
>>>>>>>>>
>>>>>>>>> How does that sound?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I'm pretty sure that these kind of downloaders do not care about
>>>>>>>> disclaimers - less then ever when located somewhere else. ;-)
>>>>>>>>
>>>>>>>> So, either we disable the entire download for the specific timeframe
>>>>>>>> or at
>>>>>>>> least a text as substitute (like "This release is not yet public.
>>>>>>>>
>>>>>>> Please
>>>>>
>>>>>> stay tuned and come back when it is announced."). But this text has
>>>>>>>> then to
>>>>>>>> be on Sourceforge in the same location.
>>>>>>>>
>>>>>>>>
>>>>>>> Yes, that's doable in the way Kay described. And yes, we would add the
>>>>>>> text
>>>>>>> and disable downloads.
>>>>>>>
>>>>>>
>>>>>> Just to be sure, is this limited to a special subdir like
>>>>>> ".../files/milestones/"? Or also, additionally for ".../files/"?
>>>>>>
>>>>>> I'm wondering if the "staging" bit can help as best solution. I would
>>>>>>>> expect that the new location is not public *and* not known *and* not
>>>>>>>> useable/functional for the normal non-admin user *until* we remove
>>>>>>>> the bit.
>>>>>>>> Am I right?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> In past we extended the 'staging' period of time for weeks, this could
>>>>>>>
>>>>>> be
>>>>>
>>>>>> done again if necessary and it's definitely a more effective way to
>>>>>>>
>>>>>> share
>>>>>
>>>>>>
>>>>>> Good to know. I thought you had extended the timeframe permanentelly.
>>>>>> ;-)
>>>>>>
>>>>>> files only with a selected audience (admins). Would that work, or you
>>>>>>> want
>>>>>>> to be able to share those files with a larger audience?
>>>>>>>
>>>>>>
>>>>>> I don't think it's relevant to a wider audience.
>>>>>>
>>>>>> We still speak about the timeframe between starting uploading to
>>>>>> Sourceforge and the official announcement. Within this timeframe it
>>>>>> should be possible for admins to test the download webpage with
>>>>>> scripting - to see if it will work - but there must not be no way to
>>>>>> download the builds from the public.
>>>>>>
>>>>>> So, I would prefer to go with the "staging"-bit as:
>>>>>> - it is already available
>>>>>> - there is no confusion for the public
>>>>>> - it's easy to delete the bit to make the release public
>>>>>> - and (please don't get me wrong ;-) ) we can do it alone without the
>>>>>> help of you or someone else of Sourceforge.
>>>>>>
>>>>>> What do others think about this?
>>>>>>
>>>>>
>>>>> sounds ok to me, we should make it to complicate. It wasn't a big thing
>>>>> the last time and it shows the interest in AOO.
>>>>>
>>>>> How do I set the staging bit?
>>>>>
>>>>>
>>>> Hi Jurgen,
>>>>
>>>> Here you find more info: https://sourceforge.net/blog/staged-folders/
>>>>
>>>> About extending the staging period I'll make sure it is set to a custom
>>>> value for AOO, usually it's 3 days.
>>>>
>>>
>>> custom value sounds good, the question is then how we can influence this
>>> value.
>>>
>>
>> When looking at the screenshots in the blog post, the "3" could be
>> exchanged with a inputfield or dropdown list to enter/choose an own value.
>> The "3 days" could be the default value.
>>
>>
>> I see that the staging bit can be removed at any time via folder
>>> properties. Maybe a nice feature would be to simply allow a custom value
>>> here or to extend the staging period if the vote fails or other problems
>>> come up.
>>>
>>
>> Maybe it's possible to extend the 3 days to, hm, more days for now and
>> have the customize feature in the future.
>
>
>
> It's actually pre-set to 21 days, click on the 'i' and you'll read This
> file is staged until Thu, 24 Apr 2014 13:04:32 GMT .
> Again, if that's not enough I'll make sure to extend it further.
Ah, thanks for the hint, I've not seen this until now. :-)
For now the timeframe will be enough of course.
Marcus
>> Then we can exclude requester that we don't want (e.g., malware
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> "distributors").
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>> Also in time frames with Beta or RC releases it can help us to
>>>>>>>>>>>>>>> steer
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> who
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> is able and when it is possible to download OpenOffice like
>>>>>>>>>>>> we
>>>>>>>>>>>> want to
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> see
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> until the real release date is reached.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Marcus
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sure, sites could still copy all binaries being voted
>>>>>>>>>>>>>>> upon and
>>>>>>>>>>>>>>> offer
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> them locally, but this would require a more significant
>>>>>>>>>>>>>>>> effort. on
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>>>>> side.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And more HDD space and more own bandwith - which is also
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> not
>>>>>
>>>>>> what
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> want.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Roberto Galoppini <ro...@gmail.com>.
2014-04-03 21:44 GMT+02:00 Marcus (OOo) <ma...@wtnet.de>:
> Am 04/03/2014 12:57 PM, schrieb Jürgen Schmidt:
>
> On 4/3/14 12:09 PM, Roberto Galoppini wrote:
>>
>>> 2014-04-03 8:52 GMT+02:00 Jürgen Schmidt<jo...@gmail.com>:
>>>
>>> On 4/2/14 11:19 PM, Marcus (OOo) wrote:
>>>>
>>>>> Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:
>>>>>
>>>>>> 2014-04-02 21:15 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>>
>>>>>> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:
>>>>>>>
>>>>>>> 2014-04-01 21:30 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>>>
>>>>>>>>
>>>>>>>> Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<ro...@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Mon, Mar 31, 2014 at 4:43 PM, Marcus
>>>>>>>>>> (OOo)<ma...@wtnet.de>
>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<
>>>>>>>>>>>> marcus.mail@wtnet.de>:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Rob Weir wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Andrew's comments show clearly that these editors do
>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>> care
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>>>>> careful or factual, or even read those disclaimers,
>>>>>>>>>>>>>>>>> unfortunately.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We can be successful only if we manage to block their
>>>>>>>>>>>>>>>>> downloads.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> They
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> link to our binaries hosted on SourceForge (which is
>>>>>>>>>>> fine). Just
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> thinking loud, but if it was possible (on the Sourceforge side)
>>>>>>>>>>>>>
>>>>>>>>>>>> to
>>>>
>>>>> deny
>>>>>>>>>>>>>>>>> all download requests that do not come from the
>>>>>>>>>>>>>>>>> openoffice.orgor
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> sourceforge.net domains, then the project would
>>>>>>>>>>> effectively be
>>>>>>>>>>>
>>>>>>>>>> in
>>>>
>>>>>
>>>>>>>>>>>> control. The embargo could be lifted just after the release.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> For me this sounds like a great idea.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Maybe we should start with denying all download requests
>>>>>>>>>>>>>>>> that some
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> these bad websites.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> @Roberto:
>>>>>>>>>>>>>>>> Can you tell us if this possible? If yes, is it much effort
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> for
>>>>
>>>>> you?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Do you see a chance to get this implemented? I think it
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> could
>>>>
>>>>> help to
>>>>>>>>>>>>>>> stop some bad websites to do bad things with our software.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> @Roberto:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maybe you haven't seen this up to now.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for heads up Marcus, sorry for not having noticed
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>
>>>>>>>>>>>>> thread
>>>>>>>>>>>>> before.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It would be great if you can tell us if it's possible to
>>>>>>>>>>>>>
>>>>>>>>>>>> exclude
>>>>
>>>>> some
>>>>>>>>>>>>>> domains / IP addresses from downloading our software?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I need the domain list and I'll check out with our SiteOps
>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>
>>>>>>>>>>>>> that's
>>>>>>>>>>>>> doable. Feel free to send me a list with a direct message.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> - chip.de
>>>>>>>>>>>> - computerbase.de
>>>>>>>>>>>> - softpedia.com
>>>>>>>>>>>>
>>>>>>>>>>>> This would be the domains from this thread that could be blocked
>>>>>>>>>>>> from
>>>>>>>>>>>> downloading from Sourceforge. Obviously needs to be extended in
>>>>>>>>>>>>
>>>>>>>>>>> the
>>>>
>>>>>
>>>>>>>>>>>> future.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Remember, the next will happen with the AOO 4.1.0 RC. ;-)
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> *Of course*, this is just for the time frame as long as the new
>>>>>>>>>>>> version
>>>>>>>>>>>>
>>>>>>>>>>>> is
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> not officially announced. As soon as the release is public,
>>>>>>>>>>> the
>>>>>>>>>>> block
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> will
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> be removed.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> @all:
>>>>>>>>>>>> I think this could help to limit the downloadability like we
>>>>>>>>>>>> want to
>>>>>>>>>>>> see
>>>>>>>>>>>> until the official release. What you think?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I don't know. Won't this just cause confusion? They point
>>>>>>>>>>>> to
>>>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>> files, go to test them, see the links don't work, and then get
>>>>>>>>>>>
>>>>>>>>>> weird
>>>>
>>>>> errors and spend an hour trying to debug it. We don't want to
>>>>>>>>>>> needlessly annoy them, since their only fault is enthusiasm. Is
>>>>>>>>>>> there a way we can give a useful error message in this case like,
>>>>>>>>>>> "This version of Apache OpenOffice has not yet been officially
>>>>>>>>>>> released. Links to these files are disallowed until the release
>>>>>>>>>>> is
>>>>>>>>>>> officially approved" or something like that?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> To be honest, I don't care about a few days were a special
>>>>>>>>>> set of
>>>>>>>>>>
>>>>>>>>> domains
>>>>>>>>> were not able to access for a few days. For me they are a bit too
>>>>>>>>> enthusiastic. And as you said in a previous post it's to protect us
>>>>>>>>>
>>>>>>>> as
>>>>
>>>>> best
>>>>>>>>> as possible.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> +1 This seems sufficient to me.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> @Roberto:
>>>>>>>>> Do you see a technical way to return a predefined error message
>>>>>>>>> when the
>>>>>>>>> release builds are already on Sourceforge but not yet officially
>>>>>>>>> released
>>>>>>>>> and published?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Our SiteOps team looked into this, here our findings:
>>>>>>>>
>>>>>>>>
>>>>>>> Great :-)
>>>>>>>
>>>>>>>
>>>>>>> One provider (chip.de) serves via Akamai CDN, one provider (
>>>>>>>
>>>>>>>> computerbase.de)
>>>>>>>> serves via their own FTP server, and softpedia.com lists
>>>>>>>> SourceForge
>>>>>>>>
>>>>>>> as
>>>>
>>>>> an
>>>>>>>> external mirror and passes traffic through our download redirector
>>>>>>>>
>>>>>>> flow
>>>>
>>>>> (not direct to a mirror).
>>>>>>>>
>>>>>>>> The first two cases are things we can't control.
>>>>>>>>
>>>>>>>> In the third case, we can indeed redirect this traffic by referrer
>>>>>>>> to
>>>>>>>>
>>>>>>> a
>>>>
>>>>> different landing page if one is provided. Maybe we want to have a
>>>>>>>> openoffice.org page explaining that's a release-candidate and it's
>>>>>>>> served
>>>>>>>> only for testing purposes and its use on a daily basis it is not
>>>>>>>> recommended.
>>>>>>>>
>>>>>>>> How does that sound?
>>>>>>>>
>>>>>>>>
>>>>>>> I'm pretty sure that these kind of downloaders do not care about
>>>>>>> disclaimers - less then ever when located somewhere else. ;-)
>>>>>>>
>>>>>>> So, either we disable the entire download for the specific timeframe
>>>>>>> or at
>>>>>>> least a text as substitute (like "This release is not yet public.
>>>>>>>
>>>>>> Please
>>>>
>>>>> stay tuned and come back when it is announced."). But this text has
>>>>>>> then to
>>>>>>> be on Sourceforge in the same location.
>>>>>>>
>>>>>>>
>>>>>> Yes, that's doable in the way Kay described. And yes, we would add the
>>>>>> text
>>>>>> and disable downloads.
>>>>>>
>>>>>
>>>>> Just to be sure, is this limited to a special subdir like
>>>>> ".../files/milestones/"? Or also, additionally for ".../files/"?
>>>>>
>>>>> I'm wondering if the "staging" bit can help as best solution. I would
>>>>>>> expect that the new location is not public *and* not known *and* not
>>>>>>> useable/functional for the normal non-admin user *until* we remove
>>>>>>> the bit.
>>>>>>> Am I right?
>>>>>>>
>>>>>>
>>>>>>
>>>>>> In past we extended the 'staging' period of time for weeks, this could
>>>>>>
>>>>> be
>>>>
>>>>> done again if necessary and it's definitely a more effective way to
>>>>>>
>>>>> share
>>>>
>>>>>
>>>>> Good to know. I thought you had extended the timeframe permanentelly.
>>>>> ;-)
>>>>>
>>>>> files only with a selected audience (admins). Would that work, or you
>>>>>> want
>>>>>> to be able to share those files with a larger audience?
>>>>>>
>>>>>
>>>>> I don't think it's relevant to a wider audience.
>>>>>
>>>>> We still speak about the timeframe between starting uploading to
>>>>> Sourceforge and the official announcement. Within this timeframe it
>>>>> should be possible for admins to test the download webpage with
>>>>> scripting - to see if it will work - but there must not be no way to
>>>>> download the builds from the public.
>>>>>
>>>>> So, I would prefer to go with the "staging"-bit as:
>>>>> - it is already available
>>>>> - there is no confusion for the public
>>>>> - it's easy to delete the bit to make the release public
>>>>> - and (please don't get me wrong ;-) ) we can do it alone without the
>>>>> help of you or someone else of Sourceforge.
>>>>>
>>>>> What do others think about this?
>>>>>
>>>>
>>>> sounds ok to me, we should make it to complicate. It wasn't a big thing
>>>> the last time and it shows the interest in AOO.
>>>>
>>>> How do I set the staging bit?
>>>>
>>>>
>>> Hi Jurgen,
>>>
>>> Here you find more info: https://sourceforge.net/blog/staged-folders/
>>>
>>> About extending the staging period I'll make sure it is set to a custom
>>> value for AOO, usually it's 3 days.
>>>
>>
>> custom value sounds good, the question is then how we can influence this
>> value.
>>
>
> When looking at the screenshots in the blog post, the "3" could be
> exchanged with a inputfield or dropdown list to enter/choose an own value.
> The "3 days" could be the default value.
>
>
> I see that the staging bit can be removed at any time via folder
>> properties. Maybe a nice feature would be to simply allow a custom value
>> here or to extend the staging period if the vote fails or other problems
>> come up.
>>
>
> Maybe it's possible to extend the 3 days to, hm, more days for now and
> have the customize feature in the future.
It's actually pre-set to 21 days, click on the 'i' and you'll read This
file is staged until Thu, 24 Apr 2014 13:04:32 GMT .
Again, if that's not enough I'll make sure to extend it further.
Roberto
>
> Marcus
>
>
>
> Then we can exclude requester that we don't want (e.g., malware
>>>>>>>
>>>>>>>>
>>>>>>>>> "distributors").
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> Also in time frames with Beta or RC releases it can help us to
>>>>>>>>>>>>>> steer
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> who
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> is able and when it is possible to download OpenOffice like
>>>>>>>>>>> we
>>>>>>>>>>> want to
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> see
>>>>>>>>>>>>>
>>>>>>>>>>>>>> until the real release date is reached.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Marcus
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sure, sites could still copy all binaries being voted
>>>>>>>>>>>>>> upon and
>>>>>>>>>>>>>> offer
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> them locally, but this would require a more significant
>>>>>>>>>>>>>>> effort. on
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>>>> side.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And more HDD space and more own bandwith - which is also
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> not
>>>>
>>>>> what
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> want.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Marcus
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Anything we can do about premature redistribution?
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 04/03/2014 12:57 PM, schrieb Jürgen Schmidt:
> On 4/3/14 12:09 PM, Roberto Galoppini wrote:
>> 2014-04-03 8:52 GMT+02:00 Jürgen Schmidt<jo...@gmail.com>:
>>
>>> On 4/2/14 11:19 PM, Marcus (OOo) wrote:
>>>> Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:
>>>>> 2014-04-02 21:15 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>
>>>>>> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:
>>>>>>
>>>>>> 2014-04-01 21:30 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>>>
>>>>>>> Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
>>>>>>>>
>>>>>>>> On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<ro...@apache.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Mar 31, 2014 at 4:43 PM, Marcus
>>>>>>>>> (OOo)<ma...@wtnet.de>
>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
>>>>>>>>>>>
>>>>>>>>>>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Rob Weir wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Andrew's comments show clearly that these editors do not
>>>>>>>>>>>>>>>>> care
>>>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>>>> careful or factual, or even read those disclaimers,
>>>>>>>>>>>>>>>> unfortunately.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We can be successful only if we manage to block their
>>>>>>>>>>>>>>>> downloads.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> They
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>> link to our binaries hosted on SourceForge (which is fine). Just
>>>>>>>>>>>
>>>>>>>>>>>> thinking loud, but if it was possible (on the Sourceforge side)
>>> to
>>>>>>>>>>>>>>>> deny
>>>>>>>>>>>>>>>> all download requests that do not come from the
>>>>>>>>>>>>>>>> openoffice.orgor
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>> sourceforge.net domains, then the project would effectively be
>>> in
>>>>>>>>>>>
>>>>>>>>>>>> control. The embargo could be lifted just after the release.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> For me this sounds like a great idea.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Maybe we should start with denying all download requests
>>>>>>>>>>>>>>> that some
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> these bad websites.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>> @Roberto:
>>>>>>>>>>>>>>> Can you tell us if this possible? If yes, is it much effort
>>> for
>>>>>>>>>>>>>>> you?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Do you see a chance to get this implemented? I think it
>>> could
>>>>>>>>>>>>>> help to
>>>>>>>>>>>>>> stop some bad websites to do bad things with our software.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> @Roberto:
>>>>>>>>>>>>> Maybe you haven't seen this up to now.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for heads up Marcus, sorry for not having noticed this
>>>>>>>>>>>> thread
>>>>>>>>>>>> before.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It would be great if you can tell us if it's possible to
>>> exclude
>>>>>>>>>>>>> some
>>>>>>>>>>>>> domains / IP addresses from downloading our software?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I need the domain list and I'll check out with our SiteOps if
>>>>>>>>>>>> that's
>>>>>>>>>>>> doable. Feel free to send me a list with a direct message.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - chip.de
>>>>>>>>>>> - computerbase.de
>>>>>>>>>>> - softpedia.com
>>>>>>>>>>>
>>>>>>>>>>> This would be the domains from this thread that could be blocked
>>>>>>>>>>> from
>>>>>>>>>>> downloading from Sourceforge. Obviously needs to be extended in
>>> the
>>>>>>>>>>>
>>>>>>>>>>> future.
>>>>>>>>>>
>>>>>>>>>> Remember, the next will happen with the AOO 4.1.0 RC. ;-)
>>>>>>>>>>>
>>>>>>>>>>> *Of course*, this is just for the time frame as long as the new
>>>>>>>>>>> version
>>>>>>>>>>>
>>>>>>>>>>> is
>>>>>>>>>>
>>>>>>>>>> not officially announced. As soon as the release is public, the
>>>>>>>>>> block
>>>>>>>>>>>
>>>>>>>>>>> will
>>>>>>>>>>
>>>>>>>>>> be removed.
>>>>>>>>>>>
>>>>>>>>>>> @all:
>>>>>>>>>>> I think this could help to limit the downloadability like we
>>>>>>>>>>> want to
>>>>>>>>>>> see
>>>>>>>>>>> until the official release. What you think?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I don't know. Won't this just cause confusion? They point to
>>>>>>>>>>> the
>>>>>>>>>> files, go to test them, see the links don't work, and then get
>>> weird
>>>>>>>>>> errors and spend an hour trying to debug it. We don't want to
>>>>>>>>>> needlessly annoy them, since their only fault is enthusiasm. Is
>>>>>>>>>> there a way we can give a useful error message in this case like,
>>>>>>>>>> "This version of Apache OpenOffice has not yet been officially
>>>>>>>>>> released. Links to these files are disallowed until the release is
>>>>>>>>>> officially approved" or something like that?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> To be honest, I don't care about a few days were a special set of
>>>>>>>> domains
>>>>>>>> were not able to access for a few days. For me they are a bit too
>>>>>>>> enthusiastic. And as you said in a previous post it's to protect us
>>> as
>>>>>>>> best
>>>>>>>> as possible.
>>>>>>>>
>>>>>>>>
>>>>>>>> +1 This seems sufficient to me.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> @Roberto:
>>>>>>>> Do you see a technical way to return a predefined error message
>>>>>>>> when the
>>>>>>>> release builds are already on Sourceforge but not yet officially
>>>>>>>> released
>>>>>>>> and published?
>>>>>>>>
>>>>>>>>
>>>>>>> Our SiteOps team looked into this, here our findings:
>>>>>>>
>>>>>>
>>>>>> Great :-)
>>>>>>
>>>>>>
>>>>>> One provider (chip.de) serves via Akamai CDN, one provider (
>>>>>>> computerbase.de)
>>>>>>> serves via their own FTP server, and softpedia.com lists SourceForge
>>> as
>>>>>>> an
>>>>>>> external mirror and passes traffic through our download redirector
>>> flow
>>>>>>> (not direct to a mirror).
>>>>>>>
>>>>>>> The first two cases are things we can't control.
>>>>>>>
>>>>>>> In the third case, we can indeed redirect this traffic by referrer to
>>> a
>>>>>>> different landing page if one is provided. Maybe we want to have a
>>>>>>> openoffice.org page explaining that's a release-candidate and it's
>>>>>>> served
>>>>>>> only for testing purposes and its use on a daily basis it is not
>>>>>>> recommended.
>>>>>>>
>>>>>>> How does that sound?
>>>>>>>
>>>>>>
>>>>>> I'm pretty sure that these kind of downloaders do not care about
>>>>>> disclaimers - less then ever when located somewhere else. ;-)
>>>>>>
>>>>>> So, either we disable the entire download for the specific timeframe
>>>>>> or at
>>>>>> least a text as substitute (like "This release is not yet public.
>>> Please
>>>>>> stay tuned and come back when it is announced."). But this text has
>>>>>> then to
>>>>>> be on Sourceforge in the same location.
>>>>>>
>>>>>
>>>>> Yes, that's doable in the way Kay described. And yes, we would add the
>>>>> text
>>>>> and disable downloads.
>>>>
>>>> Just to be sure, is this limited to a special subdir like
>>>> ".../files/milestones/"? Or also, additionally for ".../files/"?
>>>>
>>>>>> I'm wondering if the "staging" bit can help as best solution. I would
>>>>>> expect that the new location is not public *and* not known *and* not
>>>>>> useable/functional for the normal non-admin user *until* we remove
>>>>>> the bit.
>>>>>> Am I right?
>>>>>
>>>>>
>>>>> In past we extended the 'staging' period of time for weeks, this could
>>> be
>>>>> done again if necessary and it's definitely a more effective way to
>>> share
>>>>
>>>> Good to know. I thought you had extended the timeframe permanentelly. ;-)
>>>>
>>>>> files only with a selected audience (admins). Would that work, or you
>>>>> want
>>>>> to be able to share those files with a larger audience?
>>>>
>>>> I don't think it's relevant to a wider audience.
>>>>
>>>> We still speak about the timeframe between starting uploading to
>>>> Sourceforge and the official announcement. Within this timeframe it
>>>> should be possible for admins to test the download webpage with
>>>> scripting - to see if it will work - but there must not be no way to
>>>> download the builds from the public.
>>>>
>>>> So, I would prefer to go with the "staging"-bit as:
>>>> - it is already available
>>>> - there is no confusion for the public
>>>> - it's easy to delete the bit to make the release public
>>>> - and (please don't get me wrong ;-) ) we can do it alone without the
>>>> help of you or someone else of Sourceforge.
>>>>
>>>> What do others think about this?
>>>
>>> sounds ok to me, we should make it to complicate. It wasn't a big thing
>>> the last time and it shows the interest in AOO.
>>>
>>> How do I set the staging bit?
>>>
>>
>> Hi Jurgen,
>>
>> Here you find more info: https://sourceforge.net/blog/staged-folders/
>>
>> About extending the staging period I'll make sure it is set to a custom
>> value for AOO, usually it's 3 days.
>
> custom value sounds good, the question is then how we can influence this
> value.
When looking at the screenshots in the blog post, the "3" could be
exchanged with a inputfield or dropdown list to enter/choose an own
value. The "3 days" could be the default value.
> I see that the staging bit can be removed at any time via folder
> properties. Maybe a nice feature would be to simply allow a custom value
> here or to extend the staging period if the vote fails or other problems
> come up.
Maybe it's possible to extend the 3 days to, hm, more days for now and
have the customize feature in the future.
Marcus
>>>>>> Then we can exclude requester that we don't want (e.g., malware
>>>>>>>>
>>>>>>>>> "distributors").
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also in time frames with Beta or RC releases it can help us to
>>>>>>>>>>>>> steer
>>>>>>>>>>>>>
>>>>>>>>>>>>> who
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> is able and when it is possible to download OpenOffice like we
>>>>>>>>>> want to
>>>>>>>>>>>
>>>>>>>>>>>> see
>>>>>>>>>>>>> until the real release date is reached.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Marcus
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sure, sites could still copy all binaries being voted
>>>>>>>>>>>>> upon and
>>>>>>>>>>>>> offer
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> them locally, but this would require a more significant
>>>>>>>>>>>>>> effort. on
>>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>>> side.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And more HDD space and more own bandwith - which is also
>>> not
>>>>>>>>>>>>>>> what
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> want.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>> Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 4/3/14 12:09 PM, Roberto Galoppini wrote:
> 2014-04-03 8:52 GMT+02:00 Jürgen Schmidt <jo...@gmail.com>:
>
>> On 4/2/14 11:19 PM, Marcus (OOo) wrote:
>>> Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:
>>>> 2014-04-02 21:15 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>
>>>>> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:
>>>>>
>>>>> 2014-04-01 21:30 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>>
>>>>>> Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
>>>>>>>
>>>>>>> On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<ro...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Mar 31, 2014 at 4:43 PM, Marcus
>>>>>>>> (OOo)<ma...@wtnet.de>
>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
>>>>>>>>>>
>>>>>>>>>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Rob Weir wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Andrew's comments show clearly that these editors do not
>>>>>>>>>>>>>>>> care
>>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>>> careful or factual, or even read those disclaimers,
>>>>>>>>>>>>>>> unfortunately.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We can be successful only if we manage to block their
>>>>>>>>>>>>>>> downloads.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> They
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>> link to our binaries hosted on SourceForge (which is fine). Just
>>>>>>>>>>
>>>>>>>>>>> thinking loud, but if it was possible (on the Sourceforge side)
>> to
>>>>>>>>>>>>>>> deny
>>>>>>>>>>>>>>> all download requests that do not come from the
>>>>>>>>>>>>>>> openoffice.orgor
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>> sourceforge.net domains, then the project would effectively be
>> in
>>>>>>>>>>
>>>>>>>>>>> control. The embargo could be lifted just after the release.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For me this sounds like a great idea.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maybe we should start with denying all download requests
>>>>>>>>>>>>>> that some
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> from
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> these bad websites.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> @Roberto:
>>>>>>>>>>>>>> Can you tell us if this possible? If yes, is it much effort
>> for
>>>>>>>>>>>>>> you?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Do you see a chance to get this implemented? I think it
>> could
>>>>>>>>>>>>> help to
>>>>>>>>>>>>> stop some bad websites to do bad things with our software.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> @Roberto:
>>>>>>>>>>>> Maybe you haven't seen this up to now.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for heads up Marcus, sorry for not having noticed this
>>>>>>>>>>> thread
>>>>>>>>>>> before.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It would be great if you can tell us if it's possible to
>> exclude
>>>>>>>>>>>> some
>>>>>>>>>>>> domains / IP addresses from downloading our software?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I need the domain list and I'll check out with our SiteOps if
>>>>>>>>>>> that's
>>>>>>>>>>> doable. Feel free to send me a list with a direct message.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> - chip.de
>>>>>>>>>> - computerbase.de
>>>>>>>>>> - softpedia.com
>>>>>>>>>>
>>>>>>>>>> This would be the domains from this thread that could be blocked
>>>>>>>>>> from
>>>>>>>>>> downloading from Sourceforge. Obviously needs to be extended in
>> the
>>>>>>>>>>
>>>>>>>>>> future.
>>>>>>>>>
>>>>>>>>> Remember, the next will happen with the AOO 4.1.0 RC. ;-)
>>>>>>>>>>
>>>>>>>>>> *Of course*, this is just for the time frame as long as the new
>>>>>>>>>> version
>>>>>>>>>>
>>>>>>>>>> is
>>>>>>>>>
>>>>>>>>> not officially announced. As soon as the release is public, the
>>>>>>>>> block
>>>>>>>>>>
>>>>>>>>>> will
>>>>>>>>>
>>>>>>>>> be removed.
>>>>>>>>>>
>>>>>>>>>> @all:
>>>>>>>>>> I think this could help to limit the downloadability like we
>>>>>>>>>> want to
>>>>>>>>>> see
>>>>>>>>>> until the official release. What you think?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I don't know. Won't this just cause confusion? They point to
>>>>>>>>>> the
>>>>>>>>> files, go to test them, see the links don't work, and then get
>> weird
>>>>>>>>> errors and spend an hour trying to debug it. We don't want to
>>>>>>>>> needlessly annoy them, since their only fault is enthusiasm. Is
>>>>>>>>> there a way we can give a useful error message in this case like,
>>>>>>>>> "This version of Apache OpenOffice has not yet been officially
>>>>>>>>> released. Links to these files are disallowed until the release is
>>>>>>>>> officially approved" or something like that?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> To be honest, I don't care about a few days were a special set of
>>>>>>> domains
>>>>>>> were not able to access for a few days. For me they are a bit too
>>>>>>> enthusiastic. And as you said in a previous post it's to protect us
>> as
>>>>>>> best
>>>>>>> as possible.
>>>>>>>
>>>>>>>
>>>>>>> +1 This seems sufficient to me.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> @Roberto:
>>>>>>> Do you see a technical way to return a predefined error message
>>>>>>> when the
>>>>>>> release builds are already on Sourceforge but not yet officially
>>>>>>> released
>>>>>>> and published?
>>>>>>>
>>>>>>>
>>>>>> Our SiteOps team looked into this, here our findings:
>>>>>>
>>>>>
>>>>> Great :-)
>>>>>
>>>>>
>>>>> One provider (chip.de) serves via Akamai CDN, one provider (
>>>>>> computerbase.de)
>>>>>> serves via their own FTP server, and softpedia.com lists SourceForge
>> as
>>>>>> an
>>>>>> external mirror and passes traffic through our download redirector
>> flow
>>>>>> (not direct to a mirror).
>>>>>>
>>>>>> The first two cases are things we can't control.
>>>>>>
>>>>>> In the third case, we can indeed redirect this traffic by referrer to
>> a
>>>>>> different landing page if one is provided. Maybe we want to have a
>>>>>> openoffice.org page explaining that's a release-candidate and it's
>>>>>> served
>>>>>> only for testing purposes and its use on a daily basis it is not
>>>>>> recommended.
>>>>>>
>>>>>> How does that sound?
>>>>>>
>>>>>
>>>>> I'm pretty sure that these kind of downloaders do not care about
>>>>> disclaimers - less then ever when located somewhere else. ;-)
>>>>>
>>>>> So, either we disable the entire download for the specific timeframe
>>>>> or at
>>>>> least a text as substitute (like "This release is not yet public.
>> Please
>>>>> stay tuned and come back when it is announced."). But this text has
>>>>> then to
>>>>> be on Sourceforge in the same location.
>>>>>
>>>>
>>>> Yes, that's doable in the way Kay described. And yes, we would add the
>>>> text
>>>> and disable downloads.
>>>
>>> Just to be sure, is this limited to a special subdir like
>>> ".../files/milestones/"? Or also, additionally for ".../files/"?
>>>
>>>>> I'm wondering if the "staging" bit can help as best solution. I would
>>>>> expect that the new location is not public *and* not known *and* not
>>>>> useable/functional for the normal non-admin user *until* we remove
>>>>> the bit.
>>>>> Am I right?
>>>>
>>>>
>>>> In past we extended the 'staging' period of time for weeks, this could
>> be
>>>> done again if necessary and it's definitely a more effective way to
>> share
>>>
>>> Good to know. I thought you had extended the timeframe permanentelly. ;-)
>>>
>>>> files only with a selected audience (admins). Would that work, or you
>>>> want
>>>> to be able to share those files with a larger audience?
>>>
>>> I don't think it's relevant to a wider audience.
>>>
>>> We still speak about the timeframe between starting uploading to
>>> Sourceforge and the official announcement. Within this timeframe it
>>> should be possible for admins to test the download webpage with
>>> scripting - to see if it will work - but there must not be no way to
>>> download the builds from the public.
>>>
>>> So, I would prefer to go with the "staging"-bit as:
>>> - it is already available
>>> - there is no confusion for the public
>>> - it's easy to delete the bit to make the release public
>>> - and (please don't get me wrong ;-) ) we can do it alone without the
>>> help of you or someone else of Sourceforge.
>>>
>>> What do others think about this?
>>
>> sounds ok to me, we should make it to complicate. It wasn't a big thing
>> the last time and it shows the interest in AOO.
>>
>> How do I set the staging bit?
>>
>
> Hi Jurgen,
>
> Here you find more info: https://sourceforge.net/blog/staged-folders/
>
> About extending the staging period I'll make sure it is set to a custom
> value for AOO, usually it's 3 days.
custom value sounds good, the question is then how we can influence this
value.
I see that the staging bit can be removed at any time via folder
properties. Maybe a nice feature would be to simply allow a custom value
here or to extend the staging period if the vote fails or other problems
come up.
Juergen
>
> Let me know if you need assistance or help.
>
> Roberto
>
>
>
>>
>> Juergen
>>
>>
>>>
>>> Thanks
>>>
>>> Marcus
>>>
>>>
>>>
>>>>> Then we can exclude requester that we don't want (e.g., malware
>>>>>>>
>>>>>>>> "distributors").
>>>>>>>>>>>>
>>>>>>>>>>>> Also in time frames with Beta or RC releases it can help us to
>>>>>>>>>>>> steer
>>>>>>>>>>>>
>>>>>>>>>>>> who
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> is able and when it is possible to download OpenOffice like we
>>>>>>>>> want to
>>>>>>>>>>
>>>>>>>>>>> see
>>>>>>>>>>>> until the real release date is reached.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Marcus
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Sure, sites could still copy all binaries being voted
>>>>>>>>>>>> upon and
>>>>>>>>>>>> offer
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> them locally, but this would require a more significant
>>>>>>>>>>>>> effort. on
>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>> side.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And more HDD space and more own bandwith - which is also
>> not
>>>>>>>>>>>>>> what
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> they
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> want.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> Marcus
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Roberto Galoppini <ro...@gmail.com>.
2014-04-03 8:52 GMT+02:00 Jürgen Schmidt <jo...@gmail.com>:
> On 4/2/14 11:19 PM, Marcus (OOo) wrote:
> > Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:
> >> 2014-04-02 21:15 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
> >>
> >>> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:
> >>>
> >>> 2014-04-01 21:30 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
> >>>>
> >>>> Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
> >>>>>
> >>>>> On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<ro...@apache.org>
> >>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>> On Mon, Mar 31, 2014 at 4:43 PM, Marcus
> >>>>>> (OOo)<ma...@wtnet.de>
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
> >>>>>>>>
> >>>>>>>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<ma...@wtnet.de>:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Rob Weir wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Apache-OpenOffice-253.shtml
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Andrew's comments show clearly that these editors do not
> >>>>>>>>>>>>>> care
> >>>>>>>>>>>>> to be
> >>>>>>>>>>>>> careful or factual, or even read those disclaimers,
> >>>>>>>>>>>>> unfortunately.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> We can be successful only if we manage to block their
> >>>>>>>>>>>>> downloads.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> They
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> link to our binaries hosted on SourceForge (which is fine). Just
> >>>>>>>>
> >>>>>>>>> thinking loud, but if it was possible (on the Sourceforge side)
> to
> >>>>>>>>>>>>> deny
> >>>>>>>>>>>>> all download requests that do not come from the
> >>>>>>>>>>>>> openoffice.orgor
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> sourceforge.net domains, then the project would effectively be
> in
> >>>>>>>>
> >>>>>>>>> control. The embargo could be lifted just after the release.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> For me this sounds like a great idea.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Maybe we should start with denying all download requests
> >>>>>>>>>>>> that some
> >>>>>>>>>>>>
> >>>>>>>>>>>> from
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> these bad websites.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>> @Roberto:
> >>>>>>>>>>>> Can you tell us if this possible? If yes, is it much effort
> for
> >>>>>>>>>>>> you?
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Do you see a chance to get this implemented? I think it
> could
> >>>>>>>>>>> help to
> >>>>>>>>>>> stop some bad websites to do bad things with our software.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> @Roberto:
> >>>>>>>>>> Maybe you haven't seen this up to now.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Thanks for heads up Marcus, sorry for not having noticed this
> >>>>>>>>> thread
> >>>>>>>>> before.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> It would be great if you can tell us if it's possible to
> exclude
> >>>>>>>>>> some
> >>>>>>>>>> domains / IP addresses from downloading our software?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I need the domain list and I'll check out with our SiteOps if
> >>>>>>>>> that's
> >>>>>>>>> doable. Feel free to send me a list with a direct message.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> - chip.de
> >>>>>>>> - computerbase.de
> >>>>>>>> - softpedia.com
> >>>>>>>>
> >>>>>>>> This would be the domains from this thread that could be blocked
> >>>>>>>> from
> >>>>>>>> downloading from Sourceforge. Obviously needs to be extended in
> the
> >>>>>>>>
> >>>>>>>> future.
> >>>>>>>
> >>>>>>> Remember, the next will happen with the AOO 4.1.0 RC. ;-)
> >>>>>>>>
> >>>>>>>> *Of course*, this is just for the time frame as long as the new
> >>>>>>>> version
> >>>>>>>>
> >>>>>>>> is
> >>>>>>>
> >>>>>>> not officially announced. As soon as the release is public, the
> >>>>>>> block
> >>>>>>>>
> >>>>>>>> will
> >>>>>>>
> >>>>>>> be removed.
> >>>>>>>>
> >>>>>>>> @all:
> >>>>>>>> I think this could help to limit the downloadability like we
> >>>>>>>> want to
> >>>>>>>> see
> >>>>>>>> until the official release. What you think?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I don't know. Won't this just cause confusion? They point to
> >>>>>>>> the
> >>>>>>> files, go to test them, see the links don't work, and then get
> weird
> >>>>>>> errors and spend an hour trying to debug it. We don't want to
> >>>>>>> needlessly annoy them, since their only fault is enthusiasm. Is
> >>>>>>> there a way we can give a useful error message in this case like,
> >>>>>>> "This version of Apache OpenOffice has not yet been officially
> >>>>>>> released. Links to these files are disallowed until the release is
> >>>>>>> officially approved" or something like that?
> >>>>>>>
> >>>>>>>
> >>>>>> To be honest, I don't care about a few days were a special set of
> >>>>> domains
> >>>>> were not able to access for a few days. For me they are a bit too
> >>>>> enthusiastic. And as you said in a previous post it's to protect us
> as
> >>>>> best
> >>>>> as possible.
> >>>>>
> >>>>>
> >>>>> +1 This seems sufficient to me.
> >>>>>
> >>>>>>
> >>>>>>
> >>>>> @Roberto:
> >>>>> Do you see a technical way to return a predefined error message
> >>>>> when the
> >>>>> release builds are already on Sourceforge but not yet officially
> >>>>> released
> >>>>> and published?
> >>>>>
> >>>>>
> >>>> Our SiteOps team looked into this, here our findings:
> >>>>
> >>>
> >>> Great :-)
> >>>
> >>>
> >>> One provider (chip.de) serves via Akamai CDN, one provider (
> >>>> computerbase.de)
> >>>> serves via their own FTP server, and softpedia.com lists SourceForge
> as
> >>>> an
> >>>> external mirror and passes traffic through our download redirector
> flow
> >>>> (not direct to a mirror).
> >>>>
> >>>> The first two cases are things we can't control.
> >>>>
> >>>> In the third case, we can indeed redirect this traffic by referrer to
> a
> >>>> different landing page if one is provided. Maybe we want to have a
> >>>> openoffice.org page explaining that's a release-candidate and it's
> >>>> served
> >>>> only for testing purposes and its use on a daily basis it is not
> >>>> recommended.
> >>>>
> >>>> How does that sound?
> >>>>
> >>>
> >>> I'm pretty sure that these kind of downloaders do not care about
> >>> disclaimers - less then ever when located somewhere else. ;-)
> >>>
> >>> So, either we disable the entire download for the specific timeframe
> >>> or at
> >>> least a text as substitute (like "This release is not yet public.
> Please
> >>> stay tuned and come back when it is announced."). But this text has
> >>> then to
> >>> be on Sourceforge in the same location.
> >>>
> >>
> >> Yes, that's doable in the way Kay described. And yes, we would add the
> >> text
> >> and disable downloads.
> >
> > Just to be sure, is this limited to a special subdir like
> > ".../files/milestones/"? Or also, additionally for ".../files/"?
> >
> >>> I'm wondering if the "staging" bit can help as best solution. I would
> >>> expect that the new location is not public *and* not known *and* not
> >>> useable/functional for the normal non-admin user *until* we remove
> >>> the bit.
> >>> Am I right?
> >>
> >>
> >> In past we extended the 'staging' period of time for weeks, this could
> be
> >> done again if necessary and it's definitely a more effective way to
> share
> >
> > Good to know. I thought you had extended the timeframe permanentelly. ;-)
> >
> >> files only with a selected audience (admins). Would that work, or you
> >> want
> >> to be able to share those files with a larger audience?
> >
> > I don't think it's relevant to a wider audience.
> >
> > We still speak about the timeframe between starting uploading to
> > Sourceforge and the official announcement. Within this timeframe it
> > should be possible for admins to test the download webpage with
> > scripting - to see if it will work - but there must not be no way to
> > download the builds from the public.
> >
> > So, I would prefer to go with the "staging"-bit as:
> > - it is already available
> > - there is no confusion for the public
> > - it's easy to delete the bit to make the release public
> > - and (please don't get me wrong ;-) ) we can do it alone without the
> > help of you or someone else of Sourceforge.
> >
> > What do others think about this?
>
> sounds ok to me, we should make it to complicate. It wasn't a big thing
> the last time and it shows the interest in AOO.
>
> How do I set the staging bit?
>
Hi Jurgen,
Here you find more info: https://sourceforge.net/blog/staged-folders/
About extending the staging period I'll make sure it is set to a custom
value for AOO, usually it's 3 days.
Let me know if you need assistance or help.
Roberto
>
> Juergen
>
>
> >
> > Thanks
> >
> > Marcus
> >
> >
> >
> >>> Then we can exclude requester that we don't want (e.g., malware
> >>>>>
> >>>>>> "distributors").
> >>>>>>>>>>
> >>>>>>>>>> Also in time frames with Beta or RC releases it can help us to
> >>>>>>>>>> steer
> >>>>>>>>>>
> >>>>>>>>>> who
> >>>>>>>>>
> >>>>>>>>
> >>>>>>> is able and when it is possible to download OpenOffice like we
> >>>>>>> want to
> >>>>>>>>
> >>>>>>>>> see
> >>>>>>>>>> until the real release date is reached.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thanks
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Marcus
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Sure, sites could still copy all binaries being voted
> >>>>>>>>>> upon and
> >>>>>>>>>> offer
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> them locally, but this would require a more significant
> >>>>>>>>>>> effort. on
> >>>>>>>>>>>>> their
> >>>>>>>>>>>>> side.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> And more HDD space and more own bandwith - which is also
> not
> >>>>>>>>>>>> what
> >>>>>>>>>>>>
> >>>>>>>>>>>> they
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> want.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>> Marcus
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Anything we can do about premature redistribution?
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 4/2/14 11:19 PM, Marcus (OOo) wrote:
> Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:
>> 2014-04-02 21:15 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>
>>> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:
>>>
>>> 2014-04-01 21:30 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>
>>>> Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
>>>>>
>>>>> On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<ro...@apache.org>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Mon, Mar 31, 2014 at 4:43 PM, Marcus
>>>>>> (OOo)<ma...@wtnet.de>
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
>>>>>>>>
>>>>>>>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Rob Weir wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Andrew's comments show clearly that these editors do not
>>>>>>>>>>>>>> care
>>>>>>>>>>>>> to be
>>>>>>>>>>>>> careful or factual, or even read those disclaimers,
>>>>>>>>>>>>> unfortunately.
>>>>>>>>>>>>>
>>>>>>>>>>>>> We can be successful only if we manage to block their
>>>>>>>>>>>>> downloads.
>>>>>>>>>>>>>
>>>>>>>>>>>>> They
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> link to our binaries hosted on SourceForge (which is fine). Just
>>>>>>>>
>>>>>>>>> thinking loud, but if it was possible (on the Sourceforge side) to
>>>>>>>>>>>>> deny
>>>>>>>>>>>>> all download requests that do not come from the
>>>>>>>>>>>>> openoffice.orgor
>>>>>>>>>>>>>
>>>>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> sourceforge.net domains, then the project would effectively be in
>>>>>>>>
>>>>>>>>> control. The embargo could be lifted just after the release.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> For me this sounds like a great idea.
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe we should start with denying all download requests
>>>>>>>>>>>> that some
>>>>>>>>>>>>
>>>>>>>>>>>> from
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>> these bad websites.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> @Roberto:
>>>>>>>>>>>> Can you tell us if this possible? If yes, is it much effort for
>>>>>>>>>>>> you?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Do you see a chance to get this implemented? I think it could
>>>>>>>>>>> help to
>>>>>>>>>>> stop some bad websites to do bad things with our software.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> @Roberto:
>>>>>>>>>> Maybe you haven't seen this up to now.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks for heads up Marcus, sorry for not having noticed this
>>>>>>>>> thread
>>>>>>>>> before.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It would be great if you can tell us if it's possible to exclude
>>>>>>>>>> some
>>>>>>>>>> domains / IP addresses from downloading our software?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I need the domain list and I'll check out with our SiteOps if
>>>>>>>>> that's
>>>>>>>>> doable. Feel free to send me a list with a direct message.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> - chip.de
>>>>>>>> - computerbase.de
>>>>>>>> - softpedia.com
>>>>>>>>
>>>>>>>> This would be the domains from this thread that could be blocked
>>>>>>>> from
>>>>>>>> downloading from Sourceforge. Obviously needs to be extended in the
>>>>>>>>
>>>>>>>> future.
>>>>>>>
>>>>>>> Remember, the next will happen with the AOO 4.1.0 RC. ;-)
>>>>>>>>
>>>>>>>> *Of course*, this is just for the time frame as long as the new
>>>>>>>> version
>>>>>>>>
>>>>>>>> is
>>>>>>>
>>>>>>> not officially announced. As soon as the release is public, the
>>>>>>> block
>>>>>>>>
>>>>>>>> will
>>>>>>>
>>>>>>> be removed.
>>>>>>>>
>>>>>>>> @all:
>>>>>>>> I think this could help to limit the downloadability like we
>>>>>>>> want to
>>>>>>>> see
>>>>>>>> until the official release. What you think?
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't know. Won't this just cause confusion? They point to
>>>>>>>> the
>>>>>>> files, go to test them, see the links don't work, and then get weird
>>>>>>> errors and spend an hour trying to debug it. We don't want to
>>>>>>> needlessly annoy them, since their only fault is enthusiasm. Is
>>>>>>> there a way we can give a useful error message in this case like,
>>>>>>> "This version of Apache OpenOffice has not yet been officially
>>>>>>> released. Links to these files are disallowed until the release is
>>>>>>> officially approved" or something like that?
>>>>>>>
>>>>>>>
>>>>>> To be honest, I don't care about a few days were a special set of
>>>>> domains
>>>>> were not able to access for a few days. For me they are a bit too
>>>>> enthusiastic. And as you said in a previous post it's to protect us as
>>>>> best
>>>>> as possible.
>>>>>
>>>>>
>>>>> +1 This seems sufficient to me.
>>>>>
>>>>>>
>>>>>>
>>>>> @Roberto:
>>>>> Do you see a technical way to return a predefined error message
>>>>> when the
>>>>> release builds are already on Sourceforge but not yet officially
>>>>> released
>>>>> and published?
>>>>>
>>>>>
>>>> Our SiteOps team looked into this, here our findings:
>>>>
>>>
>>> Great :-)
>>>
>>>
>>> One provider (chip.de) serves via Akamai CDN, one provider (
>>>> computerbase.de)
>>>> serves via their own FTP server, and softpedia.com lists SourceForge as
>>>> an
>>>> external mirror and passes traffic through our download redirector flow
>>>> (not direct to a mirror).
>>>>
>>>> The first two cases are things we can't control.
>>>>
>>>> In the third case, we can indeed redirect this traffic by referrer to a
>>>> different landing page if one is provided. Maybe we want to have a
>>>> openoffice.org page explaining that's a release-candidate and it's
>>>> served
>>>> only for testing purposes and its use on a daily basis it is not
>>>> recommended.
>>>>
>>>> How does that sound?
>>>>
>>>
>>> I'm pretty sure that these kind of downloaders do not care about
>>> disclaimers - less then ever when located somewhere else. ;-)
>>>
>>> So, either we disable the entire download for the specific timeframe
>>> or at
>>> least a text as substitute (like "This release is not yet public. Please
>>> stay tuned and come back when it is announced."). But this text has
>>> then to
>>> be on Sourceforge in the same location.
>>>
>>
>> Yes, that's doable in the way Kay described. And yes, we would add the
>> text
>> and disable downloads.
>
> Just to be sure, is this limited to a special subdir like
> ".../files/milestones/"? Or also, additionally for ".../files/"?
>
>>> I'm wondering if the "staging" bit can help as best solution. I would
>>> expect that the new location is not public *and* not known *and* not
>>> useable/functional for the normal non-admin user *until* we remove
>>> the bit.
>>> Am I right?
>>
>>
>> In past we extended the 'staging' period of time for weeks, this could be
>> done again if necessary and it's definitely a more effective way to share
>
> Good to know. I thought you had extended the timeframe permanentelly. ;-)
>
>> files only with a selected audience (admins). Would that work, or you
>> want
>> to be able to share those files with a larger audience?
>
> I don't think it's relevant to a wider audience.
>
> We still speak about the timeframe between starting uploading to
> Sourceforge and the official announcement. Within this timeframe it
> should be possible for admins to test the download webpage with
> scripting - to see if it will work - but there must not be no way to
> download the builds from the public.
>
> So, I would prefer to go with the "staging"-bit as:
> - it is already available
> - there is no confusion for the public
> - it's easy to delete the bit to make the release public
> - and (please don't get me wrong ;-) ) we can do it alone without the
> help of you or someone else of Sourceforge.
>
> What do others think about this?
sounds ok to me, we should make it to complicate. It wasn't a big thing
the last time and it shows the interest in AOO.
How do I set the staging bit?
Juergen
>
> Thanks
>
> Marcus
>
>
>
>>> Then we can exclude requester that we don't want (e.g., malware
>>>>>
>>>>>> "distributors").
>>>>>>>>>>
>>>>>>>>>> Also in time frames with Beta or RC releases it can help us to
>>>>>>>>>> steer
>>>>>>>>>>
>>>>>>>>>> who
>>>>>>>>>
>>>>>>>>
>>>>>>> is able and when it is possible to download OpenOffice like we
>>>>>>> want to
>>>>>>>>
>>>>>>>>> see
>>>>>>>>>> until the real release date is reached.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Marcus
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Sure, sites could still copy all binaries being voted
>>>>>>>>>> upon and
>>>>>>>>>> offer
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> them locally, but this would require a more significant
>>>>>>>>>>> effort. on
>>>>>>>>>>>>> their
>>>>>>>>>>>>> side.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> And more HDD space and more own bandwith - which is also not
>>>>>>>>>>>> what
>>>>>>>>>>>>
>>>>>>>>>>>> they
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>> want.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> Marcus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 04/03/2014 01:09 PM, schrieb Rob Weir:
> On Wed, Apr 2, 2014 at 5:19 PM, Marcus (OOo)<ma...@wtnet.de> wrote:
>> Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:
>>
>>> 2014-04-02 21:15 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>>
>>>> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:
>>>>
>>>> 2014-04-01 21:30 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>
>>>>>
>>>>> Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<ro...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)<ma...@wtnet.de>
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Rob Weir wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Andrew's comments show clearly that these editors do not
>>>>>>>>>>>>>>> care
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>> careful or factual, or even read those disclaimers,
>>>>>>>>>>>>>> unfortunately.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We can be successful only if we manage to block their
>>>>>>>>>>>>>> downloads.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> They
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>> link to our binaries hosted on SourceForge (which is fine). Just
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> thinking loud, but if it was possible (on the Sourceforge side) to
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> deny
>>>>>>>>>>>>>> all download requests that do not come from the
>>>>>>>>>>>>>> openoffice.orgor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>> sourceforge.net domains, then the project would effectively be in
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> control. The embargo could be lifted just after the release.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For me this sounds like a great idea.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Maybe we should start with denying all download requests that
>>>>>>>>>>>>> some
>>>>>>>>>>>>>
>>>>>>>>>>>>> from
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> these bad websites.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> @Roberto:
>>>>>>>>>>>>> Can you tell us if this possible? If yes, is it much effort for
>>>>>>>>>>>>> you?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Do you see a chance to get this implemented? I think it could
>>>>>>>>>>>>
>>>>>>>>>>>> help to
>>>>>>>>>>>> stop some bad websites to do bad things with our software.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> @Roberto:
>>>>>>>>>>>
>>>>>>>>>>> Maybe you haven't seen this up to now.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks for heads up Marcus, sorry for not having noticed this
>>>>>>>>>>
>>>>>>>>>> thread
>>>>>>>>>> before.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It would be great if you can tell us if it's possible to exclude
>>>>>>>>>>>
>>>>>>>>>>> some
>>>>>>>>>>> domains / IP addresses from downloading our software?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I need the domain list and I'll check out with our SiteOps if
>>>>>>>>>>
>>>>>>>>>> that's
>>>>>>>>>> doable. Feel free to send me a list with a direct message.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> - chip.de
>>>>>>>>> - computerbase.de
>>>>>>>>> - softpedia.com
>>>>>>>>>
>>>>>>>>> This would be the domains from this thread that could be blocked
>>>>>>>>> from
>>>>>>>>> downloading from Sourceforge. Obviously needs to be extended in the
>>>>>>>>>
>>>>>>>>> future.
>>>>>>>>
>>>>>>>>
>>>>>>>> Remember, the next will happen with the AOO 4.1.0 RC. ;-)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Of course*, this is just for the time frame as long as the new
>>>>>>>>> version
>>>>>>>>>
>>>>>>>>> is
>>>>>>>>
>>>>>>>>
>>>>>>>> not officially announced. As soon as the release is public, the
>>>>>>>> block
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> will
>>>>>>>>
>>>>>>>>
>>>>>>>> be removed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> @all:
>>>>>>>>> I think this could help to limit the downloadability like we want to
>>>>>>>>> see
>>>>>>>>> until the official release. What you think?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I don't know. Won't this just cause confusion? They point to the
>>>>>>>>
>>>>>>>> files, go to test them, see the links don't work, and then get weird
>>>>>>>> errors and spend an hour trying to debug it. We don't want to
>>>>>>>> needlessly annoy them, since their only fault is enthusiasm. Is
>>>>>>>> there a way we can give a useful error message in this case like,
>>>>>>>> "This version of Apache OpenOffice has not yet been officially
>>>>>>>> released. Links to these files are disallowed until the release is
>>>>>>>> officially approved" or something like that?
>>>>>>>>
>>>>>>>>
>>>>>>> To be honest, I don't care about a few days were a special set of
>>>>>>
>>>>>> domains
>>>>>> were not able to access for a few days. For me they are a bit too
>>>>>> enthusiastic. And as you said in a previous post it's to protect us as
>>>>>> best
>>>>>> as possible.
>>>>>>
>>>>>>
>>>>>> +1 This seems sufficient to me.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>> @Roberto:
>>>>>> Do you see a technical way to return a predefined error message when
>>>>>> the
>>>>>> release builds are already on Sourceforge but not yet officially
>>>>>> released
>>>>>> and published?
>>>>>>
>>>>>>
>>>>> Our SiteOps team looked into this, here our findings:
>>>>>
>>>>
>>>> Great :-)
>>>>
>>>>
>>>> One provider (chip.de) serves via Akamai CDN, one provider (
>>>>>
>>>>> computerbase.de)
>>>>> serves via their own FTP server, and softpedia.com lists SourceForge as
>>>>> an
>>>>> external mirror and passes traffic through our download redirector flow
>>>>> (not direct to a mirror).
>>>>>
>>>>> The first two cases are things we can't control.
>>>>>
>>>>> In the third case, we can indeed redirect this traffic by referrer to a
>>>>> different landing page if one is provided. Maybe we want to have a
>>>>> openoffice.org page explaining that's a release-candidate and it's
>>>>> served
>>>>> only for testing purposes and its use on a daily basis it is not
>>>>> recommended.
>>>>>
>>>>> How does that sound?
>>>>>
>>>>
>>>> I'm pretty sure that these kind of downloaders do not care about
>>>> disclaimers - less then ever when located somewhere else. ;-)
>>>>
>>>> So, either we disable the entire download for the specific timeframe or
>>>> at
>>>> least a text as substitute (like "This release is not yet public. Please
>>>> stay tuned and come back when it is announced."). But this text has then
>>>> to
>>>> be on Sourceforge in the same location.
>>>>
>>>
>>> Yes, that's doable in the way Kay described. And yes, we would add the
>>> text
>>> and disable downloads.
>>
>>
>> Just to be sure, is this limited to a special subdir like
>> ".../files/milestones/"? Or also, additionally for ".../files/"?
>>
>>
>>>> I'm wondering if the "staging" bit can help as best solution. I would
>>>> expect that the new location is not public *and* not known *and* not
>>>> useable/functional for the normal non-admin user *until* we remove the
>>>> bit.
>>>> Am I right?
>>>
>>>
>>>
>>> In past we extended the 'staging' period of time for weeks, this could be
>>> done again if necessary and it's definitely a more effective way to share
>>
>>
>> Good to know. I thought you had extended the timeframe permanentelly. ;-)
>>
>>
>>> files only with a selected audience (admins). Would that work, or you want
>>> to be able to share those files with a larger audience?
>>
>>
>> I don't think it's relevant to a wider audience.
>>
>> We still speak about the timeframe between starting uploading to Sourceforge
>> and the official announcement. Within this timeframe it should be possible
>> for admins to test the download webpage with scripting - to see if it will
>> work - but there must not be no way to download the builds from the public.
>>
>> So, I would prefer to go with the "staging"-bit as:
>> - it is already available
>> - there is no confusion for the public
>> - it's easy to delete the bit to make the release public
>> - and (please don't get me wrong ;-) ) we can do it alone without the help
>> of you or someone else of Sourceforge.
>>
>> What do others think about this?
>>
>
> My original recommendation was to put a more prominent warning in the
> [VOTE] emails. The problem is this: if we are to have a public vote
> then the files we're voting on must also be public. Whether this is
> on SourceForge or people.apache.org, it is publicly known that this is
> the 4.1 RC and some websites will download and copy onto their
> websites. I don't think there is any technological means to prevent
> this. We only have our ability to educate about the risks.
Sure, to put a note into the VOTE mail is nice but wouldn't help to
avoid early downloads. I'm sure they will just smile and download
anyway. ;-)
OK, maybe I've misinterpreted your recommendation.
And yes, there is no 100% protection against these kind of downloaders.
However, we can give them a hard time and to use a staged folder can be
a real help.
So, this is my opinion. :-)
Marcus
>>>> Then we can exclude requester that we don't want (e.g., malware
>>>>>>
>>>>>>
>>>>>>> "distributors").
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Also in time frames with Beta or RC releases it can help us to
>>>>>>>>>>> steer
>>>>>>>>>>>
>>>>>>>>>>> who
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> is able and when it is possible to download OpenOffice like we want
>>>>>>>> to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> see
>>>>>>>>>>>
>>>>>>>>>>> until the real release date is reached.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Marcus
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Sure, sites could still copy all binaries being voted upon
>>>>>>>>>>> and
>>>>>>>>>>> offer
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> them locally, but this would require a more significant effort.
>>>>>>>>>>>> on
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> their
>>>>>>>>>>>>>> side.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And more HDD space and more own bandwith - which is also not
>>>>>>>>>>>>>
>>>>>>>>>>>>> what
>>>>>>>>>>>>>
>>>>>>>>>>>>> they
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> want.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Roberto Galoppini <ro...@gmail.com>.
2014-04-03 21:30 GMT+02:00 Marcus (OOo) <ma...@wtnet.de>:
> Am 04/03/2014 02:27 PM, schrieb Roberto Galoppini:
>
> 2014-04-03 13:09 GMT+02:00 Rob Weir<ro...@apache.org>:
>>
>> On Wed, Apr 2, 2014 at 5:19 PM, Marcus (OOo)<ma...@wtnet.de>
>>> wrote:
>>>
>>>> Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:
>>>>
>>>> 2014-04-02 21:15 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>
>>>>> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:
>>>>>>
>>>>>> 2014-04-01 21:30 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<ro...@apache.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)<
>>>>>>>>>
>>>>>>>> marcus.mail@wtnet.de>
>>>
>>>>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<marcus.mail@wtnet.de
>>>>>>>>>>> >:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Rob Weir wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Andrew's comments show clearly that these editors do not
>>>>>>>>>>>>>>>>> care
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>>>> careful or factual, or even read those disclaimers,
>>>>>>>>>>>>>>>> unfortunately.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We can be successful only if we manage to block their
>>>>>>>>>>>>>>>> downloads.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> They
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> link to our binaries hosted on SourceForge (which is
>>>>>>>>>> fine). Just
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> thinking loud, but if it was possible (on the Sourceforge side)
>>>>>>>>>>>>
>>>>>>>>>>> to
>>>
>>>>
>>>>>>>>>>>>>>>> deny
>>>>>>>>>>>>>>>> all download requests that do not come from the
>>>>>>>>>>>>>>>> openoffice.orgor
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> sourceforge.net domains, then the project would
>>>>>>>>>> effectively be
>>>>>>>>>>
>>>>>>>>> in
>>>
>>>>
>>>>>>>>>>>
>>>>>>>>>>> control. The embargo could be lifted just after the release.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> For me this sounds like a great idea.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Maybe we should start with denying all download requests that
>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> these bad websites.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> @Roberto:
>>>>>>>>>>>>>>> Can you tell us if this possible? If yes, is it much effort
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> for
>>>
>>>> you?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Do you see a chance to get this implemented? I think it
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> could
>>>
>>>>
>>>>>>>>>>>>>> help to
>>>>>>>>>>>>>> stop some bad websites to do bad things with our software.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> @Roberto:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Maybe you haven't seen this up to now.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for heads up Marcus, sorry for not having noticed
>>>>>>>>>>>>> this
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> thread
>>>>>>>>>>>> before.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It would be great if you can tell us if it's possible to
>>>>>>>>>>>>
>>>>>>>>>>> exclude
>>>
>>>>
>>>>>>>>>>>>> some
>>>>>>>>>>>>> domains / IP addresses from downloading our software?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I need the domain list and I'll check out with our SiteOps
>>>>>>>>>>>>> if
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> that's
>>>>>>>>>>>> doable. Feel free to send me a list with a direct message.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> - chip.de
>>>>>>>>>>> - computerbase.de
>>>>>>>>>>> - softpedia.com
>>>>>>>>>>>
>>>>>>>>>>> This would be the domains from this thread that could be blocked
>>>>>>>>>>> from
>>>>>>>>>>> downloading from Sourceforge. Obviously needs to be extended in
>>>>>>>>>>>
>>>>>>>>>> the
>>>
>>>>
>>>>>>>>>>> future.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Remember, the next will happen with the AOO 4.1.0 RC. ;-)
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *Of course*, this is just for the time frame as long as the new
>>>>>>>>>>> version
>>>>>>>>>>>
>>>>>>>>>>> is
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> not officially announced. As soon as the release is public, the
>>>>>>>>>> block
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> will
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> be removed.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> @all:
>>>>>>>>>>> I think this could help to limit the downloadability like we want
>>>>>>>>>>>
>>>>>>>>>> to
>>>
>>>> see
>>>>>>>>>>> until the official release. What you think?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I don't know. Won't this just cause confusion? They point to
>>>>>>>>>>>
>>>>>>>>>> the
>>>
>>>>
>>>>>>>>>> files, go to test them, see the links don't work, and then get
>>>>>>>>>>
>>>>>>>>> weird
>>>
>>>> errors and spend an hour trying to debug it. We don't want to
>>>>>>>>>> needlessly annoy them, since their only fault is enthusiasm. Is
>>>>>>>>>> there a way we can give a useful error message in this case like,
>>>>>>>>>> "This version of Apache OpenOffice has not yet been officially
>>>>>>>>>> released. Links to these files are disallowed until the release
>>>>>>>>>> is
>>>>>>>>>> officially approved" or something like that?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> To be honest, I don't care about a few days were a special
>>>>>>>>> set of
>>>>>>>>>
>>>>>>>>
>>>>>>>> domains
>>>>>>>> were not able to access for a few days. For me they are a bit too
>>>>>>>> enthusiastic. And as you said in a previous post it's to protect us
>>>>>>>>
>>>>>>> as
>>>
>>>> best
>>>>>>>> as possible.
>>>>>>>>
>>>>>>>>
>>>>>>>> +1 This seems sufficient to me.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> @Roberto:
>>>>>>>> Do you see a technical way to return a predefined error message when
>>>>>>>> the
>>>>>>>> release builds are already on Sourceforge but not yet officially
>>>>>>>> released
>>>>>>>> and published?
>>>>>>>>
>>>>>>>>
>>>>>>>> Our SiteOps team looked into this, here our findings:
>>>>>>>
>>>>>>>
>>>>>> Great :-)
>>>>>>
>>>>>>
>>>>>> One provider (chip.de) serves via Akamai CDN, one provider (
>>>>>>
>>>>>>>
>>>>>>> computerbase.de)
>>>>>>> serves via their own FTP server, and softpedia.com lists SourceForge
>>>>>>>
>>>>>> as
>>>
>>>> an
>>>>>>> external mirror and passes traffic through our download redirector
>>>>>>>
>>>>>> flow
>>>
>>>> (not direct to a mirror).
>>>>>>>
>>>>>>> The first two cases are things we can't control.
>>>>>>>
>>>>>>> In the third case, we can indeed redirect this traffic by referrer to
>>>>>>>
>>>>>> a
>>>
>>>> different landing page if one is provided. Maybe we want to have a
>>>>>>> openoffice.org page explaining that's a release-candidate and it's
>>>>>>> served
>>>>>>> only for testing purposes and its use on a daily basis it is not
>>>>>>> recommended.
>>>>>>>
>>>>>>> How does that sound?
>>>>>>>
>>>>>>>
>>>>>> I'm pretty sure that these kind of downloaders do not care about
>>>>>> disclaimers - less then ever when located somewhere else. ;-)
>>>>>>
>>>>>> So, either we disable the entire download for the specific timeframe
>>>>>> or
>>>>>> at
>>>>>> least a text as substitute (like "This release is not yet public.
>>>>>>
>>>>> Please
>>>
>>>> stay tuned and come back when it is announced."). But this text has
>>>>>>
>>>>> then
>>>
>>>> to
>>>>>> be on Sourceforge in the same location.
>>>>>>
>>>>>>
>>>>> Yes, that's doable in the way Kay described. And yes, we would add the
>>>>> text
>>>>> and disable downloads.
>>>>>
>>>>
>>>>
>>>> Just to be sure, is this limited to a special subdir like
>>>> ".../files/milestones/"? Or also, additionally for ".../files/"?
>>>>
>>>>
>>>> I'm wondering if the "staging" bit can help as best solution. I would
>>>>>> expect that the new location is not public *and* not known *and* not
>>>>>> useable/functional for the normal non-admin user *until* we remove the
>>>>>> bit.
>>>>>> Am I right?
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> In past we extended the 'staging' period of time for weeks, this could
>>>>>
>>>> be
>>>
>>>> done again if necessary and it's definitely a more effective way to
>>>>>
>>>> share
>>>
>>>>
>>>>
>>>> Good to know. I thought you had extended the timeframe permanentelly.
>>>> ;-)
>>>>
>>>
>>>
>> It's still set to 21 days maximum. We can of course extend that if needed.
>> I'll take care of that.
>>
>>
>>
>>>>
>>>> files only with a selected audience (admins). Would that work, or you
>>>>>
>>>> want
>>>
>>>> to be able to share those files with a larger audience?
>>>>>
>>>>
>>>>
>>>> I don't think it's relevant to a wider audience.
>>>>
>>>> We still speak about the timeframe between starting uploading to
>>>>
>>> Sourceforge
>>>
>>>> and the official announcement. Within this timeframe it should be
>>>>
>>> possible
>>>
>>>> for admins to test the download webpage with scripting - to see if it
>>>>
>>> will
>>>
>>>> work - but there must not be no way to download the builds from the
>>>>
>>> public.
>>>
>>>>
>>>> So, I would prefer to go with the "staging"-bit as:
>>>> - it is already available
>>>> - there is no confusion for the public
>>>> - it's easy to delete the bit to make the release public
>>>> - and (please don't get me wrong ;-) ) we can do it alone without the
>>>>
>>> help
>>>
>>>> of you or someone else of Sourceforge.
>>>>
>>>> What do others think about this?
>>>>
>>>>
>>> My original recommendation was to put a more prominent warning in the
>>> [VOTE] emails. The problem is this: if we are to have a public vote
>>> then the files we're voting on must also be public. Whether this is
>>> on SourceForge or people.apache.org, it is publicly known that this is
>>> the 4.1 RC and some websites will download and copy onto their
>>> websites. I don't think there is any technological means to prevent
>>> this. We only have our ability to educate about the risks.
>>>
>>>
>> Yea, actually as per my previous email we can just mitigate the issue for
>> those who point to us to serve downloads, anyone else can actually
>> download
>> it - either from their domain or other IP - and then serve it through
>> their
>> services.
>>
>
> IMHO we can skip this when using a staged folder. Then they don't see
> anything and cannot download finally.
>
>
> If it's not much of a trouble what about having a different splash-screen,
>> with a big sign "Attention" explaining that's just a release candidate and
>> it's not the final product and we recommend to visit always OpenOffice.org
>> to get the latest available release?
>>
>
> That's of course a very good idea for Beta releases or any other pre-final
> release. However, it will not help for RCs as we declare these builds as
> final when we don't get (severe) complaints. This means RC and final
> version are technically the same bits and bytes. So, here we should avoid
> any temporary splash screens.
Technically you're 100% right, my thought was that probably those guys
distributing AOO RC as final don't want to look clumsy and inexperienced
and they would probably avoid to distribute a version that is marked as not
good (yet) for the general public. Anyway, I understand the annoyance of
putting/removing such a screen-shot.
Roberto
>
>
> Marcus
>
>
>
> Then we can exclude requester that we don't want (e.g., malware
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> "distributors").
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also in time frames with Beta or RC releases it can help us to
>>>>>>>>>>>>> steer
>>>>>>>>>>>>>
>>>>>>>>>>>>> who
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> is able and when it is possible to download OpenOffice like
>>>>>>>>>> we
>>>>>>>>>>
>>>>>>>>> want
>>>
>>>> to
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> see
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> until the real release date is reached.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Marcus
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sure, sites could still copy all binaries being voted
>>>>>>>>>>>>> upon
>>>>>>>>>>>>> and
>>>>>>>>>>>>> offer
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> them locally, but this would require a more significant
>>>>>>>>>>>>>>
>>>>>>>>>>>>> effort.
>>>
>>>> on
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>>> side.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And more HDD space and more own bandwith - which is also
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> not
>>>
>>>>
>>>>>>>>>>>>>>> what
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> want.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Marcus
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Anything we can do about premature redistribution?
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 04/03/2014 02:27 PM, schrieb Roberto Galoppini:
> 2014-04-03 13:09 GMT+02:00 Rob Weir<ro...@apache.org>:
>
>> On Wed, Apr 2, 2014 at 5:19 PM, Marcus (OOo)<ma...@wtnet.de> wrote:
>>> Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:
>>>
>>>> 2014-04-02 21:15 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>
>>>>> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:
>>>>>
>>>>> 2014-04-01 21:30 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>>
>>>>>>
>>>>>> Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<ro...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)<
>> marcus.mail@wtnet.de>
>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Rob Weir wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Andrew's comments show clearly that these editors do not
>>>>>>>>>>>>>>>> care
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>>> careful or factual, or even read those disclaimers,
>>>>>>>>>>>>>>> unfortunately.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We can be successful only if we manage to block their
>>>>>>>>>>>>>>> downloads.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> They
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>> link to our binaries hosted on SourceForge (which is fine). Just
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> thinking loud, but if it was possible (on the Sourceforge side)
>> to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> deny
>>>>>>>>>>>>>>> all download requests that do not come from the
>>>>>>>>>>>>>>> openoffice.orgor
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>> sourceforge.net domains, then the project would effectively be
>> in
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> control. The embargo could be lifted just after the release.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For me this sounds like a great idea.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maybe we should start with denying all download requests that
>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> from
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> these bad websites.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> @Roberto:
>>>>>>>>>>>>>> Can you tell us if this possible? If yes, is it much effort
>> for
>>>>>>>>>>>>>> you?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Do you see a chance to get this implemented? I think it
>> could
>>>>>>>>>>>>>
>>>>>>>>>>>>> help to
>>>>>>>>>>>>> stop some bad websites to do bad things with our software.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> @Roberto:
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe you haven't seen this up to now.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for heads up Marcus, sorry for not having noticed this
>>>>>>>>>>>
>>>>>>>>>>> thread
>>>>>>>>>>> before.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It would be great if you can tell us if it's possible to
>> exclude
>>>>>>>>>>>>
>>>>>>>>>>>> some
>>>>>>>>>>>> domains / IP addresses from downloading our software?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I need the domain list and I'll check out with our SiteOps if
>>>>>>>>>>>
>>>>>>>>>>> that's
>>>>>>>>>>> doable. Feel free to send me a list with a direct message.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> - chip.de
>>>>>>>>>> - computerbase.de
>>>>>>>>>> - softpedia.com
>>>>>>>>>>
>>>>>>>>>> This would be the domains from this thread that could be blocked
>>>>>>>>>> from
>>>>>>>>>> downloading from Sourceforge. Obviously needs to be extended in
>> the
>>>>>>>>>>
>>>>>>>>>> future.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Remember, the next will happen with the AOO 4.1.0 RC. ;-)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *Of course*, this is just for the time frame as long as the new
>>>>>>>>>> version
>>>>>>>>>>
>>>>>>>>>> is
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> not officially announced. As soon as the release is public, the
>>>>>>>>> block
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> will
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> be removed.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> @all:
>>>>>>>>>> I think this could help to limit the downloadability like we want
>> to
>>>>>>>>>> see
>>>>>>>>>> until the official release. What you think?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I don't know. Won't this just cause confusion? They point to
>> the
>>>>>>>>>
>>>>>>>>> files, go to test them, see the links don't work, and then get
>> weird
>>>>>>>>> errors and spend an hour trying to debug it. We don't want to
>>>>>>>>> needlessly annoy them, since their only fault is enthusiasm. Is
>>>>>>>>> there a way we can give a useful error message in this case like,
>>>>>>>>> "This version of Apache OpenOffice has not yet been officially
>>>>>>>>> released. Links to these files are disallowed until the release is
>>>>>>>>> officially approved" or something like that?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> To be honest, I don't care about a few days were a special set of
>>>>>>>
>>>>>>> domains
>>>>>>> were not able to access for a few days. For me they are a bit too
>>>>>>> enthusiastic. And as you said in a previous post it's to protect us
>> as
>>>>>>> best
>>>>>>> as possible.
>>>>>>>
>>>>>>>
>>>>>>> +1 This seems sufficient to me.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> @Roberto:
>>>>>>> Do you see a technical way to return a predefined error message when
>>>>>>> the
>>>>>>> release builds are already on Sourceforge but not yet officially
>>>>>>> released
>>>>>>> and published?
>>>>>>>
>>>>>>>
>>>>>> Our SiteOps team looked into this, here our findings:
>>>>>>
>>>>>
>>>>> Great :-)
>>>>>
>>>>>
>>>>> One provider (chip.de) serves via Akamai CDN, one provider (
>>>>>>
>>>>>> computerbase.de)
>>>>>> serves via their own FTP server, and softpedia.com lists SourceForge
>> as
>>>>>> an
>>>>>> external mirror and passes traffic through our download redirector
>> flow
>>>>>> (not direct to a mirror).
>>>>>>
>>>>>> The first two cases are things we can't control.
>>>>>>
>>>>>> In the third case, we can indeed redirect this traffic by referrer to
>> a
>>>>>> different landing page if one is provided. Maybe we want to have a
>>>>>> openoffice.org page explaining that's a release-candidate and it's
>>>>>> served
>>>>>> only for testing purposes and its use on a daily basis it is not
>>>>>> recommended.
>>>>>>
>>>>>> How does that sound?
>>>>>>
>>>>>
>>>>> I'm pretty sure that these kind of downloaders do not care about
>>>>> disclaimers - less then ever when located somewhere else. ;-)
>>>>>
>>>>> So, either we disable the entire download for the specific timeframe or
>>>>> at
>>>>> least a text as substitute (like "This release is not yet public.
>> Please
>>>>> stay tuned and come back when it is announced."). But this text has
>> then
>>>>> to
>>>>> be on Sourceforge in the same location.
>>>>>
>>>>
>>>> Yes, that's doable in the way Kay described. And yes, we would add the
>>>> text
>>>> and disable downloads.
>>>
>>>
>>> Just to be sure, is this limited to a special subdir like
>>> ".../files/milestones/"? Or also, additionally for ".../files/"?
>>>
>>>
>>>>> I'm wondering if the "staging" bit can help as best solution. I would
>>>>> expect that the new location is not public *and* not known *and* not
>>>>> useable/functional for the normal non-admin user *until* we remove the
>>>>> bit.
>>>>> Am I right?
>>>>
>>>>
>>>>
>>>> In past we extended the 'staging' period of time for weeks, this could
>> be
>>>> done again if necessary and it's definitely a more effective way to
>> share
>>>
>>>
>>> Good to know. I thought you had extended the timeframe permanentelly. ;-)
>>
>
> It's still set to 21 days maximum. We can of course extend that if needed.
> I'll take care of that.
>
>
>>>
>>>
>>>> files only with a selected audience (admins). Would that work, or you
>> want
>>>> to be able to share those files with a larger audience?
>>>
>>>
>>> I don't think it's relevant to a wider audience.
>>>
>>> We still speak about the timeframe between starting uploading to
>> Sourceforge
>>> and the official announcement. Within this timeframe it should be
>> possible
>>> for admins to test the download webpage with scripting - to see if it
>> will
>>> work - but there must not be no way to download the builds from the
>> public.
>>>
>>> So, I would prefer to go with the "staging"-bit as:
>>> - it is already available
>>> - there is no confusion for the public
>>> - it's easy to delete the bit to make the release public
>>> - and (please don't get me wrong ;-) ) we can do it alone without the
>> help
>>> of you or someone else of Sourceforge.
>>>
>>> What do others think about this?
>>>
>>
>> My original recommendation was to put a more prominent warning in the
>> [VOTE] emails. The problem is this: if we are to have a public vote
>> then the files we're voting on must also be public. Whether this is
>> on SourceForge or people.apache.org, it is publicly known that this is
>> the 4.1 RC and some websites will download and copy onto their
>> websites. I don't think there is any technological means to prevent
>> this. We only have our ability to educate about the risks.
>>
>
> Yea, actually as per my previous email we can just mitigate the issue for
> those who point to us to serve downloads, anyone else can actually download
> it - either from their domain or other IP - and then serve it through their
> services.
IMHO we can skip this when using a staged folder. Then they don't see
anything and cannot download finally.
> If it's not much of a trouble what about having a different splash-screen,
> with a big sign "Attention" explaining that's just a release candidate and
> it's not the final product and we recommend to visit always OpenOffice.org
> to get the latest available release?
That's of course a very good idea for Beta releases or any other
pre-final release. However, it will not help for RCs as we declare these
builds as final when we don't get (severe) complaints. This means RC and
final version are technically the same bits and bytes. So, here we
should avoid any temporary splash screens.
Marcus
>>>>> Then we can exclude requester that we don't want (e.g., malware
>>>>>>>
>>>>>>>
>>>>>>>> "distributors").
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Also in time frames with Beta or RC releases it can help us to
>>>>>>>>>>>> steer
>>>>>>>>>>>>
>>>>>>>>>>>> who
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> is able and when it is possible to download OpenOffice like we
>> want
>>>>>>>>> to
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> see
>>>>>>>>>>>>
>>>>>>>>>>>> until the real release date is reached.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Marcus
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Sure, sites could still copy all binaries being voted upon
>>>>>>>>>>>> and
>>>>>>>>>>>> offer
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> them locally, but this would require a more significant
>> effort.
>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>> side.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And more HDD space and more own bandwith - which is also
>> not
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> what
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> they
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> want.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Roberto Galoppini <ro...@gmail.com>.
2014-04-03 13:09 GMT+02:00 Rob Weir <ro...@apache.org>:
> On Wed, Apr 2, 2014 at 5:19 PM, Marcus (OOo) <ma...@wtnet.de> wrote:
> > Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:
> >
> >> 2014-04-02 21:15 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
> >>
> >>> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:
> >>>
> >>> 2014-04-01 21:30 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
> >>>>
> >>>>
> >>>> Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
> >>>>>
> >>>>>
> >>>>> On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<ro...@apache.org>
> >>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>> On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)<
> marcus.mail@wtnet.de>
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<ma...@wtnet.de>:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Rob Weir wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Apache-OpenOffice-253.shtml
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Andrew's comments show clearly that these editors do not
> >>>>>>>>>>>>>> care
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> to be
> >>>>>>>>>>>>> careful or factual, or even read those disclaimers,
> >>>>>>>>>>>>> unfortunately.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> We can be successful only if we manage to block their
> >>>>>>>>>>>>> downloads.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> They
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> link to our binaries hosted on SourceForge (which is fine). Just
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> thinking loud, but if it was possible (on the Sourceforge side)
> to
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> deny
> >>>>>>>>>>>>> all download requests that do not come from the
> >>>>>>>>>>>>> openoffice.orgor
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>> sourceforge.net domains, then the project would effectively be
> in
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> control. The embargo could be lifted just after the release.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> For me this sounds like a great idea.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Maybe we should start with denying all download requests that
> >>>>>>>>>>>> some
> >>>>>>>>>>>>
> >>>>>>>>>>>> from
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> these bad websites.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>> @Roberto:
> >>>>>>>>>>>> Can you tell us if this possible? If yes, is it much effort
> for
> >>>>>>>>>>>> you?
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Do you see a chance to get this implemented? I think it
> could
> >>>>>>>>>>>
> >>>>>>>>>>> help to
> >>>>>>>>>>> stop some bad websites to do bad things with our software.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> @Roberto:
> >>>>>>>>>>
> >>>>>>>>>> Maybe you haven't seen this up to now.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Thanks for heads up Marcus, sorry for not having noticed this
> >>>>>>>>>
> >>>>>>>>> thread
> >>>>>>>>> before.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> It would be great if you can tell us if it's possible to
> exclude
> >>>>>>>>>>
> >>>>>>>>>> some
> >>>>>>>>>> domains / IP addresses from downloading our software?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I need the domain list and I'll check out with our SiteOps if
> >>>>>>>>>
> >>>>>>>>> that's
> >>>>>>>>> doable. Feel free to send me a list with a direct message.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> - chip.de
> >>>>>>>> - computerbase.de
> >>>>>>>> - softpedia.com
> >>>>>>>>
> >>>>>>>> This would be the domains from this thread that could be blocked
> >>>>>>>> from
> >>>>>>>> downloading from Sourceforge. Obviously needs to be extended in
> the
> >>>>>>>>
> >>>>>>>> future.
> >>>>>>>
> >>>>>>>
> >>>>>>> Remember, the next will happen with the AOO 4.1.0 RC. ;-)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> *Of course*, this is just for the time frame as long as the new
> >>>>>>>> version
> >>>>>>>>
> >>>>>>>> is
> >>>>>>>
> >>>>>>>
> >>>>>>> not officially announced. As soon as the release is public, the
> >>>>>>> block
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> will
> >>>>>>>
> >>>>>>>
> >>>>>>> be removed.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> @all:
> >>>>>>>> I think this could help to limit the downloadability like we want
> to
> >>>>>>>> see
> >>>>>>>> until the official release. What you think?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I don't know. Won't this just cause confusion? They point to
> the
> >>>>>>>
> >>>>>>> files, go to test them, see the links don't work, and then get
> weird
> >>>>>>> errors and spend an hour trying to debug it. We don't want to
> >>>>>>> needlessly annoy them, since their only fault is enthusiasm. Is
> >>>>>>> there a way we can give a useful error message in this case like,
> >>>>>>> "This version of Apache OpenOffice has not yet been officially
> >>>>>>> released. Links to these files are disallowed until the release is
> >>>>>>> officially approved" or something like that?
> >>>>>>>
> >>>>>>>
> >>>>>> To be honest, I don't care about a few days were a special set of
> >>>>>
> >>>>> domains
> >>>>> were not able to access for a few days. For me they are a bit too
> >>>>> enthusiastic. And as you said in a previous post it's to protect us
> as
> >>>>> best
> >>>>> as possible.
> >>>>>
> >>>>>
> >>>>> +1 This seems sufficient to me.
> >>>>>
> >>>>>>
> >>>>>>
> >>>>> @Roberto:
> >>>>> Do you see a technical way to return a predefined error message when
> >>>>> the
> >>>>> release builds are already on Sourceforge but not yet officially
> >>>>> released
> >>>>> and published?
> >>>>>
> >>>>>
> >>>> Our SiteOps team looked into this, here our findings:
> >>>>
> >>>
> >>> Great :-)
> >>>
> >>>
> >>> One provider (chip.de) serves via Akamai CDN, one provider (
> >>>>
> >>>> computerbase.de)
> >>>> serves via their own FTP server, and softpedia.com lists SourceForge
> as
> >>>> an
> >>>> external mirror and passes traffic through our download redirector
> flow
> >>>> (not direct to a mirror).
> >>>>
> >>>> The first two cases are things we can't control.
> >>>>
> >>>> In the third case, we can indeed redirect this traffic by referrer to
> a
> >>>> different landing page if one is provided. Maybe we want to have a
> >>>> openoffice.org page explaining that's a release-candidate and it's
> >>>> served
> >>>> only for testing purposes and its use on a daily basis it is not
> >>>> recommended.
> >>>>
> >>>> How does that sound?
> >>>>
> >>>
> >>> I'm pretty sure that these kind of downloaders do not care about
> >>> disclaimers - less then ever when located somewhere else. ;-)
> >>>
> >>> So, either we disable the entire download for the specific timeframe or
> >>> at
> >>> least a text as substitute (like "This release is not yet public.
> Please
> >>> stay tuned and come back when it is announced."). But this text has
> then
> >>> to
> >>> be on Sourceforge in the same location.
> >>>
> >>
> >> Yes, that's doable in the way Kay described. And yes, we would add the
> >> text
> >> and disable downloads.
> >
> >
> > Just to be sure, is this limited to a special subdir like
> > ".../files/milestones/"? Or also, additionally for ".../files/"?
> >
> >
> >>> I'm wondering if the "staging" bit can help as best solution. I would
> >>> expect that the new location is not public *and* not known *and* not
> >>> useable/functional for the normal non-admin user *until* we remove the
> >>> bit.
> >>> Am I right?
> >>
> >>
> >>
> >> In past we extended the 'staging' period of time for weeks, this could
> be
> >> done again if necessary and it's definitely a more effective way to
> share
> >
> >
> > Good to know. I thought you had extended the timeframe permanentelly. ;-)
>
It's still set to 21 days maximum. We can of course extend that if needed.
I'll take care of that.
> >
> >
> >> files only with a selected audience (admins). Would that work, or you
> want
> >> to be able to share those files with a larger audience?
> >
> >
> > I don't think it's relevant to a wider audience.
> >
> > We still speak about the timeframe between starting uploading to
> Sourceforge
> > and the official announcement. Within this timeframe it should be
> possible
> > for admins to test the download webpage with scripting - to see if it
> will
> > work - but there must not be no way to download the builds from the
> public.
> >
> > So, I would prefer to go with the "staging"-bit as:
> > - it is already available
> > - there is no confusion for the public
> > - it's easy to delete the bit to make the release public
> > - and (please don't get me wrong ;-) ) we can do it alone without the
> help
> > of you or someone else of Sourceforge.
> >
> > What do others think about this?
> >
>
> My original recommendation was to put a more prominent warning in the
> [VOTE] emails. The problem is this: if we are to have a public vote
> then the files we're voting on must also be public. Whether this is
> on SourceForge or people.apache.org, it is publicly known that this is
> the 4.1 RC and some websites will download and copy onto their
> websites. I don't think there is any technological means to prevent
> this. We only have our ability to educate about the risks.
>
Yea, actually as per my previous email we can just mitigate the issue for
those who point to us to serve downloads, anyone else can actually download
it - either from their domain or other IP - and then serve it through their
services.
If it's not much of a trouble what about having a different splash-screen,
with a big sign "Attention" explaining that's just a release candidate and
it's not the final product and we recommend to visit always OpenOffice.org
to get the latest available release?
>
> -Rob
>
>
> >
> > Thanks
> >
> > Marcus
> >
> >
> >
> >>> Then we can exclude requester that we don't want (e.g., malware
> >>>>>
> >>>>>
> >>>>>> "distributors").
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Also in time frames with Beta or RC releases it can help us to
> >>>>>>>>>> steer
> >>>>>>>>>>
> >>>>>>>>>> who
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>> is able and when it is possible to download OpenOffice like we
> want
> >>>>>>> to
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> see
> >>>>>>>>>>
> >>>>>>>>>> until the real release date is reached.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thanks
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Marcus
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Sure, sites could still copy all binaries being voted upon
> >>>>>>>>>> and
> >>>>>>>>>> offer
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> them locally, but this would require a more significant
> effort.
> >>>>>>>>>>> on
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> their
> >>>>>>>>>>>>> side.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> And more HDD space and more own bandwith - which is also
> not
> >>>>>>>>>>>>
> >>>>>>>>>>>> what
> >>>>>>>>>>>>
> >>>>>>>>>>>> they
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> want.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>> Marcus
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Anything we can do about premature redistribution?
Posted by Rob Weir <ro...@apache.org>.
On Wed, Apr 2, 2014 at 5:19 PM, Marcus (OOo) <ma...@wtnet.de> wrote:
> Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:
>
>> 2014-04-02 21:15 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>
>>> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:
>>>
>>> 2014-04-01 21:30 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>
>>>>
>>>> Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
>>>>>
>>>>>
>>>>> On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<ro...@apache.org>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)<ma...@wtnet.de>
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
>>>>>>>>
>>>>>>>>
>>>>>>>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Rob Weir wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Andrew's comments show clearly that these editors do not
>>>>>>>>>>>>>> care
>>>>>>>>>>>>>
>>>>>>>>>>>>> to be
>>>>>>>>>>>>> careful or factual, or even read those disclaimers,
>>>>>>>>>>>>> unfortunately.
>>>>>>>>>>>>>
>>>>>>>>>>>>> We can be successful only if we manage to block their
>>>>>>>>>>>>> downloads.
>>>>>>>>>>>>>
>>>>>>>>>>>>> They
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> link to our binaries hosted on SourceForge (which is fine). Just
>>>>>>>>
>>>>>>>>
>>>>>>>>> thinking loud, but if it was possible (on the Sourceforge side) to
>>>>>>>>>>>>>
>>>>>>>>>>>>> deny
>>>>>>>>>>>>> all download requests that do not come from the
>>>>>>>>>>>>> openoffice.orgor
>>>>>>>>>>>>>
>>>>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> sourceforge.net domains, then the project would effectively be in
>>>>>>>>
>>>>>>>>
>>>>>>>>> control. The embargo could be lifted just after the release.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> For me this sounds like a great idea.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe we should start with denying all download requests that
>>>>>>>>>>>> some
>>>>>>>>>>>>
>>>>>>>>>>>> from
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>> these bad websites.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> @Roberto:
>>>>>>>>>>>> Can you tell us if this possible? If yes, is it much effort for
>>>>>>>>>>>> you?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Do you see a chance to get this implemented? I think it could
>>>>>>>>>>>
>>>>>>>>>>> help to
>>>>>>>>>>> stop some bad websites to do bad things with our software.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> @Roberto:
>>>>>>>>>>
>>>>>>>>>> Maybe you haven't seen this up to now.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks for heads up Marcus, sorry for not having noticed this
>>>>>>>>>
>>>>>>>>> thread
>>>>>>>>> before.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It would be great if you can tell us if it's possible to exclude
>>>>>>>>>>
>>>>>>>>>> some
>>>>>>>>>> domains / IP addresses from downloading our software?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I need the domain list and I'll check out with our SiteOps if
>>>>>>>>>
>>>>>>>>> that's
>>>>>>>>> doable. Feel free to send me a list with a direct message.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> - chip.de
>>>>>>>> - computerbase.de
>>>>>>>> - softpedia.com
>>>>>>>>
>>>>>>>> This would be the domains from this thread that could be blocked
>>>>>>>> from
>>>>>>>> downloading from Sourceforge. Obviously needs to be extended in the
>>>>>>>>
>>>>>>>> future.
>>>>>>>
>>>>>>>
>>>>>>> Remember, the next will happen with the AOO 4.1.0 RC. ;-)
>>>>>>>>
>>>>>>>>
>>>>>>>> *Of course*, this is just for the time frame as long as the new
>>>>>>>> version
>>>>>>>>
>>>>>>>> is
>>>>>>>
>>>>>>>
>>>>>>> not officially announced. As soon as the release is public, the
>>>>>>> block
>>>>>>>>
>>>>>>>>
>>>>>>>> will
>>>>>>>
>>>>>>>
>>>>>>> be removed.
>>>>>>>>
>>>>>>>>
>>>>>>>> @all:
>>>>>>>> I think this could help to limit the downloadability like we want to
>>>>>>>> see
>>>>>>>> until the official release. What you think?
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't know. Won't this just cause confusion? They point to the
>>>>>>>
>>>>>>> files, go to test them, see the links don't work, and then get weird
>>>>>>> errors and spend an hour trying to debug it. We don't want to
>>>>>>> needlessly annoy them, since their only fault is enthusiasm. Is
>>>>>>> there a way we can give a useful error message in this case like,
>>>>>>> "This version of Apache OpenOffice has not yet been officially
>>>>>>> released. Links to these files are disallowed until the release is
>>>>>>> officially approved" or something like that?
>>>>>>>
>>>>>>>
>>>>>> To be honest, I don't care about a few days were a special set of
>>>>>
>>>>> domains
>>>>> were not able to access for a few days. For me they are a bit too
>>>>> enthusiastic. And as you said in a previous post it's to protect us as
>>>>> best
>>>>> as possible.
>>>>>
>>>>>
>>>>> +1 This seems sufficient to me.
>>>>>
>>>>>>
>>>>>>
>>>>> @Roberto:
>>>>> Do you see a technical way to return a predefined error message when
>>>>> the
>>>>> release builds are already on Sourceforge but not yet officially
>>>>> released
>>>>> and published?
>>>>>
>>>>>
>>>> Our SiteOps team looked into this, here our findings:
>>>>
>>>
>>> Great :-)
>>>
>>>
>>> One provider (chip.de) serves via Akamai CDN, one provider (
>>>>
>>>> computerbase.de)
>>>> serves via their own FTP server, and softpedia.com lists SourceForge as
>>>> an
>>>> external mirror and passes traffic through our download redirector flow
>>>> (not direct to a mirror).
>>>>
>>>> The first two cases are things we can't control.
>>>>
>>>> In the third case, we can indeed redirect this traffic by referrer to a
>>>> different landing page if one is provided. Maybe we want to have a
>>>> openoffice.org page explaining that's a release-candidate and it's
>>>> served
>>>> only for testing purposes and its use on a daily basis it is not
>>>> recommended.
>>>>
>>>> How does that sound?
>>>>
>>>
>>> I'm pretty sure that these kind of downloaders do not care about
>>> disclaimers - less then ever when located somewhere else. ;-)
>>>
>>> So, either we disable the entire download for the specific timeframe or
>>> at
>>> least a text as substitute (like "This release is not yet public. Please
>>> stay tuned and come back when it is announced."). But this text has then
>>> to
>>> be on Sourceforge in the same location.
>>>
>>
>> Yes, that's doable in the way Kay described. And yes, we would add the
>> text
>> and disable downloads.
>
>
> Just to be sure, is this limited to a special subdir like
> ".../files/milestones/"? Or also, additionally for ".../files/"?
>
>
>>> I'm wondering if the "staging" bit can help as best solution. I would
>>> expect that the new location is not public *and* not known *and* not
>>> useable/functional for the normal non-admin user *until* we remove the
>>> bit.
>>> Am I right?
>>
>>
>>
>> In past we extended the 'staging' period of time for weeks, this could be
>> done again if necessary and it's definitely a more effective way to share
>
>
> Good to know. I thought you had extended the timeframe permanentelly. ;-)
>
>
>> files only with a selected audience (admins). Would that work, or you want
>> to be able to share those files with a larger audience?
>
>
> I don't think it's relevant to a wider audience.
>
> We still speak about the timeframe between starting uploading to Sourceforge
> and the official announcement. Within this timeframe it should be possible
> for admins to test the download webpage with scripting - to see if it will
> work - but there must not be no way to download the builds from the public.
>
> So, I would prefer to go with the "staging"-bit as:
> - it is already available
> - there is no confusion for the public
> - it's easy to delete the bit to make the release public
> - and (please don't get me wrong ;-) ) we can do it alone without the help
> of you or someone else of Sourceforge.
>
> What do others think about this?
>
My original recommendation was to put a more prominent warning in the
[VOTE] emails. The problem is this: if we are to have a public vote
then the files we're voting on must also be public. Whether this is
on SourceForge or people.apache.org, it is publicly known that this is
the 4.1 RC and some websites will download and copy onto their
websites. I don't think there is any technological means to prevent
this. We only have our ability to educate about the risks.
-Rob
>
> Thanks
>
> Marcus
>
>
>
>>> Then we can exclude requester that we don't want (e.g., malware
>>>>>
>>>>>
>>>>>> "distributors").
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Also in time frames with Beta or RC releases it can help us to
>>>>>>>>>> steer
>>>>>>>>>>
>>>>>>>>>> who
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>> is able and when it is possible to download OpenOffice like we want
>>>>>>> to
>>>>>>>>
>>>>>>>>
>>>>>>>>> see
>>>>>>>>>>
>>>>>>>>>> until the real release date is reached.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Marcus
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Sure, sites could still copy all binaries being voted upon
>>>>>>>>>> and
>>>>>>>>>> offer
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> them locally, but this would require a more significant effort.
>>>>>>>>>>> on
>>>>>>>>>>>>>
>>>>>>>>>>>>> their
>>>>>>>>>>>>> side.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> And more HDD space and more own bandwith - which is also not
>>>>>>>>>>>>
>>>>>>>>>>>> what
>>>>>>>>>>>>
>>>>>>>>>>>> they
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>> want.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> Marcus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 04/02/2014 09:22 PM, schrieb Roberto Galoppini:
> 2014-04-02 21:15 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>
>> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:
>>
>> 2014-04-01 21:30 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>>
>>> Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
>>>>
>>>> On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<ro...@apache.org> wrote:
>>>>
>>>>>
>>>>> On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)<ma...@wtnet.de>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
>>>>>>>
>>>>>>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>>>
>>>>>>>>
>>>>>>>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Rob Weir wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Andrew's comments show clearly that these editors do not care
>>>>>>>>>>>> to be
>>>>>>>>>>>> careful or factual, or even read those disclaimers,
>>>>>>>>>>>> unfortunately.
>>>>>>>>>>>>
>>>>>>>>>>>> We can be successful only if we manage to block their downloads.
>>>>>>>>>>>>
>>>>>>>>>>>> They
>>>>>>>>>>>
>>>>>>>>>>
>>>>>> link to our binaries hosted on SourceForge (which is fine). Just
>>>>>>>
>>>>>>>> thinking loud, but if it was possible (on the Sourceforge side) to
>>>>>>>>>>>> deny
>>>>>>>>>>>> all download requests that do not come from the openoffice.orgor
>>>>>>>>>>>>
>>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>
>>>>>> sourceforge.net domains, then the project would effectively be in
>>>>>>>
>>>>>>>> control. The embargo could be lifted just after the release.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> For me this sounds like a great idea.
>>>>>>>>>>>
>>>>>>>>>>> Maybe we should start with denying all download requests that some
>>>>>>>>>>>
>>>>>>>>>>> from
>>>>>>>>>>
>>>>>>>>>
>>>>>> these bad websites.
>>>>>>>
>>>>>>>>
>>>>>>>>>>> @Roberto:
>>>>>>>>>>> Can you tell us if this possible? If yes, is it much effort for
>>>>>>>>>>> you?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Do you see a chance to get this implemented? I think it could
>>>>>>>>>> help to
>>>>>>>>>> stop some bad websites to do bad things with our software.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> @Roberto:
>>>>>>>>> Maybe you haven't seen this up to now.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks for heads up Marcus, sorry for not having noticed this
>>>>>>>> thread
>>>>>>>> before.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> It would be great if you can tell us if it's possible to exclude
>>>>>>>>> some
>>>>>>>>> domains / IP addresses from downloading our software?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I need the domain list and I'll check out with our SiteOps if
>>>>>>>> that's
>>>>>>>> doable. Feel free to send me a list with a direct message.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> - chip.de
>>>>>>> - computerbase.de
>>>>>>> - softpedia.com
>>>>>>>
>>>>>>> This would be the domains from this thread that could be blocked from
>>>>>>> downloading from Sourceforge. Obviously needs to be extended in the
>>>>>>>
>>>>>>> future.
>>>>>>
>>>>>> Remember, the next will happen with the AOO 4.1.0 RC. ;-)
>>>>>>>
>>>>>>> *Of course*, this is just for the time frame as long as the new
>>>>>>> version
>>>>>>>
>>>>>>> is
>>>>>>
>>>>>> not officially announced. As soon as the release is public, the block
>>>>>>>
>>>>>>> will
>>>>>>
>>>>>> be removed.
>>>>>>>
>>>>>>> @all:
>>>>>>> I think this could help to limit the downloadability like we want to
>>>>>>> see
>>>>>>> until the official release. What you think?
>>>>>>>
>>>>>>>
>>>>>>> I don't know. Won't this just cause confusion? They point to the
>>>>>> files, go to test them, see the links don't work, and then get weird
>>>>>> errors and spend an hour trying to debug it. We don't want to
>>>>>> needlessly annoy them, since their only fault is enthusiasm. Is
>>>>>> there a way we can give a useful error message in this case like,
>>>>>> "This version of Apache OpenOffice has not yet been officially
>>>>>> released. Links to these files are disallowed until the release is
>>>>>> officially approved" or something like that?
>>>>>>
>>>>>>
>>>>> To be honest, I don't care about a few days were a special set of
>>>> domains
>>>> were not able to access for a few days. For me they are a bit too
>>>> enthusiastic. And as you said in a previous post it's to protect us as
>>>> best
>>>> as possible.
>>>>
>>>>
>>>> +1 This seems sufficient to me.
>>>>
>>>>>
>>>>>
>>>> @Roberto:
>>>> Do you see a technical way to return a predefined error message when the
>>>> release builds are already on Sourceforge but not yet officially released
>>>> and published?
>>>>
>>>>
>>> Our SiteOps team looked into this, here our findings:
>>>
>>
>> Great :-)
>>
>>
>> One provider (chip.de) serves via Akamai CDN, one provider (
>>> computerbase.de)
>>> serves via their own FTP server, and softpedia.com lists SourceForge as
>>> an
>>> external mirror and passes traffic through our download redirector flow
>>> (not direct to a mirror).
>>>
>>> The first two cases are things we can't control.
>>>
>>> In the third case, we can indeed redirect this traffic by referrer to a
>>> different landing page if one is provided. Maybe we want to have a
>>> openoffice.org page explaining that's a release-candidate and it's served
>>> only for testing purposes and its use on a daily basis it is not
>>> recommended.
>>>
>>> How does that sound?
>>>
>>
>> I'm pretty sure that these kind of downloaders do not care about
>> disclaimers - less then ever when located somewhere else. ;-)
>>
>> So, either we disable the entire download for the specific timeframe or at
>> least a text as substitute (like "This release is not yet public. Please
>> stay tuned and come back when it is announced."). But this text has then to
>> be on Sourceforge in the same location.
>>
>
> Yes, that's doable in the way Kay described. And yes, we would add the text
> and disable downloads.
Just to be sure, is this limited to a special subdir like
".../files/milestones/"? Or also, additionally for ".../files/"?
>> I'm wondering if the "staging" bit can help as best solution. I would
>> expect that the new location is not public *and* not known *and* not
>> useable/functional for the normal non-admin user *until* we remove the bit.
>> Am I right?
>
>
> In past we extended the 'staging' period of time for weeks, this could be
> done again if necessary and it's definitely a more effective way to share
Good to know. I thought you had extended the timeframe permanentelly. ;-)
> files only with a selected audience (admins). Would that work, or you want
> to be able to share those files with a larger audience?
I don't think it's relevant to a wider audience.
We still speak about the timeframe between starting uploading to
Sourceforge and the official announcement. Within this timeframe it
should be possible for admins to test the download webpage with
scripting - to see if it will work - but there must not be no way to
download the builds from the public.
So, I would prefer to go with the "staging"-bit as:
- it is already available
- there is no confusion for the public
- it's easy to delete the bit to make the release public
- and (please don't get me wrong ;-) ) we can do it alone without the
help of you or someone else of Sourceforge.
What do others think about this?
Thanks
Marcus
>> Then we can exclude requester that we don't want (e.g., malware
>>>>
>>>>> "distributors").
>>>>>>>>>
>>>>>>>>> Also in time frames with Beta or RC releases it can help us to steer
>>>>>>>>>
>>>>>>>>> who
>>>>>>>>
>>>>>>>
>>>>>> is able and when it is possible to download OpenOffice like we want to
>>>>>>>
>>>>>>>> see
>>>>>>>>> until the real release date is reached.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Marcus
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sure, sites could still copy all binaries being voted upon and
>>>>>>>>> offer
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> them locally, but this would require a more significant effort. on
>>>>>>>>>>>> their
>>>>>>>>>>>> side.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> And more HDD space and more own bandwith - which is also not
>>>>>>>>>>> what
>>>>>>>>>>>
>>>>>>>>>>> they
>>>>>>>>>>
>>>>>>>>>
>>>>>> want.
>>>>>>>
>>>>>>>>
>>>>>>>>>>> Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Roberto Galoppini <ro...@gmail.com>.
2014-04-02 21:15 GMT+02:00 Marcus (OOo) <ma...@wtnet.de>:
> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:
>
> 2014-04-01 21:30 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>
>> Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
>>>
>>> On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<ro...@apache.org> wrote:
>>>
>>>>
>>>> On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)<ma...@wtnet.de>
>>>>
>>>>> wrote:
>>>>>
>>>>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
>>>>>>
>>>>>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>>
>>>>>>>
>>>>>>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
>>>>>>>
>>>>>>>>
>>>>>>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Rob Weir wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Andrew's comments show clearly that these editors do not care
>>>>>>>>>>> to be
>>>>>>>>>>> careful or factual, or even read those disclaimers,
>>>>>>>>>>> unfortunately.
>>>>>>>>>>>
>>>>>>>>>>> We can be successful only if we manage to block their downloads.
>>>>>>>>>>>
>>>>>>>>>>> They
>>>>>>>>>>
>>>>>>>>>
>>>>> link to our binaries hosted on SourceForge (which is fine). Just
>>>>>>
>>>>>>> thinking loud, but if it was possible (on the Sourceforge side) to
>>>>>>>>>>> deny
>>>>>>>>>>> all download requests that do not come from the openoffice.orgor
>>>>>>>>>>>
>>>>>>>>>>> the
>>>>>>>>>>
>>>>>>>>>
>>>>> sourceforge.net domains, then the project would effectively be in
>>>>>>
>>>>>>> control. The embargo could be lifted just after the release.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> For me this sounds like a great idea.
>>>>>>>>>>
>>>>>>>>>> Maybe we should start with denying all download requests that some
>>>>>>>>>>
>>>>>>>>>> from
>>>>>>>>>
>>>>>>>>
>>>>> these bad websites.
>>>>>>
>>>>>>>
>>>>>>>>>> @Roberto:
>>>>>>>>>> Can you tell us if this possible? If yes, is it much effort for
>>>>>>>>>> you?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Do you see a chance to get this implemented? I think it could
>>>>>>>>> help to
>>>>>>>>> stop some bad websites to do bad things with our software.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> @Roberto:
>>>>>>>> Maybe you haven't seen this up to now.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks for heads up Marcus, sorry for not having noticed this
>>>>>>> thread
>>>>>>> before.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> It would be great if you can tell us if it's possible to exclude
>>>>>>>> some
>>>>>>>> domains / IP addresses from downloading our software?
>>>>>>>>
>>>>>>>>
>>>>>>>> I need the domain list and I'll check out with our SiteOps if
>>>>>>> that's
>>>>>>> doable. Feel free to send me a list with a direct message.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> - chip.de
>>>>>> - computerbase.de
>>>>>> - softpedia.com
>>>>>>
>>>>>> This would be the domains from this thread that could be blocked from
>>>>>> downloading from Sourceforge. Obviously needs to be extended in the
>>>>>>
>>>>>> future.
>>>>>
>>>>> Remember, the next will happen with the AOO 4.1.0 RC. ;-)
>>>>>>
>>>>>> *Of course*, this is just for the time frame as long as the new
>>>>>> version
>>>>>>
>>>>>> is
>>>>>
>>>>> not officially announced. As soon as the release is public, the block
>>>>>>
>>>>>> will
>>>>>
>>>>> be removed.
>>>>>>
>>>>>> @all:
>>>>>> I think this could help to limit the downloadability like we want to
>>>>>> see
>>>>>> until the official release. What you think?
>>>>>>
>>>>>>
>>>>>> I don't know. Won't this just cause confusion? They point to the
>>>>> files, go to test them, see the links don't work, and then get weird
>>>>> errors and spend an hour trying to debug it. We don't want to
>>>>> needlessly annoy them, since their only fault is enthusiasm. Is
>>>>> there a way we can give a useful error message in this case like,
>>>>> "This version of Apache OpenOffice has not yet been officially
>>>>> released. Links to these files are disallowed until the release is
>>>>> officially approved" or something like that?
>>>>>
>>>>>
>>>> To be honest, I don't care about a few days were a special set of
>>> domains
>>> were not able to access for a few days. For me they are a bit too
>>> enthusiastic. And as you said in a previous post it's to protect us as
>>> best
>>> as possible.
>>>
>>>
>>> +1 This seems sufficient to me.
>>>
>>>>
>>>>
>>> @Roberto:
>>> Do you see a technical way to return a predefined error message when the
>>> release builds are already on Sourceforge but not yet officially released
>>> and published?
>>>
>>>
>> Our SiteOps team looked into this, here our findings:
>>
>
> Great :-)
>
>
> One provider (chip.de) serves via Akamai CDN, one provider (
>> computerbase.de)
>> serves via their own FTP server, and softpedia.com lists SourceForge as
>> an
>> external mirror and passes traffic through our download redirector flow
>> (not direct to a mirror).
>>
>> The first two cases are things we can't control.
>>
>> In the third case, we can indeed redirect this traffic by referrer to a
>> different landing page if one is provided. Maybe we want to have a
>> openoffice.org page explaining that's a release-candidate and it's served
>> only for testing purposes and its use on a daily basis it is not
>> recommended.
>>
>> How does that sound?
>>
>
> I'm pretty sure that these kind of downloaders do not care about
> disclaimers - less then ever when located somewhere else. ;-)
>
> So, either we disable the entire download for the specific timeframe or at
> least a text as substitute (like "This release is not yet public. Please
> stay tuned and come back when it is announced."). But this text has then to
> be on Sourceforge in the same location.
>
Yes, that's doable in the way Kay described. And yes, we would add the text
and disable downloads.
>
> I'm wondering if the "staging" bit can help as best solution. I would
> expect that the new location is not public *and* not known *and* not
> useable/functional for the normal non-admin user *until* we remove the bit.
> Am I right?
In past we extended the 'staging' period of time for weeks, this could be
done again if necessary and it's definitely a more effective way to share
files only with a selected audience (admins). Would that work, or you want
to be able to share those files with a larger audience?
Roberto
>
>
> Thanks
>
> Marcus
>
>
>
> Then we can exclude requester that we don't want (e.g., malware
>>>
>>>> "distributors").
>>>>>>>>
>>>>>>>> Also in time frames with Beta or RC releases it can help us to steer
>>>>>>>>
>>>>>>>> who
>>>>>>>
>>>>>>
>>>>> is able and when it is possible to download OpenOffice like we want to
>>>>>>
>>>>>>> see
>>>>>>>> until the real release date is reached.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>>
>>>>>>>> Marcus
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Sure, sites could still copy all binaries being voted upon and
>>>>>>>> offer
>>>>>>>>
>>>>>>>>
>>>>>>>>> them locally, but this would require a more significant effort. on
>>>>>>>>>>> their
>>>>>>>>>>> side.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> And more HDD space and more own bandwith - which is also not
>>>>>>>>>> what
>>>>>>>>>>
>>>>>>>>>> they
>>>>>>>>>
>>>>>>>>
>>>>> want.
>>>>>>
>>>>>>>
>>>>>>>>>> Marcus
>>>>>>>>>>
>>>>>>>>>
Re: Anything we can do about premature redistribution?
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:
> 2014-04-01 21:30 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>
>> Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
>>
>> On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<ro...@apache.org> wrote:
>>>
>>> On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)<ma...@wtnet.de>
>>>> wrote:
>>>>
>>>>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
>>>>>
>>>>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>>
>>>>>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
>>>>>>>
>>>>>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
>>>>>>>>
>>>>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>>>>>>
>>>>>>>>> Rob Weir wrote:
>>>>>>>>>>
>>>>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Andrew's comments show clearly that these editors do not care to be
>>>>>>>>>> careful or factual, or even read those disclaimers, unfortunately.
>>>>>>>>>>
>>>>>>>>>> We can be successful only if we manage to block their downloads.
>>>>>>>>>>
>>>>>>>>> They
>>>>
>>>>> link to our binaries hosted on SourceForge (which is fine). Just
>>>>>>>>>> thinking loud, but if it was possible (on the Sourceforge side) to
>>>>>>>>>> deny
>>>>>>>>>> all download requests that do not come from the openoffice.org or
>>>>>>>>>>
>>>>>>>>> the
>>>>
>>>>> sourceforge.net domains, then the project would effectively be in
>>>>>>>>>> control. The embargo could be lifted just after the release.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> For me this sounds like a great idea.
>>>>>>>>>
>>>>>>>>> Maybe we should start with denying all download requests that some
>>>>>>>>>
>>>>>>>> from
>>>>
>>>>> these bad websites.
>>>>>>>>>
>>>>>>>>> @Roberto:
>>>>>>>>> Can you tell us if this possible? If yes, is it much effort for you?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Do you see a chance to get this implemented? I think it could help to
>>>>>>>> stop some bad websites to do bad things with our software.
>>>>>>>>
>>>>>>>>
>>>>>>> @Roberto:
>>>>>>> Maybe you haven't seen this up to now.
>>>>>>>
>>>>>>>
>>>>>> Thanks for heads up Marcus, sorry for not having noticed this thread
>>>>>> before.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> It would be great if you can tell us if it's possible to exclude some
>>>>>>> domains / IP addresses from downloading our software?
>>>>>>>
>>>>>>>
>>>>>> I need the domain list and I'll check out with our SiteOps if that's
>>>>>> doable. Feel free to send me a list with a direct message.
>>>>>>
>>>>>
>>>>>
>>>>> - chip.de
>>>>> - computerbase.de
>>>>> - softpedia.com
>>>>>
>>>>> This would be the domains from this thread that could be blocked from
>>>>> downloading from Sourceforge. Obviously needs to be extended in the
>>>>>
>>>> future.
>>>>
>>>>> Remember, the next will happen with the AOO 4.1.0 RC. ;-)
>>>>>
>>>>> *Of course*, this is just for the time frame as long as the new version
>>>>>
>>>> is
>>>>
>>>>> not officially announced. As soon as the release is public, the block
>>>>>
>>>> will
>>>>
>>>>> be removed.
>>>>>
>>>>> @all:
>>>>> I think this could help to limit the downloadability like we want to see
>>>>> until the official release. What you think?
>>>>>
>>>>>
>>>> I don't know. Won't this just cause confusion? They point to the
>>>> files, go to test them, see the links don't work, and then get weird
>>>> errors and spend an hour trying to debug it. We don't want to
>>>> needlessly annoy them, since their only fault is enthusiasm. Is
>>>> there a way we can give a useful error message in this case like,
>>>> "This version of Apache OpenOffice has not yet been officially
>>>> released. Links to these files are disallowed until the release is
>>>> officially approved" or something like that?
>>>>
>>>
>> To be honest, I don't care about a few days were a special set of domains
>> were not able to access for a few days. For me they are a bit too
>> enthusiastic. And as you said in a previous post it's to protect us as best
>> as possible.
>>
>>
>> +1 This seems sufficient to me.
>>>
>>
>> @Roberto:
>> Do you see a technical way to return a predefined error message when the
>> release builds are already on Sourceforge but not yet officially released
>> and published?
>>
>
> Our SiteOps team looked into this, here our findings:
Great :-)
> One provider (chip.de) serves via Akamai CDN, one provider (computerbase.de)
> serves via their own FTP server, and softpedia.com lists SourceForge as an
> external mirror and passes traffic through our download redirector flow
> (not direct to a mirror).
>
> The first two cases are things we can't control.
>
> In the third case, we can indeed redirect this traffic by referrer to a
> different landing page if one is provided. Maybe we want to have a
> openoffice.org page explaining that's a release-candidate and it's served
> only for testing purposes and its use on a daily basis it is not
> recommended.
>
> How does that sound?
I'm pretty sure that these kind of downloaders do not care about
disclaimers - less then ever when located somewhere else. ;-)
So, either we disable the entire download for the specific timeframe or
at least a text as substitute (like "This release is not yet public.
Please stay tuned and come back when it is announced."). But this text
has then to be on Sourceforge in the same location.
I'm wondering if the "staging" bit can help as best solution. I would
expect that the new location is not public *and* not known *and* not
useable/functional for the normal non-admin user *until* we remove the
bit. Am I right?
Thanks
Marcus
>> Then we can exclude requester that we don't want (e.g., malware
>>>>>>> "distributors").
>>>>>>>
>>>>>>> Also in time frames with Beta or RC releases it can help us to steer
>>>>>>>
>>>>>> who
>>>>
>>>>> is able and when it is possible to download OpenOffice like we want to
>>>>>>> see
>>>>>>> until the real release date is reached.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>>
>>>>>>> Marcus
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Sure, sites could still copy all binaries being voted upon and
>>>>>>> offer
>>>>>>>
>>>>>>>>
>>>>>>>>>> them locally, but this would require a more significant effort. on
>>>>>>>>>> their
>>>>>>>>>> side.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> And more HDD space and more own bandwith - which is also not what
>>>>>>>>>
>>>>>>>> they
>>>>
>>>>> want.
>>>>>>>>>
>>>>>>>>> Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 04/02/2014 06:52 PM, schrieb Kay Schenk:
> On Wed, Apr 2, 2014 at 9:20 AM, Roberto Galoppini<
> roberto.galoppini@gmail.com> wrote:
>
>> 2014-04-01 21:30 GMT+02:00 Marcus (OOo)<ma...@wtnet.de>:
>>
>>> Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
>>>
>>> On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<ro...@apache.org> wrote:
>>>>
>>>> On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)<ma...@wtnet.de>
>>>>> wrote:
>>>>>
>>>>>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
>>>>>>
>>>>>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>>>
>>>>>>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
>>>>>>>>
>>>>>>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
>>>>>>>>>
>>>>>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>>>>>>>
>>>>>>>>>> Rob Weir wrote:
>>>>>>>>>>>
>>>>>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Andrew's comments show clearly that these editors do not care to
>> be
>>>>>>>>>>> careful or factual, or even read those disclaimers,
>> unfortunately.
>>>>>>>>>>>
>>>>>>>>>>> We can be successful only if we manage to block their downloads.
>>>>>>>>>>>
>>>>>>>>>> They
>>>>>
>>>>>> link to our binaries hosted on SourceForge (which is fine). Just
>>>>>>>>>>> thinking loud, but if it was possible (on the Sourceforge side)
>> to
>>>>>>>>>>> deny
>>>>>>>>>>> all download requests that do not come from the openoffice.orgor
>>>>>>>>>>>
>>>>>>>>>> the
>>>>>
>>>>>> sourceforge.net domains, then the project would effectively be in
>>>>>>>>>>> control. The embargo could be lifted just after the release.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> For me this sounds like a great idea.
>>>>>>>>>>
>>>>>>>>>> Maybe we should start with denying all download requests that some
>>>>>>>>>>
>>>>>>>>> from
>>>>>
>>>>>> these bad websites.
>>>>>>>>>>
>>>>>>>>>> @Roberto:
>>>>>>>>>> Can you tell us if this possible? If yes, is it much effort for
>> you?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Do you see a chance to get this implemented? I think it could help
>> to
>>>>>>>>> stop some bad websites to do bad things with our software.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> @Roberto:
>>>>>>>> Maybe you haven't seen this up to now.
>>>>>>>>
>>>>>>>>
>>>>>>> Thanks for heads up Marcus, sorry for not having noticed this thread
>>>>>>> before.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> It would be great if you can tell us if it's possible to exclude
>> some
>>>>>>>> domains / IP addresses from downloading our software?
>>>>>>>>
>>>>>>>>
>>>>>>> I need the domain list and I'll check out with our SiteOps if that's
>>>>>>> doable. Feel free to send me a list with a direct message.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> - chip.de
>>>>>> - computerbase.de
>>>>>> - softpedia.com
>>>>>>
>>>>>> This would be the domains from this thread that could be blocked from
>>>>>> downloading from Sourceforge. Obviously needs to be extended in the
>>>>>>
>>>>> future.
>>>>>
>>>>>> Remember, the next will happen with the AOO 4.1.0 RC. ;-)
>>>>>>
>>>>>> *Of course*, this is just for the time frame as long as the new
>> version
>>>>>>
>>>>> is
>>>>>
>>>>>> not officially announced. As soon as the release is public, the block
>>>>>>
>>>>> will
>>>>>
>>>>>> be removed.
>>>>>>
>>>>>> @all:
>>>>>> I think this could help to limit the downloadability like we want to
>> see
>>>>>> until the official release. What you think?
>>>>>>
>>>>>>
>>>>> I don't know. Won't this just cause confusion? They point to the
>>>>> files, go to test them, see the links don't work, and then get weird
>>>>> errors and spend an hour trying to debug it. We don't want to
>>>>> needlessly annoy them, since their only fault is enthusiasm. Is
>>>>> there a way we can give a useful error message in this case like,
>>>>> "This version of Apache OpenOffice has not yet been officially
>>>>> released. Links to these files are disallowed until the release is
>>>>> officially approved" or something like that?
>>>>>
>>>>
>>> To be honest, I don't care about a few days were a special set of domains
>>> were not able to access for a few days. For me they are a bit too
>>> enthusiastic. And as you said in a previous post it's to protect us as
>> best
>>> as possible.
>>>
>>>
>>> +1 This seems sufficient to me.
>>>>
>>>
>>> @Roberto:
>>> Do you see a technical way to return a predefined error message when the
>>> release builds are already on Sourceforge but not yet officially released
>>> and published?
>>>
>>
>> Our SiteOps team looked into this, here our findings:
>>
>> One provider (chip.de) serves via Akamai CDN, one provider (
>> computerbase.de)
>> serves via their own FTP server, and softpedia.com lists SourceForge as an
>> external mirror and passes traffic through our download redirector flow
>> (not direct to a mirror).
>>
>> The first two cases are things we can't control.
>>
>> In the third case, we can indeed redirect this traffic by referrer to a
>> different landing page if one is provided. Maybe we want to have a
>> openoffice.org page explaining that's a release-candidate and it's served
>> only for testing purposes and its use on a daily basis it is not
>> recommended.
>>
>> How does that sound?
>>
>> Roberto
>>
>
> Roberto -- thanks for all this investigation.
>
>
> Should we assume that this caution should only be applied to:
>
> http://sourceforge.net/projects/openofficeorg.mirror/files/milestones/
>
> assuming this area would always be used for "betas"?
Without other opinions I would assume the same. For Beta or any other
pre-final releases this would help.
However, the problem remains when it comes to a final release that is
located one subdir up in ".../files/":
We want to protect the release builds until we have really announced it
officially.
So, IMHO it has to be a more generic solution like the "staging"-bit or
a substitute text (see my other mail to Roberto).
Marcus
>>> Then we can exclude requester that we don't want (e.g., malware
>>>>>>>> "distributors").
>>>>>>>>
>>>>>>>> Also in time frames with Beta or RC releases it can help us to steer
>>>>>>>>
>>>>>>> who
>>>>>
>>>>>> is able and when it is possible to download OpenOffice like we want to
>>>>>>>> see
>>>>>>>> until the real release date is reached.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Marcus
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Sure, sites could still copy all binaries being voted upon and
>>>>>>>> offer
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> them locally, but this would require a more significant effort.
>> on
>>>>>>>>>>> their
>>>>>>>>>>> side.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> And more HDD space and more own bandwith - which is also not what
>>>>>>>>>>
>>>>>>>>> they
>>>>>
>>>>>> want.
>>>>>>>>>>
>>>>>>>>>> Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Kay Schenk <ka...@gmail.com>.
On Wed, Apr 2, 2014 at 9:20 AM, Roberto Galoppini <
roberto.galoppini@gmail.com> wrote:
> 2014-04-01 21:30 GMT+02:00 Marcus (OOo) <ma...@wtnet.de>:
>
> > Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
> >
> > On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<ro...@apache.org> wrote:
> >>
> >> On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)<ma...@wtnet.de>
> >>> wrote:
> >>>
> >>>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
> >>>>
> >>>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<ma...@wtnet.de>:
> >>>>>
> >>>>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
> >>>>>>
> >>>>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
> >>>>>>>
> >>>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
> >>>>>>>>
> >>>>>>>> Rob Weir wrote:
> >>>>>>>>>
> >>>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>> Apache-OpenOffice-253.shtml
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> Andrew's comments show clearly that these editors do not care to
> be
> >>>>>>>>> careful or factual, or even read those disclaimers,
> unfortunately.
> >>>>>>>>>
> >>>>>>>>> We can be successful only if we manage to block their downloads.
> >>>>>>>>>
> >>>>>>>> They
> >>>
> >>>> link to our binaries hosted on SourceForge (which is fine). Just
> >>>>>>>>> thinking loud, but if it was possible (on the Sourceforge side)
> to
> >>>>>>>>> deny
> >>>>>>>>> all download requests that do not come from the openoffice.orgor
> >>>>>>>>>
> >>>>>>>> the
> >>>
> >>>> sourceforge.net domains, then the project would effectively be in
> >>>>>>>>> control. The embargo could be lifted just after the release.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> For me this sounds like a great idea.
> >>>>>>>>
> >>>>>>>> Maybe we should start with denying all download requests that some
> >>>>>>>>
> >>>>>>> from
> >>>
> >>>> these bad websites.
> >>>>>>>>
> >>>>>>>> @Roberto:
> >>>>>>>> Can you tell us if this possible? If yes, is it much effort for
> you?
> >>>>>>>>
> >>>>>>>>
> >>>>>>> Do you see a chance to get this implemented? I think it could help
> to
> >>>>>>> stop some bad websites to do bad things with our software.
> >>>>>>>
> >>>>>>>
> >>>>>> @Roberto:
> >>>>>> Maybe you haven't seen this up to now.
> >>>>>>
> >>>>>>
> >>>>> Thanks for heads up Marcus, sorry for not having noticed this thread
> >>>>> before.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> It would be great if you can tell us if it's possible to exclude
> some
> >>>>>> domains / IP addresses from downloading our software?
> >>>>>>
> >>>>>>
> >>>>> I need the domain list and I'll check out with our SiteOps if that's
> >>>>> doable. Feel free to send me a list with a direct message.
> >>>>>
> >>>>
> >>>>
> >>>> - chip.de
> >>>> - computerbase.de
> >>>> - softpedia.com
> >>>>
> >>>> This would be the domains from this thread that could be blocked from
> >>>> downloading from Sourceforge. Obviously needs to be extended in the
> >>>>
> >>> future.
> >>>
> >>>> Remember, the next will happen with the AOO 4.1.0 RC. ;-)
> >>>>
> >>>> *Of course*, this is just for the time frame as long as the new
> version
> >>>>
> >>> is
> >>>
> >>>> not officially announced. As soon as the release is public, the block
> >>>>
> >>> will
> >>>
> >>>> be removed.
> >>>>
> >>>> @all:
> >>>> I think this could help to limit the downloadability like we want to
> see
> >>>> until the official release. What you think?
> >>>>
> >>>>
> >>> I don't know. Won't this just cause confusion? They point to the
> >>> files, go to test them, see the links don't work, and then get weird
> >>> errors and spend an hour trying to debug it. We don't want to
> >>> needlessly annoy them, since their only fault is enthusiasm. Is
> >>> there a way we can give a useful error message in this case like,
> >>> "This version of Apache OpenOffice has not yet been officially
> >>> released. Links to these files are disallowed until the release is
> >>> officially approved" or something like that?
> >>>
> >>
> > To be honest, I don't care about a few days were a special set of domains
> > were not able to access for a few days. For me they are a bit too
> > enthusiastic. And as you said in a previous post it's to protect us as
> best
> > as possible.
> >
> >
> > +1 This seems sufficient to me.
> >>
> >
> > @Roberto:
> > Do you see a technical way to return a predefined error message when the
> > release builds are already on Sourceforge but not yet officially released
> > and published?
> >
>
> Our SiteOps team looked into this, here our findings:
>
> One provider (chip.de) serves via Akamai CDN, one provider (
> computerbase.de)
> serves via their own FTP server, and softpedia.com lists SourceForge as an
> external mirror and passes traffic through our download redirector flow
> (not direct to a mirror).
>
> The first two cases are things we can't control.
>
> In the third case, we can indeed redirect this traffic by referrer to a
> different landing page if one is provided. Maybe we want to have a
> openoffice.org page explaining that's a release-candidate and it's served
> only for testing purposes and its use on a daily basis it is not
> recommended.
>
> How does that sound?
>
> Roberto
>
Roberto -- thanks for all this investigation.
Should we assume that this caution should only be applied to:
http://sourceforge.net/projects/openofficeorg.mirror/files/milestones/
assuming this area would always be used for "betas"?
>
> >
> > Thanks
> >
> >
> > Marcus
> >
> >
> >
> > Then we can exclude requester that we don't want (e.g., malware
> >>>>>> "distributors").
> >>>>>>
> >>>>>> Also in time frames with Beta or RC releases it can help us to steer
> >>>>>>
> >>>>> who
> >>>
> >>>> is able and when it is possible to download OpenOffice like we want to
> >>>>>> see
> >>>>>> until the real release date is reached.
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Thanks
> >>>>>>
> >>>>>> Marcus
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Sure, sites could still copy all binaries being voted upon and
> >>>>>> offer
> >>>>>>
> >>>>>>>
> >>>>>>>>> them locally, but this would require a more significant effort.
> on
> >>>>>>>>> their
> >>>>>>>>> side.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> And more HDD space and more own bandwith - which is also not what
> >>>>>>>>
> >>>>>>> they
> >>>
> >>>> want.
> >>>>>>>>
> >>>>>>>> Marcus
> >>>>>>>>
> >>>>>>>
>
--
-------------------------------------------------------------------------------------------------
MzK
"Cats do not have to be shown how to have a good time,
for they are unfailing ingenious in that respect."
-- James Mason
Re: Anything we can do about premature redistribution?
Posted by Roberto Galoppini <ro...@gmail.com>.
2014-04-23 1:37 GMT+02:00 Andrea Pescetti <pe...@apache.org>:
> On 22/04/2014 Roberto Galoppini wrote:
>
>> 2014-04-22 0:14 GMT+02:00 Andrea Pescetti:
>>
>>> http://www.openoffice.org/download/devbuilds.html
>>>
>> Andrea are you saying we should re-route RCs download requests coming from
>> all referrals (but openoffice.org and sourceforge.net) to that page?
>>
>
> That would be the proposal, yes. Add apache.org to the whitelisted
> referrals.
>
>
> Please confirm my understand is correct and provide me with the exact
>> directory/files so that I can ask our SiteOps to implement that right away
>>
>
> I don't think we already have the files online. The files to be redirected
> are the Release Candidates, and I may be wrong but I assume that RC4 is not
> yet on SourceForge and will be uploaded during or immediately after the
> vote.
Ok, I'm assuming those files will be in a directory called 4.1? Please let
me know, so that I can move with this plan accordingly.
Roberto
> During this period (lasting a few days) we don't want to allow downloads
> until we send out the official release news. Reason: we may (and we did it
> already) decide to push a last-minute fix even when a release has been
> approved but is not distributed yet.
>
>
> Regards,
> Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Anything we can do about premature redistribution?
Posted by Andrea Pescetti <pe...@apache.org>.
On 22/04/2014 Roberto Galoppini wrote:
> 2014-04-22 0:14 GMT+02:00 Andrea Pescetti:
>> http://www.openoffice.org/download/devbuilds.html
> Andrea are you saying we should re-route RCs download requests coming from
> all referrals (but openoffice.org and sourceforge.net) to that page?
That would be the proposal, yes. Add apache.org to the whitelisted
referrals.
> Please confirm my understand is correct and provide me with the exact
> directory/files so that I can ask our SiteOps to implement that right away
I don't think we already have the files online. The files to be
redirected are the Release Candidates, and I may be wrong but I assume
that RC4 is not yet on SourceForge and will be uploaded during or
immediately after the vote. During this period (lasting a few days) we
don't want to allow downloads until we send out the official release
news. Reason: we may (and we did it already) decide to push a
last-minute fix even when a release has been approved but is not
distributed yet.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Roberto Galoppini <ro...@gmail.com>.
2014-04-22 0:14 GMT+02:00 Andrea Pescetti <pe...@apache.org>:
> On 19/04/2014 Roberto Galoppini wrote:
>
>> Our aim I believe it's to expand our userbase, redirecting them to an
>> openoffice page explaining which are the options might be a good thing.
>>
>
> We can reuse, and possibly reword, this page then:
> http://www.openoffice.org/download/devbuilds.html
>
> This is where people trying to download a yet unapproved RC would land, so
> the content, disclaimers and links seem quite appropriate.
Andrea are you saying we should re-route RCs download requests coming from
all referrals (but openoffice.org and sourceforge.net) to that page?
Please confirm my understand is correct and provide me with the exact
directory/files so that I can ask our SiteOps to implement that right away,
I'll do that once I'll get the green light.
Thanks,
Roberto
>
>
> Regards,
> Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Anything we can do about premature redistribution?
Posted by Andrea Pescetti <pe...@apache.org>.
On 19/04/2014 Roberto Galoppini wrote:
> Our aim I believe it's to expand our userbase, redirecting them to an
> openoffice page explaining which are the options might be a good thing.
We can reuse, and possibly reword, this page then:
http://www.openoffice.org/download/devbuilds.html
This is where people trying to download a yet unapproved RC would land,
so the content, disclaimers and links seem quite appropriate.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Roberto Galoppini <ro...@gmail.com>.
2014-04-19 16:21 GMT+02:00 Andrea Pescetti <pe...@apache.org>:
> On 02/04/2014 Roberto Galoppini wrote:
>
>> softpedia.com ... passes traffic through our download redirector flow
>> ... we can indeed redirect this traffic by referrer to a
>>
>> different landing page if one is provided.
>>
>
> Can't we just serve a 403? It's their problem, not ours. It's not rude at
> all, it's a way to protect our users: if we don't want that our unreleased
> versions are purported for real releases, we need that users only access
> them from a page on apache.org, on openoffice.org or e-mail until we
> release them.
>
> So matching the HTTP referer and serving a 403 unless it comes from *.
> apache.org , *.openoffice.org or is empty seems the best solution to me.
> If we really want to be extra-polite, http://www.openoffice.org/
> download/devbuilds.html should be scary enough for casual users.
>
We could take the chance to educate those users about which is the last
available version, though. Reading Softpedia site it's clear they are not
providing the end-user with a way to pick up 4.0.1 or 4.1 beta, and the
title is just confusing "Apache OpenOffice.org 4.0.1 / 4.1.0 Beta".
Our aim I believe it's to expand our userbase, redirecting them to an
openoffice page explaining which are the options might be a good thing.
Thoughts?
>
> Of course, if this is a manual operation that must be done when we enter
> RC phase and undone after release, and only the SourceForge staff can do
> that, then this becomes a bit complex. Or can the project members who have
> access to the SourceForge area enable/disable the protection with no need
> for external help?
>
So far regex-based redirect based on referral need to be managed by
SiteOps, but I can make sure we get what we want.
Roberto
>
> Regards,
> Andrea.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Anything we can do about premature redistribution?
Posted by Andrea Pescetti <pe...@apache.org>.
On 02/04/2014 Roberto Galoppini wrote:
> softpedia.com ... passes traffic through our download redirector flow
> ... we can indeed redirect this traffic by referrer to a
> different landing page if one is provided.
Can't we just serve a 403? It's their problem, not ours. It's not rude
at all, it's a way to protect our users: if we don't want that our
unreleased versions are purported for real releases, we need that users
only access them from a page on apache.org, on openoffice.org or e-mail
until we release them.
So matching the HTTP referer and serving a 403 unless it comes from
*.apache.org , *.openoffice.org or is empty seems the best solution to
me. If we really want to be extra-polite,
http://www.openoffice.org/download/devbuilds.html should be scary enough
for casual users.
Of course, if this is a manual operation that must be done when we enter
RC phase and undone after release, and only the SourceForge staff can do
that, then this becomes a bit complex. Or can the project members who
have access to the SourceForge area enable/disable the protection with
no need for external help?
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Roberto Galoppini <ro...@gmail.com>.
2014-04-01 21:30 GMT+02:00 Marcus (OOo) <ma...@wtnet.de>:
> Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
>
> On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<ro...@apache.org> wrote:
>>
>> On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)<ma...@wtnet.de>
>>> wrote:
>>>
>>>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
>>>>
>>>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>>
>>>>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
>>>>>>
>>>>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
>>>>>>>
>>>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>>>>>
>>>>>>>> Rob Weir wrote:
>>>>>>>>>
>>>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Andrew's comments show clearly that these editors do not care to be
>>>>>>>>> careful or factual, or even read those disclaimers, unfortunately.
>>>>>>>>>
>>>>>>>>> We can be successful only if we manage to block their downloads.
>>>>>>>>>
>>>>>>>> They
>>>
>>>> link to our binaries hosted on SourceForge (which is fine). Just
>>>>>>>>> thinking loud, but if it was possible (on the Sourceforge side) to
>>>>>>>>> deny
>>>>>>>>> all download requests that do not come from the openoffice.org or
>>>>>>>>>
>>>>>>>> the
>>>
>>>> sourceforge.net domains, then the project would effectively be in
>>>>>>>>> control. The embargo could be lifted just after the release.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> For me this sounds like a great idea.
>>>>>>>>
>>>>>>>> Maybe we should start with denying all download requests that some
>>>>>>>>
>>>>>>> from
>>>
>>>> these bad websites.
>>>>>>>>
>>>>>>>> @Roberto:
>>>>>>>> Can you tell us if this possible? If yes, is it much effort for you?
>>>>>>>>
>>>>>>>>
>>>>>>> Do you see a chance to get this implemented? I think it could help to
>>>>>>> stop some bad websites to do bad things with our software.
>>>>>>>
>>>>>>>
>>>>>> @Roberto:
>>>>>> Maybe you haven't seen this up to now.
>>>>>>
>>>>>>
>>>>> Thanks for heads up Marcus, sorry for not having noticed this thread
>>>>> before.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> It would be great if you can tell us if it's possible to exclude some
>>>>>> domains / IP addresses from downloading our software?
>>>>>>
>>>>>>
>>>>> I need the domain list and I'll check out with our SiteOps if that's
>>>>> doable. Feel free to send me a list with a direct message.
>>>>>
>>>>
>>>>
>>>> - chip.de
>>>> - computerbase.de
>>>> - softpedia.com
>>>>
>>>> This would be the domains from this thread that could be blocked from
>>>> downloading from Sourceforge. Obviously needs to be extended in the
>>>>
>>> future.
>>>
>>>> Remember, the next will happen with the AOO 4.1.0 RC. ;-)
>>>>
>>>> *Of course*, this is just for the time frame as long as the new version
>>>>
>>> is
>>>
>>>> not officially announced. As soon as the release is public, the block
>>>>
>>> will
>>>
>>>> be removed.
>>>>
>>>> @all:
>>>> I think this could help to limit the downloadability like we want to see
>>>> until the official release. What you think?
>>>>
>>>>
>>> I don't know. Won't this just cause confusion? They point to the
>>> files, go to test them, see the links don't work, and then get weird
>>> errors and spend an hour trying to debug it. We don't want to
>>> needlessly annoy them, since their only fault is enthusiasm. Is
>>> there a way we can give a useful error message in this case like,
>>> "This version of Apache OpenOffice has not yet been officially
>>> released. Links to these files are disallowed until the release is
>>> officially approved" or something like that?
>>>
>>
> To be honest, I don't care about a few days were a special set of domains
> were not able to access for a few days. For me they are a bit too
> enthusiastic. And as you said in a previous post it's to protect us as best
> as possible.
>
>
> +1 This seems sufficient to me.
>>
>
> @Roberto:
> Do you see a technical way to return a predefined error message when the
> release builds are already on Sourceforge but not yet officially released
> and published?
>
Our SiteOps team looked into this, here our findings:
One provider (chip.de) serves via Akamai CDN, one provider (computerbase.de)
serves via their own FTP server, and softpedia.com lists SourceForge as an
external mirror and passes traffic through our download redirector flow
(not direct to a mirror).
The first two cases are things we can't control.
In the third case, we can indeed redirect this traffic by referrer to a
different landing page if one is provided. Maybe we want to have a
openoffice.org page explaining that's a release-candidate and it's served
only for testing purposes and its use on a daily basis it is not
recommended.
How does that sound?
Roberto
>
> Thanks
>
>
> Marcus
>
>
>
> Then we can exclude requester that we don't want (e.g., malware
>>>>>> "distributors").
>>>>>>
>>>>>> Also in time frames with Beta or RC releases it can help us to steer
>>>>>>
>>>>> who
>>>
>>>> is able and when it is possible to download OpenOffice like we want to
>>>>>> see
>>>>>> until the real release date is reached.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>>>
>>>>>> Marcus
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sure, sites could still copy all binaries being voted upon and
>>>>>> offer
>>>>>>
>>>>>>>
>>>>>>>>> them locally, but this would require a more significant effort. on
>>>>>>>>> their
>>>>>>>>> side.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> And more HDD space and more own bandwith - which is also not what
>>>>>>>>
>>>>>>> they
>>>
>>>> want.
>>>>>>>>
>>>>>>>> Marcus
>>>>>>>>
>>>>>>>
Re: Anything we can do about premature redistribution?
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
> On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<ro...@apache.org> wrote:
>
>> On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo)<ma...@wtnet.de>
>> wrote:
>>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
>>>
>>>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<ma...@wtnet.de>:
>>>>
>>>>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
>>>>>
>>>>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
>>>>>>
>>>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>>>>
>>>>>>>> Rob Weir wrote:
>>>>>>>>
>>>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>>>>>
>>>>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Andrew's comments show clearly that these editors do not care to be
>>>>>>>> careful or factual, or even read those disclaimers, unfortunately.
>>>>>>>>
>>>>>>>> We can be successful only if we manage to block their downloads.
>> They
>>>>>>>> link to our binaries hosted on SourceForge (which is fine). Just
>>>>>>>> thinking loud, but if it was possible (on the Sourceforge side) to
>>>>>>>> deny
>>>>>>>> all download requests that do not come from the openoffice.org or
>> the
>>>>>>>> sourceforge.net domains, then the project would effectively be in
>>>>>>>> control. The embargo could be lifted just after the release.
>>>>>>>>
>>>>>>>
>>>>>>> For me this sounds like a great idea.
>>>>>>>
>>>>>>> Maybe we should start with denying all download requests that some
>> from
>>>>>>> these bad websites.
>>>>>>>
>>>>>>> @Roberto:
>>>>>>> Can you tell us if this possible? If yes, is it much effort for you?
>>>>>>>
>>>>>>
>>>>>> Do you see a chance to get this implemented? I think it could help to
>>>>>> stop some bad websites to do bad things with our software.
>>>>>>
>>>>>
>>>>> @Roberto:
>>>>> Maybe you haven't seen this up to now.
>>>>>
>>>>
>>>> Thanks for heads up Marcus, sorry for not having noticed this thread
>>>> before.
>>>>
>>>>
>>>>
>>>>>
>>>>> It would be great if you can tell us if it's possible to exclude some
>>>>> domains / IP addresses from downloading our software?
>>>>>
>>>>
>>>> I need the domain list and I'll check out with our SiteOps if that's
>>>> doable. Feel free to send me a list with a direct message.
>>>
>>>
>>> - chip.de
>>> - computerbase.de
>>> - softpedia.com
>>>
>>> This would be the domains from this thread that could be blocked from
>>> downloading from Sourceforge. Obviously needs to be extended in the
>> future.
>>> Remember, the next will happen with the AOO 4.1.0 RC. ;-)
>>>
>>> *Of course*, this is just for the time frame as long as the new version
>> is
>>> not officially announced. As soon as the release is public, the block
>> will
>>> be removed.
>>>
>>> @all:
>>> I think this could help to limit the downloadability like we want to see
>>> until the official release. What you think?
>>>
>>
>> I don't know. Won't this just cause confusion? They point to the
>> files, go to test them, see the links don't work, and then get weird
>> errors and spend an hour trying to debug it. We don't want to
>> needlessly annoy them, since their only fault is enthusiasm. Is
>> there a way we can give a useful error message in this case like,
>> "This version of Apache OpenOffice has not yet been officially
>> released. Links to these files are disallowed until the release is
>> officially approved" or something like that?
To be honest, I don't care about a few days were a special set of
domains were not able to access for a few days. For me they are a bit
too enthusiastic. And as you said in a previous post it's to protect us
as best as possible.
> +1 This seems sufficient to me.
@Roberto:
Do you see a technical way to return a predefined error message when the
release builds are already on Sourceforge but not yet officially
released and published?
Thanks
Marcus
>>>>> Then we can exclude requester that we don't want (e.g., malware
>>>>> "distributors").
>>>>>
>>>>> Also in time frames with Beta or RC releases it can help us to steer
>> who
>>>>> is able and when it is possible to download OpenOffice like we want to
>>>>> see
>>>>> until the real release date is reached.
>>>>
>>>>
>>>>
>>>>> Thanks
>>>>>
>>>>> Marcus
>>>>>
>>>>>
>>>>>
>>>>> Sure, sites could still copy all binaries being voted upon and offer
>>>>>>>>
>>>>>>>> them locally, but this would require a more significant effort. on
>>>>>>>> their
>>>>>>>> side.
>>>>>>>>
>>>>>>>
>>>>>>> And more HDD space and more own bandwith - which is also not what
>> they
>>>>>>> want.
>>>>>>>
>>>>>>> Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Kay Schenk <ka...@gmail.com>.
On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir <ro...@apache.org> wrote:
> On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) <ma...@wtnet.de>
> wrote:
> > Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
> >
> >> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<ma...@wtnet.de>:
> >>
> >>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
> >>>
> >>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
> >>>>
> >>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
> >>>>>
> >>>>>> Rob Weir wrote:
> >>>>>>
> >>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
> >>>>>>>>>>
> >>>>>>>>>> Apache-OpenOffice-253.shtml
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Or maybe a disclaimer in the voting thread email?
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> Andrew's comments show clearly that these editors do not care to be
> >>>>>> careful or factual, or even read those disclaimers, unfortunately.
> >>>>>>
> >>>>>> We can be successful only if we manage to block their downloads.
> They
> >>>>>> link to our binaries hosted on SourceForge (which is fine). Just
> >>>>>> thinking loud, but if it was possible (on the Sourceforge side) to
> >>>>>> deny
> >>>>>> all download requests that do not come from the openoffice.org or
> the
> >>>>>> sourceforge.net domains, then the project would effectively be in
> >>>>>> control. The embargo could be lifted just after the release.
> >>>>>>
> >>>>>
> >>>>> For me this sounds like a great idea.
> >>>>>
> >>>>> Maybe we should start with denying all download requests that some
> from
> >>>>> these bad websites.
> >>>>>
> >>>>> @Roberto:
> >>>>> Can you tell us if this possible? If yes, is it much effort for you?
> >>>>>
> >>>>
> >>>> Do you see a chance to get this implemented? I think it could help to
> >>>> stop some bad websites to do bad things with our software.
> >>>>
> >>>
> >>> @Roberto:
> >>> Maybe you haven't seen this up to now.
> >>>
> >>
> >> Thanks for heads up Marcus, sorry for not having noticed this thread
> >> before.
> >>
> >>
> >>
> >>>
> >>> It would be great if you can tell us if it's possible to exclude some
> >>> domains / IP addresses from downloading our software?
> >>>
> >>
> >> I need the domain list and I'll check out with our SiteOps if that's
> >> doable. Feel free to send me a list with a direct message.
> >
> >
> > - chip.de
> > - computerbase.de
> > - softpedia.com
> >
> > This would be the domains from this thread that could be blocked from
> > downloading from Sourceforge. Obviously needs to be extended in the
> future.
> > Remember, the next will happen with the AOO 4.1.0 RC. ;-)
> >
> > *Of course*, this is just for the time frame as long as the new version
> is
> > not officially announced. As soon as the release is public, the block
> will
> > be removed.
> >
> > @all:
> > I think this could help to limit the downloadability like we want to see
> > until the official release. What you think?
> >
>
> I don't know. Won't this just cause confusion? They point to the
> files, go to test them, see the links don't work, and then get weird
> errors and spend an hour trying to debug it. We don't want to
> needlessly annoy them, since their only fault is enthusiasm. Is
> there a way we can give a useful error message in this case like,
> "This version of Apache OpenOffice has not yet been officially
> released. Links to these files are disallowed until the release is
> officially approved" or something like that?
>
> -Rob
>
+1 This seems sufficient to me.
> > Marcus
> >
> >
> >
> >
> >>> Then we can exclude requester that we don't want (e.g., malware
> >>> "distributors").
> >>>
> >>> Also in time frames with Beta or RC releases it can help us to steer
> who
> >>> is able and when it is possible to download OpenOffice like we want to
> >>> see
> >>> until the real release date is reached.
> >>
> >>
> >>
> >>> Thanks
> >>>
> >>> Marcus
> >>>
> >>>
> >>>
> >>> Sure, sites could still copy all binaries being voted upon and offer
> >>>>>>
> >>>>>> them locally, but this would require a more significant effort. on
> >>>>>> their
> >>>>>> side.
> >>>>>>
> >>>>>
> >>>>> And more HDD space and more own bandwith - which is also not what
> they
> >>>>> want.
> >>>>>
> >>>>> Marcus
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
-------------------------------------------------------------------------------------------------
MzK
"Cats do not have to be shown how to have a good time,
for they are unfailing ingenious in that respect."
-- James Mason
Re: Anything we can do about premature redistribution?
Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 31, 2014 at 4:43 PM, Marcus (OOo) <ma...@wtnet.de> wrote:
> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
>
>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<ma...@wtnet.de>:
>>
>>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
>>>
>>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
>>>>
>>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>>
>>>>>> Rob Weir wrote:
>>>>>>
>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>>>
>>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Andrew's comments show clearly that these editors do not care to be
>>>>>> careful or factual, or even read those disclaimers, unfortunately.
>>>>>>
>>>>>> We can be successful only if we manage to block their downloads. They
>>>>>> link to our binaries hosted on SourceForge (which is fine). Just
>>>>>> thinking loud, but if it was possible (on the Sourceforge side) to
>>>>>> deny
>>>>>> all download requests that do not come from the openoffice.org or the
>>>>>> sourceforge.net domains, then the project would effectively be in
>>>>>> control. The embargo could be lifted just after the release.
>>>>>>
>>>>>
>>>>> For me this sounds like a great idea.
>>>>>
>>>>> Maybe we should start with denying all download requests that some from
>>>>> these bad websites.
>>>>>
>>>>> @Roberto:
>>>>> Can you tell us if this possible? If yes, is it much effort for you?
>>>>>
>>>>
>>>> Do you see a chance to get this implemented? I think it could help to
>>>> stop some bad websites to do bad things with our software.
>>>>
>>>
>>> @Roberto:
>>> Maybe you haven't seen this up to now.
>>>
>>
>> Thanks for heads up Marcus, sorry for not having noticed this thread
>> before.
>>
>>
>>
>>>
>>> It would be great if you can tell us if it's possible to exclude some
>>> domains / IP addresses from downloading our software?
>>>
>>
>> I need the domain list and I'll check out with our SiteOps if that's
>> doable. Feel free to send me a list with a direct message.
>
>
> - chip.de
> - computerbase.de
> - softpedia.com
>
> This would be the domains from this thread that could be blocked from
> downloading from Sourceforge. Obviously needs to be extended in the future.
> Remember, the next will happen with the AOO 4.1.0 RC. ;-)
>
> *Of course*, this is just for the time frame as long as the new version is
> not officially announced. As soon as the release is public, the block will
> be removed.
>
> @all:
> I think this could help to limit the downloadability like we want to see
> until the official release. What you think?
>
I don't know. Won't this just cause confusion? They point to the
files, go to test them, see the links don't work, and then get weird
errors and spend an hour trying to debug it. We don't want to
needlessly annoy them, since their only fault is enthusiasm. Is
there a way we can give a useful error message in this case like,
"This version of Apache OpenOffice has not yet been officially
released. Links to these files are disallowed until the release is
officially approved" or something like that?
-Rob
> Marcus
>
>
>
>
>>> Then we can exclude requester that we don't want (e.g., malware
>>> "distributors").
>>>
>>> Also in time frames with Beta or RC releases it can help us to steer who
>>> is able and when it is possible to download OpenOffice like we want to
>>> see
>>> until the real release date is reached.
>>
>>
>>
>>> Thanks
>>>
>>> Marcus
>>>
>>>
>>>
>>> Sure, sites could still copy all binaries being voted upon and offer
>>>>>>
>>>>>> them locally, but this would require a more significant effort. on
>>>>>> their
>>>>>> side.
>>>>>>
>>>>>
>>>>> And more HDD space and more own bandwith - which is also not what they
>>>>> want.
>>>>>
>>>>> Marcus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini:
> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<ma...@wtnet.de>:
>
>> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
>>
>>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
>>>
>>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>>
>>>>> Rob Weir wrote:
>>>>>
>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>>
>>>>>
>>>>> Andrew's comments show clearly that these editors do not care to be
>>>>> careful or factual, or even read those disclaimers, unfortunately.
>>>>>
>>>>> We can be successful only if we manage to block their downloads. They
>>>>> link to our binaries hosted on SourceForge (which is fine). Just
>>>>> thinking loud, but if it was possible (on the Sourceforge side) to deny
>>>>> all download requests that do not come from the openoffice.org or the
>>>>> sourceforge.net domains, then the project would effectively be in
>>>>> control. The embargo could be lifted just after the release.
>>>>>
>>>>
>>>> For me this sounds like a great idea.
>>>>
>>>> Maybe we should start with denying all download requests that some from
>>>> these bad websites.
>>>>
>>>> @Roberto:
>>>> Can you tell us if this possible? If yes, is it much effort for you?
>>>>
>>>
>>> Do you see a chance to get this implemented? I think it could help to
>>> stop some bad websites to do bad things with our software.
>>>
>>
>> @Roberto:
>> Maybe you haven't seen this up to now.
>>
>
> Thanks for heads up Marcus, sorry for not having noticed this thread before.
>
>
>
>>
>> It would be great if you can tell us if it's possible to exclude some
>> domains / IP addresses from downloading our software?
>>
>
> I need the domain list and I'll check out with our SiteOps if that's
> doable. Feel free to send me a list with a direct message.
- chip.de
- computerbase.de
- softpedia.com
This would be the domains from this thread that could be blocked from
downloading from Sourceforge. Obviously needs to be extended in the
future. Remember, the next will happen with the AOO 4.1.0 RC. ;-)
*Of course*, this is just for the time frame as long as the new version
is not officially announced. As soon as the release is public, the block
will be removed.
@all:
I think this could help to limit the downloadability like we want to see
until the official release. What you think?
Marcus
>> Then we can exclude requester that we don't want (e.g., malware
>> "distributors").
>>
>> Also in time frames with Beta or RC releases it can help us to steer who
>> is able and when it is possible to download OpenOffice like we want to see
>> until the real release date is reached.
>
>
>> Thanks
>>
>> Marcus
>>
>>
>>
>> Sure, sites could still copy all binaries being voted upon and offer
>>>>> them locally, but this would require a more significant effort. on their
>>>>> side.
>>>>>
>>>>
>>>> And more HDD space and more own bandwith - which is also not what they
>>>> want.
>>>>
>>>> Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Roberto Galoppini <ro...@gmail.com>.
2014-03-28 21:24 GMT+01:00 Marcus (OOo) <ma...@wtnet.de>:
> Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
>
>> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
>>
>>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>>
>>>> Rob Weir wrote:
>>>>
>>>>> http://linux.softpedia.com/get/Office/Office-Suites/
>>>>>>>> Apache-OpenOffice-253.shtml
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Or maybe a disclaimer in the voting thread email?
>>>>>
>>>>
>>>> Andrew's comments show clearly that these editors do not care to be
>>>> careful or factual, or even read those disclaimers, unfortunately.
>>>>
>>>> We can be successful only if we manage to block their downloads. They
>>>> link to our binaries hosted on SourceForge (which is fine). Just
>>>> thinking loud, but if it was possible (on the Sourceforge side) to deny
>>>> all download requests that do not come from the openoffice.org or the
>>>> sourceforge.net domains, then the project would effectively be in
>>>> control. The embargo could be lifted just after the release.
>>>>
>>>
>>> For me this sounds like a great idea.
>>>
>>> Maybe we should start with denying all download requests that some from
>>> these bad websites.
>>>
>>> @Roberto:
>>> Can you tell us if this possible? If yes, is it much effort for you?
>>>
>>
>> Do you see a chance to get this implemented? I think it could help to
>> stop some bad websites to do bad things with our software.
>>
>
> @Roberto:
> Maybe you haven't seen this up to now.
>
Thanks for heads up Marcus, sorry for not having noticed this thread before.
>
> It would be great if you can tell us if it's possible to exclude some
> domains / IP addresses from downloading our software?
>
I need the domain list and I'll check out with our SiteOps if that's
doable. Feel free to send me a list with a direct message.
Roberto
>
> Then we can exclude requester that we don't want (e.g., malware
> "distributors").
>
> Also in time frames with Beta or RC releases it can help us to steer who
> is able and when it is possible to download OpenOffice like we want to see
> until the real release date is reached.
> Thanks
>
> Marcus
>
>
>
> Sure, sites could still copy all binaries being voted upon and offer
>>>> them locally, but this would require a more significant effort. on their
>>>> side.
>>>>
>>>
>>> And more HDD space and more own bandwith - which is also not what they
>>> want.
>>>
>>> Marcus
>>>
>>
Re: Anything we can do about premature redistribution?
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 03/13/2014 10:01 PM, schrieb Marcus (OOo):
> Am 03/09/2014 06:08 PM, schrieb Marcus (OOo):
>> Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
>>> Rob Weir wrote:
>>>>>>> http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml
>>>>>>>
>>>>>>>
>>>>>>>
>>>> Or maybe a disclaimer in the voting thread email?
>>>
>>> Andrew's comments show clearly that these editors do not care to be
>>> careful or factual, or even read those disclaimers, unfortunately.
>>>
>>> We can be successful only if we manage to block their downloads. They
>>> link to our binaries hosted on SourceForge (which is fine). Just
>>> thinking loud, but if it was possible (on the Sourceforge side) to deny
>>> all download requests that do not come from the openoffice.org or the
>>> sourceforge.net domains, then the project would effectively be in
>>> control. The embargo could be lifted just after the release.
>>
>> For me this sounds like a great idea.
>>
>> Maybe we should start with denying all download requests that some from
>> these bad websites.
>>
>> @Roberto:
>> Can you tell us if this possible? If yes, is it much effort for you?
>
> Do you see a chance to get this implemented? I think it could help to
> stop some bad websites to do bad things with our software.
@Roberto:
Maybe you haven't seen this up to now.
It would be great if you can tell us if it's possible to exclude some
domains / IP addresses from downloading our software?
Then we can exclude requester that we don't want (e.g., malware
"distributors").
Also in time frames with Beta or RC releases it can help us to steer who
is able and when it is possible to download OpenOffice like we want to
see until the real release date is reached.
Thanks
Marcus
>>> Sure, sites could still copy all binaries being voted upon and offer
>>> them locally, but this would require a more significant effort. on their
>>> side.
>>
>> And more HDD space and more own bandwith - which is also not what they
>> want.
>>
>> Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti:
> Rob Weir wrote:
>>>>> http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml
>>>>>
>> Or maybe a disclaimer in the voting thread email?
>
> Andrew's comments show clearly that these editors do not care to be
> careful or factual, or even read those disclaimers, unfortunately.
>
> We can be successful only if we manage to block their downloads. They
> link to our binaries hosted on SourceForge (which is fine). Just
> thinking loud, but if it was possible (on the Sourceforge side) to deny
> all download requests that do not come from the openoffice.org or the
> sourceforge.net domains, then the project would effectively be in
> control. The embargo could be lifted just after the release.
For me this sounds like a great idea.
Maybe we should start with denying all download requests that some from
these bad websites.
@Roberto:
Can you tell us if this possible? If yes, is it much effort for you?
> Sure, sites could still copy all binaries being voted upon and offer
> them locally, but this would require a more significant effort. on their
> side.
And more HDD space and more own bandwith - which is also not what they want.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Andrea Pescetti <pe...@apache.org>.
Rob Weir wrote:
>>>> http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml
> Or maybe a disclaimer in the voting thread email?
Andrew's comments show clearly that these editors do not care to be
careful or factual, or even read those disclaimers, unfortunately.
We can be successful only if we manage to block their downloads. They
link to our binaries hosted on SourceForge (which is fine). Just
thinking loud, but if it was possible (on the Sourceforge side) to deny
all download requests that do not come from the openoffice.org or the
sourceforge.net domains, then the project would effectively be in
control. The embargo could be lifted just after the release.
Sure, sites could still copy all binaries being voted upon and offer
them locally, but this would require a more significant effort. on their
side.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Chuck Davis <cj...@gmail.com>.
A water-mark on new documents that directs people to find "official"
distributions on the web site? The water-mark will be taken off when AOO
is out of beta and an official release is available. At the least this
would require those who want to just redistribute know enough programming
to make it inconvenient for them.
On Fri, Mar 7, 2014 at 7:37 AM, Jürgen Schmidt <jo...@gmail.com>wrote:
> On 3/7/14 4:33 PM, Rob Weir wrote:
> > On Fri, Mar 7, 2014 at 10:23 AM, Jürgen Schmidt <jo...@gmail.com>
> wrote:
> >> On 3/7/14 4:21 PM, Oliver-Rainer Wittmann wrote:
> >>> Hi,
> >>>
> >>> On 07.03.2014 15:22, Rob Weir wrote:
> >>>> Evidently we're already released, on some websites at least:
> >>>>
> >>>>
> http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml
> >>>>
> >>>>
> >>>> How much do we care about this? The risk, I suppose, is on
> >>>> Softpedia, that we could find a last-minute defect in the NOTICE or
> >>>> other legal files, and they find themselves distributing a package
> >>>> that is not correct. But the practical risk there is small.
> >>>>
> >>>> The greater risk is to users, that we find a last-minute fatal bug
> >>>> that causes us to cancel the vote, but there are versions of the
> >>>> Release Candidate still floating around. That can hurt the AOO
> >>>> reputation if that happened.
> >>>>
> >>>> I'm not sure we can prevent this from happening, and still have an
> >>>> open and transparent voting process. But maybe there is something we
> >>>> can do to discourage it?
> >>>>
> >>>
> >>>
> >>> softpedia is not the only one:
> >>> - http://www.chip.de/downloads/OpenOffice_14324674.html
> >>> - http://www.computerbase.de/downloads/office/
> >>>
> >>
> >> I think we can create a blog explaining the voting procedure and make
> >> clear where we are in the process and that it is the RC of the Beta
> only.
> >>
> >
> > Or maybe a disclaimer in the voting thread email? Next time we could
> > say something like:
> >
> > "Note: All Apache releases require a vote of the PMC lasting at
> > least 72-hours. We do not officially release until after that vote
> > has concluded. We appreciate the enthusiasm of our users and 3rd
> > party distributors and their efforts to publicize our releases and
> > share them with a broader audience. But we ask that you do not
> > publicize a release until the vote has concluded and the vote results
> > posted. This is for the safety of the users. It is always possible
> > for a last minute defect to be reported in a Release Candidate causing
> > us to cancel an in-progress vote. in fact this has occurred before.
> > So be safe and wait for the release process to conclude."
> >
> > I'm guessing that they hear about the RC from the email list, not the
> > wiki, so it might make sense to put a message like this in the vote
> > email.
> >
>
> +1, already marked and I will add it the next time. But for this time we
> can put this text in a blog. Opinions?
>
> Juergen
>
>
> > -Rob
> >
> >
> >> But I don't know if this would really help to avoid confusion.
> >>
> >> Juergen
> >>
> >>
> >>>
> >>> Best regards, Oliver.
> >>>
> >>>> -Rob
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >>> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Anything we can do about premature redistribution?
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 3/7/14 4:33 PM, Rob Weir wrote:
> On Fri, Mar 7, 2014 at 10:23 AM, Jürgen Schmidt <jo...@gmail.com> wrote:
>> On 3/7/14 4:21 PM, Oliver-Rainer Wittmann wrote:
>>> Hi,
>>>
>>> On 07.03.2014 15:22, Rob Weir wrote:
>>>> Evidently we're already released, on some websites at least:
>>>>
>>>> http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml
>>>>
>>>>
>>>> How much do we care about this? The risk, I suppose, is on
>>>> Softpedia, that we could find a last-minute defect in the NOTICE or
>>>> other legal files, and they find themselves distributing a package
>>>> that is not correct. But the practical risk there is small.
>>>>
>>>> The greater risk is to users, that we find a last-minute fatal bug
>>>> that causes us to cancel the vote, but there are versions of the
>>>> Release Candidate still floating around. That can hurt the AOO
>>>> reputation if that happened.
>>>>
>>>> I'm not sure we can prevent this from happening, and still have an
>>>> open and transparent voting process. But maybe there is something we
>>>> can do to discourage it?
>>>>
>>>
>>>
>>> softpedia is not the only one:
>>> - http://www.chip.de/downloads/OpenOffice_14324674.html
>>> - http://www.computerbase.de/downloads/office/
>>>
>>
>> I think we can create a blog explaining the voting procedure and make
>> clear where we are in the process and that it is the RC of the Beta only.
>>
>
> Or maybe a disclaimer in the voting thread email? Next time we could
> say something like:
>
> "Note: All Apache releases require a vote of the PMC lasting at
> least 72-hours. We do not officially release until after that vote
> has concluded. We appreciate the enthusiasm of our users and 3rd
> party distributors and their efforts to publicize our releases and
> share them with a broader audience. But we ask that you do not
> publicize a release until the vote has concluded and the vote results
> posted. This is for the safety of the users. It is always possible
> for a last minute defect to be reported in a Release Candidate causing
> us to cancel an in-progress vote. in fact this has occurred before.
> So be safe and wait for the release process to conclude."
>
> I'm guessing that they hear about the RC from the email list, not the
> wiki, so it might make sense to put a message like this in the vote
> email.
>
+1, already marked and I will add it the next time. But for this time we
can put this text in a blog. Opinions?
Juergen
> -Rob
>
>
>> But I don't know if this would really help to avoid confusion.
>>
>> Juergen
>>
>>
>>>
>>> Best regards, Oliver.
>>>
>>>> -Rob
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Rob Weir <ro...@apache.org>.
On Fri, Mar 7, 2014 at 10:23 AM, Jürgen Schmidt <jo...@gmail.com> wrote:
> On 3/7/14 4:21 PM, Oliver-Rainer Wittmann wrote:
>> Hi,
>>
>> On 07.03.2014 15:22, Rob Weir wrote:
>>> Evidently we're already released, on some websites at least:
>>>
>>> http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml
>>>
>>>
>>> How much do we care about this? The risk, I suppose, is on
>>> Softpedia, that we could find a last-minute defect in the NOTICE or
>>> other legal files, and they find themselves distributing a package
>>> that is not correct. But the practical risk there is small.
>>>
>>> The greater risk is to users, that we find a last-minute fatal bug
>>> that causes us to cancel the vote, but there are versions of the
>>> Release Candidate still floating around. That can hurt the AOO
>>> reputation if that happened.
>>>
>>> I'm not sure we can prevent this from happening, and still have an
>>> open and transparent voting process. But maybe there is something we
>>> can do to discourage it?
>>>
>>
>>
>> softpedia is not the only one:
>> - http://www.chip.de/downloads/OpenOffice_14324674.html
>> - http://www.computerbase.de/downloads/office/
>>
>
> I think we can create a blog explaining the voting procedure and make
> clear where we are in the process and that it is the RC of the Beta only.
>
Or maybe a disclaimer in the voting thread email? Next time we could
say something like:
"Note: All Apache releases require a vote of the PMC lasting at
least 72-hours. We do not officially release until after that vote
has concluded. We appreciate the enthusiasm of our users and 3rd
party distributors and their efforts to publicize our releases and
share them with a broader audience. But we ask that you do not
publicize a release until the vote has concluded and the vote results
posted. This is for the safety of the users. It is always possible
for a last minute defect to be reported in a Release Candidate causing
us to cancel an in-progress vote. in fact this has occurred before.
So be safe and wait for the release process to conclude."
I'm guessing that they hear about the RC from the email list, not the
wiki, so it might make sense to put a message like this in the vote
email.
-Rob
> But I don't know if this would really help to avoid confusion.
>
> Juergen
>
>
>>
>> Best regards, Oliver.
>>
>>> -Rob
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 3/7/14 4:21 PM, Oliver-Rainer Wittmann wrote:
> Hi,
>
> On 07.03.2014 15:22, Rob Weir wrote:
>> Evidently we're already released, on some websites at least:
>>
>> http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml
>>
>>
>> How much do we care about this? The risk, I suppose, is on
>> Softpedia, that we could find a last-minute defect in the NOTICE or
>> other legal files, and they find themselves distributing a package
>> that is not correct. But the practical risk there is small.
>>
>> The greater risk is to users, that we find a last-minute fatal bug
>> that causes us to cancel the vote, but there are versions of the
>> Release Candidate still floating around. That can hurt the AOO
>> reputation if that happened.
>>
>> I'm not sure we can prevent this from happening, and still have an
>> open and transparent voting process. But maybe there is something we
>> can do to discourage it?
>>
>
>
> softpedia is not the only one:
> - http://www.chip.de/downloads/OpenOffice_14324674.html
> - http://www.computerbase.de/downloads/office/
>
I think we can create a blog explaining the voting procedure and make
clear where we are in the process and that it is the RC of the Beta only.
But I don't know if this would really help to avoid confusion.
Juergen
>
> Best regards, Oliver.
>
>> -Rob
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 07.03.2014 15:22, Rob Weir wrote:
> Evidently we're already released, on some websites at least:
>
> http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml
>
> How much do we care about this? The risk, I suppose, is on
> Softpedia, that we could find a last-minute defect in the NOTICE or
> other legal files, and they find themselves distributing a package
> that is not correct. But the practical risk there is small.
>
> The greater risk is to users, that we find a last-minute fatal bug
> that causes us to cancel the vote, but there are versions of the
> Release Candidate still floating around. That can hurt the AOO
> reputation if that happened.
>
> I'm not sure we can prevent this from happening, and still have an
> open and transparent voting process. But maybe there is something we
> can do to discourage it?
>
softpedia is not the only one:
- http://www.chip.de/downloads/OpenOffice_14324674.html
- http://www.computerbase.de/downloads/office/
Best regards, Oliver.
> -Rob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by David Gerard <dg...@gmail.com>.
On 7 March 2014 22:30, Andrew Rist <an...@oracle.com> wrote:
> "It is derived from the IBM Lotus Symphony suite of applications..."
> - not correct
https://blogs.apache.org/OOo/entry/merging_lotus_symphony_allegro_moderato
suggests this is not an unfair statement. Indeed, just rebasing on the
Symphony code was seriously considered.
> "Ever since the Oracle Corporation acquired the Sun Microsystems
> company, work on Apache OpenOffice ceased, and various developers
> who worked on the project decided to create a new project, named
> LibreOffice." - neither correct nor pertinent
That's ridiculously wrong, to the point of warranting formal messages
of correction from both projects.
In general, I would suggest asking nicely as the very first approach,
when the beta is in fact approved and ready.
- d.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Anything we can do about premature redistribution?
Posted by Andrew Rist <an...@oracle.com>.
On 3/7/2014 6:22 AM, Rob Weir wrote:
> Evidently we're already released, on some websites at least:
>
> http://linux.softpedia.com/get/Office/Office-Suites/Apache-OpenOffice-253.shtml
Also, what of the "Editor's review"?
"It is derived from the IBM Lotus Symphony suite of applications..."
- not correct
"Under the hood, Apache OpenOffice is translated in over 170
languages..." - not correct
"It is also very important to mention here that the well known
LibreOffice open source office suite is based on the source code of
this application." - hmmm - correct, but, not the traditional LO
formulation
"Ever since the Oracle Corporation acquired the Sun Microsystems
company, work on Apache OpenOffice ceased, and various developers
who worked on the project decided to create a new project, named
LibreOffice." - neither correct nor pertinent
"Because of this, LibreOffice is now the main choice for any Linux
distribution developer who wants to pre-install a complete and open
source office suite application in their operating system(s)."
>
> How much do we care about this? The risk, I suppose, is on
> Softpedia, that we could find a last-minute defect in the NOTICE or
> other legal files, and they find themselves distributing a package
> that is not correct. But the practical risk there is small.
>
> The greater risk is to users, that we find a last-minute fatal bug
> that causes us to cancel the vote, but there are versions of the
> Release Candidate still floating around. That can hurt the AOO
> reputation if that happened.
>
> I'm not sure we can prevent this from happening, and still have an
> open and transparent voting process. But maybe there is something we
> can do to discourage it?
>
> -Rob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
--
Andrew Rist | Interoperability Architect
OracleCorporate Architecture Group
Redwood Shores, CA | 650.506.9847