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. 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? > > -Rob > > > > > > 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 > >
