openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus (OOo)" <marcus.m...@wtnet.de>
Subject Re: Anything we can do about premature redistribution?
Date Thu, 03 Apr 2014 19:30:10 GMT
Am 04/03/2014 02:27 PM, schrieb Roberto Galoppini:
> 2014-04-03 13:09 GMT+02:00 Rob Weir<robweir@apache.org>:
>
>> On Wed, Apr 2, 2014 at 5:19 PM, Marcus (OOo)<marcus.mail@wtnet.de>  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. ;-)
>>
>
> 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


Mime
View raw message