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: [RELEASE]: Beta downloads and feedback and a proposed way to the final
On 3/18/14 12:34 AM, Kay Schenk wrote: On Mon, Mar 17, 2014 at 4:02 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 03/17/2014 06:31 PM, schrieb Kay Schenk: On Mon, Mar 17, 2014 at 5:33 AM, Rob Weirrobw...@apache.org wrote: On Mon, Mar 17, 2014 at 3:52 AM, Andrea Pescettipesce...@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 I agree that we should not link the buildbot builds from the main download page despite that this is where they were in the legacy OOo site. We can do more to help the development community find them however. There is and will no linking from the main download webpage. So, this seems to be save. We already have a link to the buildbot page from the project source page (navigation Development - Source Code) -- http://openoffice.apache.org/source.html but it isn't highlighted much. A bit more pimping the section is OK. But it should stay a bit invisible as it is at the moment. I think some wording changes on this page might help. Right. However, the main question is IMHO following: Do we want to present the dev builds in a bit more structured way in order to allow to point asking people to the CWIKI resp. CI webpage? Regarding Andrea's first post inside this thread it seems to be already approved (kind of) that we can link to these dev builds. Marcus Well I decided to brave the waters and updated the project site Developer FAQ (in staging): http://openoffice.staging.apache.org/developer-faqs.html#where_can_i_download_developer_builds If too much, as this is still a *public* web site, I'll be happy to revert (or someone else can). Not committed to production yet. No changes on the Source page yet. We should probably just edit that and link to the Developer FAQ. We already had some info on both the developer snapshots and the buildbot here before but not explained, etc. by the way the current discussion is not related to the thread subject. Can we please start new threads for new topics, this make sit easier fro interested people top follow or not. Juergen - 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
Better visibility for dev builds (Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final)
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. 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
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
Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final
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. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final
On 3/17/14 1:16 AM, Dave Fisher wrote: No links to snapshots from the website. It is ASF policy. it is a somewhat strange policy where the automated generated page is public available as well, isn't it? No advertising of snapshots, but we can let developers know on this list. where exactly is the difference to link to it from here the list , the wiki or point on the public available auto generated overview page? But in general I am no friend of linking to many builds and where we get even more confusion which build is used by whom. As long as we produce the official snapshots manually I would prefer to link to them only and keep the build bots builds. When we have linux build bots with the correct baseline, a windows bots equal to the release build machine and a working Mac bot we can for sure move over to the build bots for general usage. People who are interested in these are normally following this list as well. And for all others where we are interested in feedback we do a blog post and promote the builds like the Beta where we have 138,000 downloads since last Monday. Juergen Regards, Dave Sent from my iPhone On Mar 16, 2014, at 4:07 PM, Andrea Pescetti pesce...@apache.org wrote: Marcus (OOo) wrote: 1. The disclaimer should be above of Target public and more detailed - maybe also in bold, red-colored, etc. See http://www.openoffice.org/download/devbuilds.html now (still not linked to from other pages). I kept the CSS local to the page since I didn't want to mess with the side-wide CSS. 2. The wording should kept more general. Otherwise you have to change the page again and again depending on time, release mode, purpose, etc. As I wrote at the beginning of the thread, so far it would be enough for me to have these builds visible during the beta-to-final phase. Then, if we find out it's useful, we can discuss it further, but focus now should be in having builds more visible in this phase. 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: [RELEASE]: Beta downloads and feedback and a proposed way to the final
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
Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final
On Mon, Mar 17, 2014 at 5:33 AM, Rob Weir robw...@apache.org wrote: 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 I agree that we should not link the buildbot builds from the main download page despite that this is where they were in the legacy OOo site. We can do more to help the development community find them however. We already have a link to the buildbot page from the project source page (navigation Development - Source Code) -- http://openoffice.apache.org/source.html but it isn't highlighted much. I think some wording changes on this page might help. 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: [RELEASE]: Beta downloads and feedback and a proposed way to the final
Am 03/17/2014 06:31 PM, schrieb Kay Schenk: On Mon, Mar 17, 2014 at 5:33 AM, Rob Weirrobw...@apache.org wrote: On Mon, Mar 17, 2014 at 3:52 AM, Andrea Pescettipesce...@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 I agree that we should not link the buildbot builds from the main download page despite that this is where they were in the legacy OOo site. We can do more to help the development community find them however. There is and will no linking from the main download webpage. So, this seems to be save. We already have a link to the buildbot page from the project source page (navigation Development - Source Code) -- http://openoffice.apache.org/source.html but it isn't highlighted much. A bit more pimping the section is OK. But it should stay a bit invisible as it is at the moment. I think some wording changes on this page might help. Right. However, the main question is IMHO following: Do we want to present the dev builds in a bit more structured way in order to allow to point asking people to the CWIKI resp. CI webpage? Regarding Andrea's first post inside this thread it seems to be already approved (kind of) that we can link to these dev builds. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final
Am 03/17/2014 12:07 AM, schrieb Andrea Pescetti: Marcus (OOo) wrote: 1. The disclaimer should be above of Target public and more detailed - maybe also in bold, red-colored, etc. See http://www.openoffice.org/download/devbuilds.html now (still not linked to from other pages). I kept the CSS local to the page since I didn't want to mess with the side-wide CSS. Yes, better now. 2. The wording should kept more general. Otherwise you have to change the page again and again depending on time, release mode, purpose, etc. As I wrote at the beginning of the thread, so far it would be enough for me to have these builds visible during the beta-to-final phase. Then, if we find out it's useful, we can discuss it further, but focus now should be in having builds more visible in this phase. I think I now where this is likely to lead to, but OK. ;-) Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final
On Mon, Mar 17, 2014 at 4:02 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 03/17/2014 06:31 PM, schrieb Kay Schenk: On Mon, Mar 17, 2014 at 5:33 AM, Rob Weirrobw...@apache.org wrote: On Mon, Mar 17, 2014 at 3:52 AM, Andrea Pescettipesce...@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 I agree that we should not link the buildbot builds from the main download page despite that this is where they were in the legacy OOo site. We can do more to help the development community find them however. There is and will no linking from the main download webpage. So, this seems to be save. We already have a link to the buildbot page from the project source page (navigation Development - Source Code) -- http://openoffice.apache.org/source.html but it isn't highlighted much. A bit more pimping the section is OK. But it should stay a bit invisible as it is at the moment. I think some wording changes on this page might help. Right. However, the main question is IMHO following: Do we want to present the dev builds in a bit more structured way in order to allow to point asking people to the CWIKI resp. CI webpage? Regarding Andrea's first post inside this thread it seems to be already approved (kind of) that we can link to these dev builds. Marcus Well I decided to brave the waters and updated the project site Developer FAQ (in staging): http://openoffice.staging.apache.org/developer-faqs.html#where_can_i_download_developer_builds If too much, as this is still a *public* web site, I'll be happy to revert (or someone else can). Not committed to production yet. No changes on the Source page yet. We should probably just edit that and link to the Developer FAQ. We already had some info on both the developer snapshots and the buildbot here before but not explained, etc. - 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: [RELEASE]: Beta downloads and feedback and a proposed way to the final
On 13/03/2014 Jürgen Schmidt wrote: For now I haven't seen really serious problems which of course is good but maybe I have overseen something. Anyway if we don't get serious issues until March 30th I plan to prepare and provide the first final RC on the 31th. The vote will start immediately after the upload ... The plan looks good. I would complement it with two innovations, that would stay in place from now to the final release date: 1) Link to the latest snapshots from the openoffice.org website. We've been too conservative with this, to the point that even our community members cannot find them easily. Details are being discussed on the Infra list, but it is acceptable that the main download page has a link to an intermediate page that contains all suitable disclaimers and links to daily/snapshot builds, specifying that they are to be used by active community members for testing. 2) (an idea from another PMC member) Hold 2-3 informal meetings on Google Hangout or similar platform, where main QA volunteers, developers and volunteers involved in the release process can review the status together, to make sure we are all on the same page for the upcoming release. Even with a small group this would be nice to have, it allows a more effective communication. No decisions would be taken, but the dev list would be informed of what was discussed. Probably the best moment is in the European afternoon, so for example Wednesday or Thursday at 4PM for the next 2-3 weeks. Could it work? Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final
Am 03/16/2014 01:50 PM, schrieb Andrea Pescetti: On 13/03/2014 Jürgen Schmidt wrote: For now I haven't seen really serious problems which of course is good but maybe I have overseen something. Anyway if we don't get serious issues until March 30th I plan to prepare and provide the first final RC on the 31th. The vote will start immediately after the upload ... The plan looks good. I would complement it with two innovations, that would stay in place from now to the final release date: 1) Link to the latest snapshots from the openoffice.org website. We've been too conservative with this, to the point that even our community members cannot find them easily. Details are being discussed on the Infra list, but it is acceptable that the main download page has a link to an intermediate page that contains all suitable disclaimers and links to daily/snapshot builds, specifying that they are to be used by active community members for testing. Interesting change. OK, when Infra is now fine with linking to the dev builds from the public download webpage, then I can insert a respective box. Is linking to the CWiki page or the buildbots preferred? 2) (an idea from another PMC member) Hold 2-3 informal meetings on Google Hangout or similar platform, where main QA volunteers, developers and volunteers involved in the release process can review the status together, to make sure we are all on the same page for the upcoming release. Even with a small group this would be nice to have, it allows a more effective communication. No decisions would be taken, but the dev list would be informed of what was discussed. Probably the best moment is in the European afternoon, so for example Wednesday or Thursday at 4PM for the next 2-3 weeks. Could it work? I haven't heard of this idea until today. Is it listed somewhere on dev@? Thanks Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final
Marcus (OOo) wrote: Am 03/16/2014 01:50 PM, schrieb Andrea Pescetti: The plan looks good. I would complement it with two innovations, that would stay in place from now to the final release date: 1) Link to the latest snapshots from the openoffice.org website. ... Interesting change. OK, when Infra is now fine with linking to the dev builds from the public download webpage, then I can insert a respective box. Is linking to the CWiki page or the buildbots preferred? In order to better differentiate, we will need an intermediate page. I've put a draft at http://www.openoffice.org/download/devbuilds.html (currently not linked to from anywhere) to make the proposal clearer. Also the link in the download page can be in the right hand side column and not in the boxes, for better differentiation (the beta is meant for testing but is formally approved; daily builds are REALLY meant only for testing). 2) (an idea from another PMC member) Hold 2-3 informal meetings on Google Hangout or similar platform, ... for example Wednesday or Thursday at 4PM for the next 2-3 weeks. Could it work? I haven't heard of this idea until today. Is it listed somewhere on dev@? No, you didn't miss anything. That is a proposal I'm bringing to dev now. It came from a personal conversation, so I wanted to make it clear it is not my idea, even though I certainly support it. We said it was to be brought to the lists, but time passed and I'm bringing it here now since it would be useful in the weeks before the release. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final
Marcus (OOo) wrote: 1. The disclaimer should be above of Target public and more detailed - maybe also in bold, red-colored, etc. See http://www.openoffice.org/download/devbuilds.html now (still not linked to from other pages). I kept the CSS local to the page since I didn't want to mess with the side-wide CSS. 2. The wording should kept more general. Otherwise you have to change the page again and again depending on time, release mode, purpose, etc. As I wrote at the beginning of the thread, so far it would be enough for me to have these builds visible during the beta-to-final phase. Then, if we find out it's useful, we can discuss it further, but focus now should be in having builds more visible in this phase. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final
No links to snapshots from the website. It is ASF policy. No advertising of snapshots, but we can let developers know on this list. Regards, Dave Sent from my iPhone On Mar 16, 2014, at 4:07 PM, Andrea Pescetti pesce...@apache.org wrote: Marcus (OOo) wrote: 1. The disclaimer should be above of Target public and more detailed - maybe also in bold, red-colored, etc. See http://www.openoffice.org/download/devbuilds.html now (still not linked to from other pages). I kept the CSS local to the page since I didn't want to mess with the side-wide CSS. 2. The wording should kept more general. Otherwise you have to change the page again and again depending on time, release mode, purpose, etc. As I wrote at the beginning of the thread, so far it would be enough for me to have these builds visible during the beta-to-final phase. Then, if we find out it's useful, we can discuss it further, but focus now should be in having builds more visible in this phase. 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: [RELEASE]: Beta downloads and feedback and a proposed way to the final
On Thu, Mar 13, 2014 at 1:30 AM, Jürgen Schmidt jogischm...@gmail.comwrote: Hi, we have already 92,000 Beta downloads via SF, I can't say exactly how many full install sets and how many of them are language packs only. But I think the number is quite good we should be able to find serious problems if only 50% use the beta for some real testing under normal work conditions. But I don't know ... For now I haven't seen really serious problems which of course is good but maybe I have overseen something. Anyway if we don't get serious issues until March 30th I plan to prepare and provide the first final RC on the 31th. The vote will start immediately after the upload ... The idea is to have the AOO 4.1 is place for the ApacheCon (7.-.11. April) or even better announce it during the ApacheCon. Any opinions on this plan? Juergen I don't know what the normal feedback expectation is for a beta release like this, but this would provide 3 weeks and 3 weekends for testing, so probably a reasonable plan. I know we've already had some feedback on the users list, but we'll keep monitoring things. - 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
[RELEASE]: Beta downloads and feedback and a proposed way to the final
Hi, we have already 92,000 Beta downloads via SF, I can't say exactly how many full install sets and how many of them are language packs only. But I think the number is quite good we should be able to find serious problems if only 50% use the beta for some real testing under normal work conditions. But I don't know ... For now I haven't seen really serious problems which of course is good but maybe I have overseen something. Anyway if we don't get serious issues until March 30th I plan to prepare and provide the first final RC on the 31th. The vote will start immediately after the upload ... The idea is to have the AOO 4.1 is place for the ApacheCon (7.-.11. April) or even better announce it during the ApacheCon. Any opinions on this plan? Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: Beta downloads and feedback and a proposed way to the final
Hi, On 13.03.2014 09:30, Jürgen Schmidt wrote: Hi, we have already 92,000 Beta downloads via SF, I can't say exactly how many full install sets and how many of them are language packs only. But I think the number is quite good we should be able to find serious problems if only 50% use the beta for some real testing under normal work conditions. But I don't know ... For now I haven't seen really serious problems which of course is good but maybe I have overseen something. Anyway if we don't get serious issues until March 30th I plan to prepare and provide the first final RC on the 31th. The vote will start immediately after the upload ... The idea is to have the AOO 4.1 is place for the ApacheCon (7.-.11. April) or even better announce it during the ApacheCon. Any opinions on this plan? +1 Since two days I am reviewing the Bugzilla issues which had been submitted since the availability of the AOO 4.1.0 Beta. Until now, I did not observe any serious issue. Best regards, Oliver. Juergen - 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
