On Mon, Mar 17, 2014 at 3:52 AM, Andrea Pescetti <pesce...@apache.org> wrote: > Dave Fisher wrote: >> >> No links to snapshots from the website. It is ASF policy. > > > It is not ASF policy. It is the way we have interpreted it so far. > > Policy is here http://www.apache.org/dev/release.html#what but as already > discussed with the Board the key is that visitors pass through a page that > makes it clear the dev builds are for our developers (meaning "anyone > contributing toward the development of our product"). So the policy issue > seems mostly solved to me. Feel free to ask me in private for discussion > links. >
The problem is we cannot control what 3rd parties do. They can easily deep-link to our dev build page directly, bypassing any "warning" page that they might have. Of course, they could do that today, to ci.apache.org, if they knew about it. When 3rd parties promote unofficial builds, we can run into the following problems: 1) Users get a lower-quality product and this hurts our brand reputation 2) The developer builds may not meet all ASF release requirements, e.g, checks on NOTICE and LICENSE files, so errors in this area can hurt the ASF's brand reputation. 3) We do not offer upgrade notifications for developer builds. So users can become "stuck" on an unmaintained product and be susceptible to security issues, etc. This harms the user and our reputation. So we have a strong incentive to ensure that developer releases are not widely available to the public. I'm not sure what problem we're solving that would recommend putting a link (direct or indirect) to developer releases on our main download page, which gets *a million visits per week*. We should be very careful about that. Was there something that did not work with sharing the ci.apache.org address on the dev and qa lists? Other solutions: 1) Share the developer build link on the QA page, not the public download page that gets 1 million visits per week. If the goal is to have only project members download, then put it on a page that only project members read ;-) 2) Add some authentication on the actual developer build download page. Ideally, tie it having a BZ account. 3) Put a date-based expiration into developer builds, to discourage long-term use. Regards, -Rob > > Regards, > Andrea. > > --------------------------------------------------------------------- > 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
