Am 11/10/2012 01:17 AM, schrieb Dave Fisher:
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.
Sure, however it would fit for the SF mirrors. The en-US full install
and some langpacks. Let's say 2 GB for 2 revisions.
SourceForge and apache extras differ. BUT we need to be very careful that
> there is no confusion with releases as Rob wrote.
Don't panic. It was just an idea. ;-)
Marcus
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
