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 21:12:16 GMT
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.

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