On Tue, Mar 18, 2014 at 7: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. > >> 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. >
This is good to know. I had not noticed that the URLs for the binaries encoded the revision number, so the danger of deep links to them is diminished. >> 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. > We do have links in other pages, pages intended specifically for project volunteers, e.g.: http://openoffice.apache.org/orientation/intro-qa.html. So I have nothing against this info being shared with volunteers. It should be shared with them. My concern was putting the info on our main download page which is a public-facing page designed for end users. This page is 2nd only to our index.html home page. It is a very prominent place to put something like this. But I'll say this: If it is abused, we'll know about it quickly and can change the page and links. So the risk of giving this a try is low. > 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. > Also, maybe have the developer builds have a different splash screen and logo, like we do with the beta, so it clear what the status is. > 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. > We'd enhance this if we had a "report bug" link on the help menu, maybe also a link to our "get involved" page in the Help/About page. 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
