On 4/3/14 12:09 PM, Roberto Galoppini wrote: > 2014-04-03 8:52 GMT+02:00 Jürgen Schmidt <jogischm...@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.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? >> > > 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. 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. Juergen > > 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-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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
