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
Fwd: [jira] [Resolved] (INFRA-7463) Customization for the OpenOffice bugzilla
For your info: The bugzilla improvements regarding field descriptions we discussed in the mailing list thread [Bug 124386] Improve Help for Version Selector are active now; many thanks to Mark Thomas. Herbert Original Message Subject: [jira] [Resolved] (INFRA-7463) Customization for the OpenOffice bugzilla Date: Tue, 18 Mar 2014 09:36:44 + (UTC) From: Mark Thomas (JIRA) j...@apache.org To: h...@apache.org [ https://issues.apache.org/jira/browse/INFRA-7463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved INFRA-7463. Resolution: Fixed Patch applied. Bugzilla restarted. Customization for the OpenOffice bugzilla - Key: INFRA-7463 URL: https://issues.apache.org/jira/browse/INFRA-7463 Project: Infrastructure Issue Type: Wish Components: Infra Wishlist Reporter: Herbert Duerr Attachments: bugzilla.patch The field descriptions for issues in bugzilla are apparently not clear enough, so the OpenOffice project discussed some enhancement ideas on its development mailing list. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
4.1.0_release_blocker requested: [Issue 124427] multi-line text control fields doesn't write into database
Oliver-Rainer Wittmann o...@apache.org has asked for 4.1.0_release_blocker: Issue 124427: multi-line text control fields doesn't write into database https://issues.apache.org/ooo/show_bug.cgi?id=124427 --- Additional Comments from Oliver-Rainer Wittmann o...@apache.org fixed on trunk, revision 1578786 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
4.1.0_release_blocker granted: [Issue 124427] multi-line text control fields doesn't write into database
j...@apache.org has granted Oliver-Rainer Wittmann o...@apache.org's request for 4.1.0_release_blocker: Issue 124427: multi-line text control fields doesn't write into database https://issues.apache.org/ooo/show_bug.cgi?id=124427 --- Additional Comments from j...@apache.org set the showstopper flag again, was removed by mistake - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
4.1.0_release_blocker granted: [Issue 124426] Pop-up errors when open various files on Mac
j...@apache.org has granted fanyuz...@gmail.com's request for 4.1.0_release_blocker: Issue 124426: Pop-up errors when open various files on Mac https://issues.apache.org/ooo/show_bug.cgi?id=124426 --- Additional Comments from j...@apache.org grant showstopper flag as reminder for verification of the next available build - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Bug 124386] Improve Help for Version Selector
On Tue, Mar 11, 2014 at 12:05:31PM +0100, Herbert Duerr wrote: Since many entries in our bugzilla database are not about bugs, but about new features or enhancements I'd also like to use the term issue instead of bug, when Bugzilla refers to such an entry. Isn't it possible to use both? The recent change turns all bug XXX into simple text, for example https://issues.apache.org/ooo/show_bug.cgi?id=124366#c1 used to have a link in See bug 119006 for more information. Regards -- Ariel Constenla-Haile La Plata, Argentina pgp4AZoDJ1jsA.pgp Description: PGP signature
Re: Is it time to re-evaluate the viability of internal documentation?
On Tue, Mar 18, 2014 at 12:34 AM, Keith N. McKenna keith.mcke...@comcast.net wrote: Greetings All; With the documentation list active for over a year now I believe it is time to re-evaluate where we are with the documentation effort and if it is worth continuing. My personal perspective is that very little progress has been made nor do I see the likelihood of that changing in the near future. It has become very frustrating answering inquiries with detailed e-mails about what the needs are and where current information is being worked and then never hearing from many people again. We seem not to have been able to attract skilled technical writers who can give of there time to drive the infrastructure needed and to mentor volunteers who want to help but have not done this type of writing before. I would pose a number of questions that should be considered and answered. 1: Is there a need for user documentation? 2: Is this the place for that documentation to come from? I firmly believe that there is a need for high quality user oriented documentation for OpenOffice. I am just not sure of the best way to go about filling that need. I hope that this effort can generate a renewed interest in how to go about giving the users of this wonderful software documentation of the same quality and professionalism as the code base itself. I think it could be interesting to look at two other areas of the project where we have had greater success with integrating new volunteers. Maybe there are lessons there. I'm thinking of QA and Translation volunteers. In those two cases we also get many emails from volunteers offering to help. I'm not sure of the exact percentage of those who stick around longer term. Certainly we see many express some interest, but then are never heard of again. But we also see solid contributors who anchor the effort, become committers, etc. So what is common between QA and Translation? 1) The presence of more experienced volunteers to structure the work, break it into smaller pieces, help new volunteers get started, etc. You see, for example with QA, Yuzhen taking the lead on defining test cases, Rainer taking the lead in how use Bugzilla effectively, Juergen and Andrea reminding translation volunteers of deadlines and helping them get started, etc. This is partially a question of critical mass. 2) The work is naturally bite sized. You can be an effective QA volunteer working 1 hour a week or 40 hours a week. There are tasks of every size. Ditto for Translators. 3) Both QA and Translation have deadlines, based on our release schedule, to motivate progress. Although we're volunteers, the fact that these efforts are tied to a specific release gives some urgency to get the tasks done. 4) Both areas have a solid way of tracking progress toward release goals, with the easy ability for one volunteer to step and finish a task that someone else has started. So we're rarely stuck waiting for a specific volunteer who might not be available at a given time. So how is it with Doc? You've done much if 1) above. I know you've personally done a lot to make this happen. 2) as well. I wonder if 3) could be part of the issue? Doc is not aligned with a release schedule, at least not in the same way that QA and Translation are. How are with 4)? Could this be a factor? Any other factors? I do think documentation is important to users. But I don't claim to be an expert in this area, or to know exactly what kind of documentation they need most, tutorials versus reference material, PDF's versus videos, etc. Maybe this could be the subject of a survey? Regards, -Rob Regards Keith - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Hello, I can help!
Hello, I have been contemplating getting involved in helping in an open source project for some time and particularly like the OpenOffice project. I have looked through the Help Wanted Page and believe I can assist in a range of capacities. I entered the world of software engineering as a Web Design and Developer and believe I can certainly help improve the website (point 5 and 6) and would like to submit some designs for the landing page. I endure a lot of testing on work projects and could assist on testing developer builds also. I believe that I can also help with testing developer builds and writing documentation. However my real goal would be assisting in bug fixing and updating OpenOffice in the future. I have over 7 years experience developing in web based languages and markup including HTML, CSS, JS and PHP, using them day-in-day out, and more recently around 3 years of Java, building web services and writing selenium integration tests. I am also currently engaged in a part time masters course that is opening my eyes to the paradigms of Haskell and Erlang. Although I have very little experience with C++ I am well versed in OOP and would like to eventually gain enough familiarity with the codebase that I can contribute and assist. But for now I am happy to assist in a bit of visual design for the website and testing whilst to get up to speed. Please let me know if this is of interest or you would like any more details or a CV from me. Kind regards, Stefan Cross 2012 - Current - Scrum Master/Developer, Telefonica Digital 2012 - Current - MSc Software Engineering, Oxford University 2008 - 2012 - Director, Cross Multimedia 2006 - 2:1 BS Media Communications Technology, Oxford Brookes - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[Bug 124455] introducing an attribute for spacing between paragraphs with the same paragraph style
Hello! With bug 124455 I propose a better handling of the formatting of lists and other text blocks in writer. Would anyone have a look on it if this change could be introduced in the next time? Or will it depend on a change of the document format? https://issues.apache.org/ooo/show_bug.cgi?id=124455 Thanks! mroe - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Bug 124386] Improve Help for Version Selector
On 18.03.2014 14:54, Ariel Constenla-Haile wrote: On Tue, Mar 11, 2014 at 12:05:31PM +0100, Herbert Duerr wrote: Since many entries in our bugzilla database are not about bugs, but about new features or enhancements I'd also like to use the term issue instead of bug, when Bugzilla refers to such an entry. Isn't it possible to use both? The recent change turns all bug XXX into simple text, for example https://issues.apache.org/ooo/show_bug.cgi?id=124366#c1 used to have a link in See bug 119006 for more information. As far as I know we'd need to use a bugzilla hook for a more generic auto-linkification. The current changes only changed text templates. Writing the hook seems not too difficult [1] but we haven't gotten around to it. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=364254 Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Reporting a problem with the OpenOffice website
I am 81 year old IPAD user. Keen to down load and use Open Office Word Processor. Please provide instructions on how I can do this.VMY W.Daniels. England UK Sent from my iPad - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Reporting a problem with the OpenOffice website
On Tue, 18 Mar 2014 17:11:49 + William Daniels billj...@icloud.com wrote: I am 81 year old IPAD user. Keen to down load and use Open Office Word Processor. Please provide instructions on how I can do this.VMY W.Daniels. England UK Sent from my iPad - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org It doesn't work on an Ipad - sorry. There is an independent port (AndrOpen Office) of it available for download from the google Play Store (free, as far as I remember). -- Rory O'Farrell ofarr...@iol.ie - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Reporting a problem with the OpenOffice website
Hello, I've a problem to put an automatic date field, when I insert the correct wanted format, it stays in Date and i can't change it ! Thanks
Re: Reporting a problem with the OpenOffice website
On Tue, 18 Mar 2014 18:16:18 + (GMT) Christophe Biguet christophe.big...@yahoo.fr wrote: Hello, I've a problem to put an automatic date field, when I insert the correct wanted format, it stays in Date and i can't change it ! Thanks /View /Field names unchecked -- Rory O'Farrell ofarr...@iol.ie - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Allow to edit pages in CWiki
On 18/03/2014 Salva Open-Office Es wrote: Hello Andrea Please, allow me to edit pages in CWiki User: SLV-es Done. CCing the dev list for reference. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: openoffice.lst, can wJRE be deleted?
Hi all Just for your information. This work is donne. and chacked into trunk. Thanks to Andre for reviewing the patch. Greetings Raphael Am 14.03.2014 um 20:33 schrieb Raphael Bircher: Hi at all I added the patch. Can someone review it? Greetings Raphael Am 14.03.2014 um 15:06 schrieb Raphael Bircher: Hi Andre It's now Issue https://issues.apache.org/ooo/show_bug.cgi?id=124432 I found some other code related to wJRE in the code. I will prepare a patch. Greetings Raphael Am 14.03.2014 um 08:55 schrieb Andre Fischer: On 13.03.2014 23:15, Kay Schenk wrote: On 03/13/2014 06:49 AM, Raphael Bircher wrote: Hi all In openoffice.lst there is still a configuration for the with JRE build. We have anymor Builds with JRE, and I doubt that we will have in future. The license of Java is not ALv2 compatible, right. So the question is, can we delete this part? Greetings Raphael I would think so unless others have a different opinion. I agree that removing this entry from openoffice.lst is a good idea. Raphael, do you want to do it or shall I? I already have two modules on my to-remove list for Monday already. -Andre - 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 - 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: Complete removal of the register assistent
Hi all I made https://issues.apache.org/ooo/show_bug.cgi?id=124457 for this task Greetings Raphael Am 17.03.2014 um 16:55 schrieb Raphael Bircher: Hi at all. I found some plesure in destructive work, and I found more gode to remove. In openoffice.lst are still some reminder of the register assistant. It was removed from Apache OpenOffice right at the beginning of the project. I would like to prepare a patch to remove the rest of this assistant. Have a nice day Raphael - 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: Hello, I can help!
On Tue, Mar 18, 2014 at 7:32 AM, Stefan Cross i...@stefan-cross.com wrote: Hello, I have been contemplating getting involved in helping in an open source project for some time and particularly like the OpenOffice project. I have looked through the Help Wanted Page and believe I can assist in a range of capacities. I entered the world of software engineering as a Web Design and Developer and believe I can certainly help improve the website (point 5 and 6) and would like to submit some designs for the landing page. I endure a lot of testing on work projects and could assist on testing developer builds also. I believe that I can also help with testing developer builds and writing documentation. However my real goal would be assisting in bug fixing and updating OpenOffice in the future. I have over 7 years experience developing in web based languages and markup including HTML, CSS, JS and PHP, using them day-in-day out, and more recently around 3 years of Java, building web services and writing selenium integration tests. I am also currently engaged in a part time masters course that is opening my eyes to the paradigms of Haskell and Erlang. Although I have very little experience with C++ I am well versed in OOP and would like to eventually gain enough familiarity with the codebase that I can contribute and assist. But for now I am happy to assist in a bit of visual design for the website and testing whilst to get up to speed. Please let me know if this is of interest or you would like any more details or a CV from me. Kind regards, Stefan Cross 2012 - Current - Scrum Master/Developer, Telefonica Digital 2012 - Current - MSc Software Engineering, Oxford University 2008 - 2012 - Director, Cross Multimedia 2006 - 2:1 BS Media Communications Technology, Oxford Brookes - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org Hello Stefan and thank you for wanting to get involved. The easiest way to submit proposals for either of our websites would be to apply for an account on our planning wiki-- https://cwiki.apache.org/confluence/display/OOOUSERS/Wiki+Home Just use the Sign Up link. A good place to add information like this would probably be under the Site-Dev-Plan page -- https://cwiki.apache.org/confluence/display/OOOUSERS/Site-Dev-Plan You can include attachments using the wiki as well. There are a lot of areas and opportunities for involvement with this project. Welcome. -- - MzK Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect. -- James Mason
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
