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 Fri, 04 Apr 2014 18:57:28 GMT
Am 04/03/2014 11:12 PM, schrieb Roberto Galoppini:
> 2014-04-03 21:44 GMT+02:00 Marcus (OOo)<marcus.mail@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<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.
>>>
>>
>> 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


Mime
View raw message