Sent from my iPhone
On Nov 9, 2012, at 5:04 PM, "Marcus (OOo)" <marcus.m...@wtnet.de> wrote: > Am 11/09/2012 10:50 PM, schrieb Rob Weir: >> On Fri, Nov 9, 2012 at 4:30 PM, jan iversen<jancasacon...@gmail.com> wrote: >>> Hi. >>> >>> In order to make life easier (more stable) for translators, I think it >>> would be a good idea to "isolate" developer builds on dev. When we have >>> langauge packs integrated, then we could point to them from l10n, with a >>> thick note, stating they are only there for testing the language. >>> >>> In order to make sure they dont get distributed "as released", would it be >>> an idea (and is it possible) to e.g. disable the actual "save" (not the >>> button, but the final write call). With such a feature anybody can test >>> (which is the purpose) but it cannot be used as a product. >>> >> >> So we're all on the same page, this is how I understand the two main >> constraints on how we treat pre-release builds: >> >> 1) Constraint one is policy. We distribute releases to the public, >> after they've been vetted and approved by the PMC. We need to avoid >> shortcuts that cause software to be distributed to the public outside >> of this approval process. >> >> 2) Constraint two is bandwidth. We don't have infinite bandwidth. >> That is why we rely on download mirrors for distributing releases and, >> in the special case of OpenOffice, SourceForge as well. We need to >> be careful about bandwidth used by posting developer builds on >> people.apache.org. > > IMHO it shouldn't be a problem to put the dev builds also onto the mirrors. Which mirrors? Apache Mirrors are for most recent releases only on active branches and also for all Apache projects. Mirror operators have limited space. SourceForge and apache extras differ. BUT we need to be very careful that there is no confusion with releases as Rob wrote. R > The additionally need space it low and more than 2 revisions shouldn't be > there. However, the upload is an additionally effort. ;-) > >> The nightmare scenario is we post a developer build of a popular new >> translation, say Korean, and even though it was not intended to be a >> public release, someone gets the URL to the people.apache.org install >> sets and posts it on a Korean forum or website, and we start getting >> millions of downloads from people.apache.org. This would be bad for >> Infra, but also bad for us, since our users would probably not have a >> good experience with pre-release software. > > This can happen also today. It doesn't depend on where the download link is > located. Just who has found it and where it gets populated. > >> So we really need to keep the dev builds "low key", and not make it >> very easy for the public to accidentally stumble upon them. > > OK, understood. > > Marcus > > > >>> On 9 November 2012 22:05, Rob Weir<robw...@apache.org> wrote: >>> >>>> On Fri, Nov 9, 2012 at 3:55 PM, Marcus (OOo)<marcus.m...@wtnet.de> wrote: >>>>> Hi all, >>>>> >>>>> a quick question as I don't know the status of this request: >>>>> >>>>> Do we (still) want to have download links for Dev Builds that refer to >>>> the >>>>> respective people's dir? >>>>> >>>> >>>> IMHO we don't want pages in www.openoffice.org/dowload/* to point to >>>> anything other than actual releases. Links from Dev, L10n or QA >>>> pages are fine. >>>> >>>>> Then I would create a webpage that can be included in the usual download >>>>> website - as it was in the former times with OOo. >>>>> >>>>> At the moment there is just a link to the Wiki page. >>>>> >>>>> Marcus
