Re: Better visibility for dev builds (Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final)
Excuse me for intervening the discussion, but I still don't get the difference between these links: http://www.openoffice.org/download/all_beta.html http://www.openoffice.org/download/devbuilds.html https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds I'm lost, and others may feel the same.
Re: Better visibility for dev builds (Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final)
Tal Daniel wrote: Excuse me for intervening the discussion, but I still don't get the difference between these links: [1] http://www.openoffice.org/download/all_beta.html [2] http://www.openoffice.org/download/devbuilds.html [3] https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds I'm lost, and others may feel the same. Making your life simpler is what this discussion is meant to do... so no problem! Head to the download page http://www.openoffice.org/download/ (Right column, Additional Resources, Development builds) to get the builds between 4.1.0-beta and the coming 4.1.0 final. These are probably the ones you are interested in. Hebrew will be available after the next run (tomorrow). This corresponds to item #2 in your list above. Item #1 is the beta release, 4.1.0-beta. It is the one we want the general public to test. But volunteers who have already tested the beta and need to check specific bugs or features addressed after the beta will probably want to use #2. So we have: [Beta = #1] -- [Snapshots from AOO410 = download page or #2] -- 4.1.0 Item #3 contains snapshots that are built from time to time. They can be built from the trunk or from a release branch (not every bugfix or feature we add now will go into 4.1.0: most of them will be used for the version after 4.1.0, so they go to trunk instead of going to the AOO410 branch). They currently contain a snapshot that was taken for the Beta, so they are not useful at the moment. When we are not near a release, they are built from trunk and are a good way to test the latest changes. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Better visibility for dev builds (Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final)
Andrea Pescetti wrote: Tal Daniel wrote: Excuse me for intervening the discussion, but I still don't get the difference between these links: [1] http://www.openoffice.org/download/all_beta.html [2] http://www.openoffice.org/download/devbuilds.html [3] https://cwiki.apache.org/confluence/display/OOOUSERS/ Development+Snapshot+Builds I'm lost, and others may feel the same. ... Head to the download page http://www.openoffice.org/download/ (Right column, Additional Resources, Development builds) to get the builds between 4.1.0-beta and the coming 4.1.0 final. These are probably the ones you are interested in. Hebrew will be available after the next run (tomorrow). This corresponds to item #2 in your list above. Item #1 is the beta release, 4.1.0-beta. It is the one we want the general public to test. But volunteers who have already tested the beta and need to check specific bugs or features addressed after the beta will probably want to use #2. So we have: [Beta = #1] -- [Snapshots from AOO410 = download page or #2] -- 4.1.0 Item #3 contains snapshots that are built from time to time. They can be built from the trunk or from a release branch (not every bugfix or feature we add now will go into 4.1.0: most of them will be used for the version after 4.1.0, so they go to trunk instead of going to the AOO410 branch). They currently contain a snapshot that was taken for the Beta, so they are not useful at the moment. When we are not near a release, they are built from trunk and are a good way to test the latest changes. *Thanks*, Andrea, for the explanation. It cleared things up. I always feel so uncomfortable to mail the list with only a thanks; mailing lists should have a LIKE button too :)
Re: Better visibility for dev builds (Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final)
Am 03/26/2014 12:41 AM, schrieb Andrea Pescetti: On 23/03/2014 Dave Fisher wrote: +1 to proceeding along the careful plan that has been developed. Good! So I'll proceed in about 24 hours to: - Adding a link (right column) from http://www.openoffice.org/download/ to http://www.openoffice.org/download/devbuilds.html - Removing the Do not link notice from http://www.openoffice.org/download/devbuilds.html - Making sure we only list the builds that are from the AOO410 branch, i.e., between beta and 4.1 final. Do we have agreement of the fial location of the hints (www.openoffice.org or openoffice.apache.org) I believe it's better located in the later website as we have already a developer section. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Better visibility for dev builds (Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final)
On 26/03/2014 Marcus (OOo) wrote: Am 03/26/2014 12:41 AM, schrieb Andrea Pescetti: Good! So I'll proceed in about 24 hours to: - Adding a link (right column) from http://www.openoffice.org/download/ to http://www.openoffice.org/download/devbuilds.html - Removing the Do not link notice from http://www.openoffice.org/download/devbuilds.html - Making sure we only list the builds that are from the AOO410 branch, i.e., between beta and 4.1 final. Do we have agreement of the fial location of the hints ... I believe it's better located in the later website as we have already a developer section. I've now published the changes. I kept the URLs as above, but I believe we can rediscuss the URL of the intermediate page before the next (after 4.1, probably pre-4.1.1 or whatever will come) heavy QA period a few months from now. By the way, I'm not really happy with having two official sites, two official wikis... not to mention the outdated content. The more we consolidate, the better. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Better visibility for dev builds (Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final)
On 23/03/2014 Dave Fisher wrote: +1 to proceeding along the careful plan that has been developed. Good! So I'll proceed in about 24 hours to: - Adding a link (right column) from http://www.openoffice.org/download/ to http://www.openoffice.org/download/devbuilds.html - Removing the Do not link notice from http://www.openoffice.org/download/devbuilds.html - Making sure we only list the builds that are from the AOO410 branch, i.e., between beta and 4.1 final. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Better visibility for dev builds (Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final)
Hi - Andrea shared with me the conversations that he had regarding the policy and I am convinced that he did in fact have the conversations that I suggested he should have. +1 to proceeding along the careful plan that has been developed. Regards, Dave On Mar 20, 2014, at 1:43 PM, Dave Fisher wrote: Hi Andrea, I am only commenting on a Foundation policy regarding advertising builds. Infrastructure is shared and while the impact of 1000s of users downloading a nightly build may seem small it has a possible negative influence on the 150 other projects and 50 podlings that share this infrastructure. If you want guidance or clearance on an exception to the policy then I think you know where to go. Infrastructure will need to agree and the board must not object. Best Regards, Dave On Mar 19, 2014, at 5:22 PM, Andrea Pescetti wrote: Marcus (OOo) wrote: This means, normal users go to: www.openoffice.org/download/ Power users, dev's, qa's, etc. should be pointed to: openoffice.apache.org/developer-faqs.html So, putting text from Andrea's webpage proposal into the webpage Kay has found (again ;-) ) could be the golden way. They are two improvements in two different directions. Both good (as it would be good to add text to the ci.apache.org page; some of us, but not me, do have access to it). I see no reasons against doing both (pending resolution of the -1 by Dave; but I hope this can be withdrawn after the new explanations). 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 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Better visibility for dev builds (Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final)
On 3/20/14 1:22 AM, Andrea Pescetti wrote: Marcus (OOo) wrote: This means, normal users go to: www.openoffice.org/download/ Power users, dev's, qa's, etc. should be pointed to: openoffice.apache.org/developer-faqs.html So, putting text from Andrea's webpage proposal into the webpage Kay has found (again ;-) ) could be the golden way. They are two improvements in two different directions. Both good (as it would be good to add text to the ci.apache.org page; some of us, but not me, do have access to it). I see no reasons against doing both (pending resolution of the -1 by Dave; but I hope this can be withdrawn after the new explanations). which builds exactly do you want to promote here and with what explanation? - build bots are fine, need no or only little explanation - manually built snapshot/milestones -- please no further page where entries have to be edited manually as well Again somebody should continue to work on build bots that are identical with the build release machines that we can use this builds directly. Different configuration switches can trigger release, beta or dev builds Juergen 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
Re: Better visibility for dev builds (Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final)
Jürgen Schmidt wrote: which builds exactly do you want to promote here and with what explanation? - build bots are fine, need no or only little explanation - manually built snapshot/milestones -- please no further page where entries have to be edited manually as well Whatever is useful to our community. Anyway, the draft is online at http://www.openoffice.org/download/devbuilds.html and I think it's rather clear if one reads all of it. Again somebody should continue to work on build bots that are identical with the build release machines that we can use this builds directly. This is a unrelated problem, and does not apply to this release, even though I hope we can make some steps forward here too and indeed align the buildbots with the release baseline for a future release. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Better visibility for dev builds (Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final)
On 3/20/14 8:59 AM, Andrea Pescetti wrote: Jürgen Schmidt wrote: which builds exactly do you want to promote here and with what explanation? - build bots are fine, need no or only little explanation - manually built snapshot/milestones -- please no further page where entries have to be edited manually as well Whatever is useful to our community. Anyway, the draft is online at http://www.openoffice.org/download/devbuilds.html and I think it's rather clear if one reads all of it. I have read it and I see not how it can help for the release. Feedback on nightly builds from trunk does not help us really at the moment. Development continues on trunk and completely new unrelated problems can come up here. For the release only the aoo410 branch is relevant. Well I have moved yesterday the SNAPSHOT tag on a proper version of the aoo410 branch and the next snapshot build comes closer to what we want release. But the SNAPSHOT build from the bots is Windows only. I hope you see my point and we should first work on the basics. Juergen Again somebody should continue to work on build bots that are identical with the build release machines that we can use this builds directly. This is a unrelated problem, and does not apply to this release, even though I hope we can make some steps forward here too and indeed align the buildbots with the release baseline for a future release. 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
Re: Better visibility for dev builds (Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final)
Jürgen Schmidt wrote: http://www.openoffice.org/download/devbuilds.html Development continues on trunk and completely new unrelated problems can come up here. I don't want to divert the discussion, but wouldn't it make sense to have daily builds both for AOO410 and for trunk? Sure, this means more effort and more resources, but even if a daily build only fixes those couple bugs that may have been approved as stoppers the day before, it's already quite useful to volunteers who don't build OpenOffice themselves. For the release only the aoo410 branch is relevant. Well I have moved yesterday the SNAPSHOT tag on a proper version of the aoo410 branch and the next snapshot build comes closer to what we want release. But the SNAPSHOT build from the bots is Windows only. OK, so we are starting to have Windows (and Linux, right?) builds that are intermediate steps between 4.1.0-Beta and 4.1.0. These do not require extra effort, and these are the ones that should be very visible to our volunteers and prospective volunteers if we want to get the maximum QA coverage. I hope you see my point and we should first work on the basics. I can edit the page to keep only builds that are from the AOO410 branch. Remember, I see this as a targeted effort to deliver great quality in 4.1.0. So I would make the page visible again when a new release is approaching, to show what we will have available at that time. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Better visibility for dev builds (Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final)
On 3/20/14 3:13 PM, Andrea Pescetti wrote: Jürgen Schmidt wrote: http://www.openoffice.org/download/devbuilds.html Development continues on trunk and completely new unrelated problems can come up here. I don't want to divert the discussion, but wouldn't it make sense to have daily builds both for AOO410 and for trunk? Sure, this means more effort and more resources, but even if a daily build only fixes those couple bugs that may have been approved as stoppers the day before, it's already quite useful to volunteers who don't build OpenOffice themselves. sure that would make sense For the release only the aoo410 branch is relevant. Well I have moved yesterday the SNAPSHOT tag on a proper version of the aoo410 branch and the next snapshot build comes closer to what we want release. But the SNAPSHOT build from the bots is Windows only. OK, so we are starting to have Windows (and Linux, right?) builds that are intermediate steps between 4.1.0-Beta and 4.1.0. These do not require extra effort, and these are the ones that should be very visible to our volunteers and prospective volunteers if we want to get the maximum QA coverage. no Linux from the bots, we have only a windows bot building the SNAPSHOT as far as I know Juergen I hope you see my point and we should first work on the basics. I can edit the page to keep only builds that are from the AOO410 branch. Remember, I see this as a targeted effort to deliver great quality in 4.1.0. So I would make the page visible again when a new release is approaching, to show what we will have available at that time. 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
Re: Better visibility for dev builds (Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final)
On Thu, Mar 20, 2014 at 7:27 AM, Jürgen Schmidt jogischm...@gmail.comwrote: On 3/20/14 3:13 PM, Andrea Pescetti wrote: Jürgen Schmidt wrote: http://www.openoffice.org/download/devbuilds.html Development continues on trunk and completely new unrelated problems can come up here. I don't want to divert the discussion, but wouldn't it make sense to have daily builds both for AOO410 and for trunk? Sure, this means more effort and more resources, but even if a daily build only fixes those couple bugs that may have been approved as stoppers the day before, it's already quite useful to volunteers who don't build OpenOffice themselves. sure that would make sense For the release only the aoo410 branch is relevant. Well I have moved yesterday the SNAPSHOT tag on a proper version of the aoo410 branch and the next snapshot build comes closer to what we want release. But the SNAPSHOT build from the bots is Windows only. OK, so we are starting to have Windows (and Linux, right?) builds that are intermediate steps between 4.1.0-Beta and 4.1.0. These do not require extra effort, and these are the ones that should be very visible to our volunteers and prospective volunteers if we want to get the maximum QA coverage. no Linux from the bots, we have only a windows bot building the SNAPSHOT as far as I know Juergen We have a 32 bit Linux SNAPSHOT, and a windows 7 SNAPSHOT which builds once a week on Sunday at 7:00A (not sure about timezone). The 4.10 tag is also building once a week on Sunday. I hope you see my point and we should first work on the basics. I can edit the page to keep only builds that are from the AOO410 branch. Remember, I see this as a targeted effort to deliver great quality in 4.1.0. So I would make the page visible again when a new release is approaching, to show what we will have available at that time. 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 -- - MzK Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect. -- James Mason
Re: Better visibility for dev builds (Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final)
Hi Andrea, I am only commenting on a Foundation policy regarding advertising builds. Infrastructure is shared and while the impact of 1000s of users downloading a nightly build may seem small it has a possible negative influence on the 150 other projects and 50 podlings that share this infrastructure. If you want guidance or clearance on an exception to the policy then I think you know where to go. Infrastructure will need to agree and the board must not object. Best Regards, Dave On Mar 19, 2014, at 5:22 PM, Andrea Pescetti wrote: Marcus (OOo) wrote: This means, normal users go to: www.openoffice.org/download/ Power users, dev's, qa's, etc. should be pointed to: openoffice.apache.org/developer-faqs.html So, putting text from Andrea's webpage proposal into the webpage Kay has found (again ;-) ) could be the golden way. They are two improvements in two different directions. Both good (as it would be good to add text to the ci.apache.org page; some of us, but not me, do have access to it). I see no reasons against doing both (pending resolution of the -1 by Dave; but I hope this can be withdrawn after the new explanations). 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
Re: Better visibility for dev builds (Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final)
On Tue, Mar 18, 2014 at 4:21 PM, Andrea Pescetti pesce...@apache.orgwrote: 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.
Re: Better visibility for dev builds (Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final)
Am 03/19/2014 12:21 AM, schrieb Andrea Pescetti: 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. 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. I think the policy problem is not real problem and that a central webpage can have advantages should be also clear. *For me* only the location of this page is now open. Of course it's most comfortable to have all things about download in a single place. However, in this case I think a split regarding our target audience is better. This means, normal users go to: www.openoffice.org/download/ Power users, dev's, qa's, etc. should be pointed to: openoffice.apache.org/developer-faqs.html So, putting text from Andrea's webpage proposal into the webpage Kay has found (again ;-) ) could be the golden way. My 2 ct Marcus 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
Re: Better visibility for dev builds (Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final)
Marcus (OOo) wrote: This means, normal users go to: www.openoffice.org/download/ Power users, dev's, qa's, etc. should be pointed to: openoffice.apache.org/developer-faqs.html So, putting text from Andrea's webpage proposal into the webpage Kay has found (again ;-) ) could be the golden way. They are two improvements in two different directions. Both good (as it would be good to add text to the ci.apache.org page; some of us, but not me, do have access to it). I see no reasons against doing both (pending resolution of the -1 by Dave; but I hope this can be withdrawn after the new explanations). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Better visibility for dev builds (Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final)
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
