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.m...@wtnet.de>: >> >>> Am 04/02/2014 06:20 PM, schrieb Roberto Galoppini: >>> >>> 2014-04-01 21:30 GMT+02:00 Marcus (OOo)<marcus.m...@wtnet.de>: >>>> >>>> Am 03/31/2014 11:56 PM, schrieb Kay Schenk: >>>>> >>>>> On Mon, Mar 31, 2014 at 1:48 PM, Rob Weir<robw...@apache.org> >>>>> wrote: >>>>> >>>>>> >>>>>> On Mon, Mar 31, 2014 at 4:43 PM, Marcus >>>>>> (OOo)<marcus.m...@wtnet.de> >>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> Am 03/29/2014 09:36 PM, schrieb Roberto Galoppini: >>>>>>>> >>>>>>>> 2014-03-28 21:24 GMT+01:00 Marcus (OOo)<marcus.m...@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? 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-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
