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:44:49 GMT
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.

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