2014-04-03 21:44 GMT+02:00 Marcus (OOo) <marcus.m...@wtnet.de>: > Am 04/03/2014 12:57 PM, schrieb Jürgen Schmidt: > > 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. >> > > When looking at the screenshots in the blog post, the "3" could be > exchanged with a inputfield or dropdown list to enter/choose an own value. > The "3 days" could be the default 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. >> > > Maybe it's possible to extend the 3 days to, hm, more days for now and > have the customize feature in the future.
It's actually pre-set to 21 days, click on the 'i' and you'll read This file is staged until Thu, 24 Apr 2014 13:04:32 GMT . Again, if that's not enough I'll make sure to extend it further. 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 > >
