openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roberto Galoppini <roberto.galopp...@gmail.com>
Subject Re: Anything we can do about premature redistribution?
Date Thu, 03 Apr 2014 19:36:14 GMT
2014-04-03 21:30 GMT+02:00 Marcus (OOo) <marcus.mail@wtnet.de>:

> 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.


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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message