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 10:09:17 GMT
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.

 Let me know if you need assistance or help.

 Roberto



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