openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J├╝rgen Schmidt <jogischm...@gmail.com>
Subject Re: Anything we can do about premature redistribution?
Date Thu, 03 Apr 2014 06:52:44 GMT
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)<marcus.mail@wtnet.de>:
>>
>>> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini:
>>>
>>>   2014-04-01 21:30 GMT+02:00 Marcus (OOo)<marcus.mail@wtnet.de>:
>>>>
>>>>   Am 03/31/2014 11:56 PM, schrieb Kay Schenk:
>>>>>
>>>>>    On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<robweir@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. ;-)
> 
>> 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


Mime
View raw message