2014-04-03 21:30 GMT+02:00 Marcus (OOo) <marcus.m...@wtnet.de>: > Am 04/03/2014 02:27 PM, schrieb Roberto Galoppini: > > 2014-04-03 13:09 GMT+02:00 Rob Weir<robw...@apache.org>: >> >> On Wed, Apr 2, 2014 at 5:19 PM, Marcus (OOo)<marcus.m...@wtnet.de> >>> 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. >>>> ;-) >>>> >>> >>> >> It's still set to 21 days maximum. We can of course extend that if needed. >> I'll take care of that. >> >> >> >>>> >>>> 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? >>>> >>>> >>> My original recommendation was to put a more prominent warning in the >>> [VOTE] emails. The problem is this: if we are to have a public vote >>> then the files we're voting on must also be public. Whether this is >>> on SourceForge or people.apache.org, it is publicly known that this is >>> the 4.1 RC and some websites will download and copy onto their >>> websites. I don't think there is any technological means to prevent >>> this. We only have our ability to educate about the risks. >>> >>> >> Yea, actually as per my previous email we can just mitigate the issue for >> those who point to us to serve downloads, anyone else can actually >> download >> it - either from their domain or other IP - and then serve it through >> their >> services. >> > > IMHO we can skip this when using a staged folder. Then they don't see > anything and cannot download finally. > > > If it's not much of a trouble what about having a different splash-screen, >> with a big sign "Attention" explaining that's just a release candidate and >> it's not the final product and we recommend to visit always OpenOffice.org >> to get the latest available release? >> > > That's of course a very good idea for Beta releases or any other pre-final > release. However, it will not help for RCs as we declare these builds as > final when we don't get (severe) complaints. This means RC and final > version are technically the same bits and bytes. So, here we should avoid > any temporary splash screens.
Technically you're 100% right, my thought was that probably those guys distributing AOO RC as final don't want to look clumsy and inexperienced and they would probably avoid to distribute a version that is marked as not good (yet) for the general public. Anyway, I understand the annoyance of putting/removing such a screen-shot. 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-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
