On Tue, Mar 18, 2014 at 4:21 PM, Andrea Pescetti <pesce...@apache.org>wrote:
> Rob Weir wrote: > >> On Mon, Mar 17, 2014 at 3:52 AM, Andrea Pescetti 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. >>> >> > I'm moving this to an own thread as per Juergen's request (but this IS > release-relevant: I'd like to have more visibility for dev builds in the > weeks leading to 4.1). And I'm leave the snippet above just to say that > "Policy forbids this" is not a killer argument in this case. If the Apache > policy gets in the way, we are probably applying it too conservatively, and > I heave elements to believe this is the case. > > 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. >> > > Indeed, you already guessed the answer yourself: there's nothing > preventing people to link to ci.apache.org right now. And that link shows > up first in search engines for "openoffice daily builds". So if we put an > intermediate page with a proper disclaimer this will actually help to get > the message straight. > Can we add descriptions/additional explanation directly to our main http://ci.apache.org page? > > 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 ... >> 3) We do not offer upgrade notifications for developer builds. >> > > These can happen, but the whole point is that end users won't get those > builds. Direct links to binaries are impossible since URLs change every > day/week; links to pages on ci.apache.org without explanations will not > result in downloads but in puzzled users (we show a mix of everything from > SDK to console logs...). Let me add, Infra will let us know very quickly if > end users start downloading daily builds. > > Was there something that did not work with sharing the ci.apache.org >> address on the dev and qa lists? >> > > That is the key question. Here are some more explanations. > > What I propose: add a link "Development builds" to the column on the right > hand side of http://www.openoffice.org/download/ ; the link leads to > http://www.openoffice.org/download/devbuilds.html (a page Dave objected > to; I've put a large DRAFT disclaimer on top, and I hope we can keep the > page online during this discussion for convenience); this page gives all > necessary disclaimers, ways to get involved and links to the dev builds. > > Why would it be helpful? > > 1) Because links shared by e-mail simply have not worked well so far. > Localization volunteers, for example, are confused on how/when/where dev > builds are made available, if they are available for their platform and in > their language and so on. If they know that there is a path from the > download page their life will be easier and our product more tested. > > 2) Because it allows to enlarge our community. Power users periodically > scan our download pages looking for "something new", especially in this > period. They are likely unaware of our daily builds. But if we manage to > make them aware both that daily builds exist and that they exist as part of > a community QA effort we might get a few new good QA volunteers for version > 4.1.0. If you notice, the proposed intermediate page also gives information > on how to join QA. By the way, this would also help with perception: even > those who will never try those builds can see that there are constant > improvements, happening in an open environment. > > Other solutions: >> 1) ... If the goal is to have only project members >> download, then put it on a page that only project members read >> > > Kay's improvements to http://openoffice.staging.apache.org/developer-faqs. > html#where_can_i_download_developer_builds (to fix: both Raphael's and > Ariel's builds are very outdated at the moment so they shouldn't be > mentioned) are complementary to what I propose. > > 2) Add some authentication on the actual developer build download >> page. Ideally, tie it having a BZ account. >> > > This is an unnecessary effort; contributing should be easy. > > 3) Put a date-based expiration into developer builds, to discourage >> long-term use. >> > > I like this. Well, not a literal date-based expiration since it has an > old-fashioned "Trial version expired" effect. But pointing the update > information to a page where we explain to the user that he is running a dev > build meant only for testing could help. > > Of course, if we keep the discussion open until April it will become > useless to my intended purpose. But I would see it as a missed opportunity > to enlarge the community. And this project, like all projects, should never > waste opportunities. > > Regards, > Andrea. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > -- ------------------------------------------------------------------------------------------------- MzK "Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect." -- James Mason
