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 10:57:57 GMT
On 4/3/14 12:09 PM, Roberto Galoppini wrote:
> 2014-04-03 8:52 GMT+02:00 Jürgen Schmidt <jogischmidt@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)<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?
>>
> 
> 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


Mime
View raw message