On Tue, Dec 4, 2012 at 5:44 PM, Rob Weir <robw...@apache.org> wrote: > On Tue, Dec 4, 2012 at 4:31 PM, Ariel Constenla-Haile > <arie...@apache.org> wrote: >> On Tue, Dec 04, 2012 at 03:00:13PM -0500, Rob Weir wrote: >>> >> If we want something to be downloaded and used by the public then we >>> >> should release it, period. We should not be looking for clever ways >>> >> to avoid the important release steps of verifying IP, producing a >>> >> source package and voting on it. >>> > >>> > It seems you are mixing things, as I only proposed to build all language >>> > packages, while following the same release criteria as before (release >>> > only languages with 100% UI and a localization team backing it). Where >>> > do you see a clever way to avoid official procedures in this? >>> > >>> >>> When you suggested that we point users to these un-released binaries. >> >> Well, this meant only: If a user sends a mail telling that AOO does not >> work on his RHEL 5 system, I find it good to point her/him to the >> packages I've made, this will solve her/his problem. So if I read the >> mail, I will point her/him to my packages. The same would apply in this >> case with the language packs (which I already plan to do for the >> linux-glib-2.5 build). >> >> I didn't mean to "officially" point the users (whatever that could >> mean). >> > > I think your little project is less of a practical concern. It > probably doesn't use much bandwidth. The much larger danger is that > we mention a new translation on the public website, and that gets > mentioned on a popular website, or social media, or a magazine and all > of a sudden we get massive download requests going to > people.apache.org. Do you really want to see Infra get upset? > Remember, the ASF has limited bandwidth. > > We cannot control this or prevent it from happening. It is out of our > control once we mention something on the pubic website. So we need to > act responsibly. And that means (IMHO) that if we're producing a test > build for QA and NL people to test with, that we publicize only as > much as needed for them to know that it exists. That means the > mailing lists. We need to be aware of how big the AOO project is, in > comparison to the rest of the ASF, and take such precautions if we > want to stay welcome here. >
And btw, just so you can see that I'm not just making stuff up, please note the ASF Releases Policy page: "What Is A Release? Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list. If the general public is being instructed to download a package, then that package has been released. Each PMC must obey the ASF requirements on approving any release. How you label the package is a secondary issue, described below. During the process of developing software and preparing a release, various packages are made available to the developer community for testing purposes. Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package. The only people who are supposed to know about such packages are the people following the dev list (or searching its archives) and thus aware of the conditions placed on the package. If you find that the general public are downloading such test packages, then remove them. Under no circumstances are unapproved builds a substitute for releases. If this policy seems inconvenient, then release more often. Proper release management is a key aspect of Apache software development. The Apache Software Foundation produces open source software. All releases are in the form of the source materials needed to make changes to the software being released. In some cases, binary/bytecode packages are also produced as a convenience to users that might not have the appropriate tools to build a compiled version of the source. In all such cases, the binary/bytecode package must have the same version number as the source release and may only add binary/bytecode files that are the result of compiling that version of the source code release." http://www.apache.org/dev/release.html Hopefully that is clearer than my unsuccessfully attempts at explaining this. Regards, -Rob >>> > In the end, it's just the same as I've done with the linux glib-2.5 >>> > build, which is advertised in the portings page, and stored at >>> > people.apache.org... I haven't heard any complaints about this, so far >>> > only some people thankful >>> > https://issues.apache.org/ooo/show_bug.cgi?id=119385#c13 >>> > >>> >>> Perhaps we should start looking at such pseudo releases more carefully? >> >> I don't see the point, these are not (pseudo) releases, they are simply >> community contributed packages, that might be useful for some users. The >> same aipplies to adfinis solaris builds, and any other "unofficially" >> community contributed stuff. >> > > But these are not on people.apache.org, are they? > > -Rob > >> >> Regards >> -- >> Ariel Constenla-Haile >> La Plata, Argentina
