[Amber] moving code from Lab
Hi all Amber community members, our infrastructure is up and running!!! If everybody agrees I'll start moving my original Amber stuff from Lab in the new SVN location. Thoughts? See you, have a nice day!!! Simo http://people.apache.org/~simonetripodi/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [Amber] moving code from Lab
On 01/06/2010 14:34, Simone Tripodi wrote: Hi all Amber community members, our infrastructure is up and running!!! If everybody agrees I'll start moving my original Amber stuff from Lab in the new SVN location. Thoughts? Sounds good. I'd like to contribute code too, but Pablo I are still waiting on ids... p (Anyone want to ask Infra again?) See you, have a nice day!!! Simo http://people.apache.org/~simonetripodi/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org signature.asc Description: OpenPGP digital signature
Incubator PMC/Board report for June 2010 (general@incubator.apache.org)
Dear Deltacloud Developers, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for . The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted one week before the board meeting, to allow sufficient time for review. Please submit your report with sufficient time to allow the incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is one week prior to the board meeting. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. This should be appended to the Incubator Wiki page at: http://wiki.apache.org/incubator/June2010 Note: This manually populated. You may need to wait a little before this page is created from a template. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Incubator PMC/Board report for June 2010 (general@incubator.apache.org)
Dear Amber Developers, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for . The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted one week before the board meeting, to allow sufficient time for review. Please submit your report with sufficient time to allow the incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is one week prior to the board meeting. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. This should be appended to the Incubator Wiki page at: http://wiki.apache.org/incubator/June2010 Note: This manually populated. You may need to wait a little before this page is created from a template. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Incubator PMC/Board report for June 2010 (general@incubator.apache.org)
Dear Whirr Developers, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for . The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted one week before the board meeting, to allow sufficient time for review. Please submit your report with sufficient time to allow the incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is one week prior to the board meeting. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. This should be appended to the Incubator Wiki page at: http://wiki.apache.org/incubator/June2010 Note: This manually populated. You may need to wait a little before this page is created from a template. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Incubator PMC/Board report for June 2010 (general@incubator.apache.org)
Dear Zeta Components Developers, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for . The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted one week before the board meeting, to allow sufficient time for review. Please submit your report with sufficient time to allow the incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is one week prior to the board meeting. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. This should be appended to the Incubator Wiki page at: http://wiki.apache.org/incubator/June2010 Note: This manually populated. You may need to wait a little before this page is created from a template. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[ANN] Apache Shiro 1.0.0-incubating Released!
Dear Apache Shiro Community, We are proud and excited to offer Apache Shiro's first stable release as an Apache Incubator podling! Version 1.0.0-incubating is available immediately for download here: http://incubator.apache.org/shiro/download.html Associated documentation is available here: http://incubator.apache.org/shiro/documentation.html Release notes are included below. Thank you so much to the Apache community and the Apache Incubator for helping us move toward our first release. A very special thanks goes to our user community and early adopters for helping us refine our first stable release. Best Regards, Les Hazlewood -- Release Notes are browsable online here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310950styleName=Htmlversion=12314078 And included here for convenience: Release Notes - Shiro - Version 1.0.0-incubating ** Bug * [SHIRO-10] - Aliases in the ini configuration builder do not work correctly * [SHIRO-82] - Shiro strips anchor (#) values from the URL if user is unauthenticated * [SHIRO-87] - Fix package name of package-info.java in shiro-core * [SHIRO-89] - Sample Spring Application - WebStart won't launch * [SHIRO-95] - Specifying my own Cache in ShiroFilter not working * [SHIRO-101] - Comma in role in the properties file is not read correctly by the PropertyRealm * [SHIRO-106] - AuthorizationFilter needs to use sendError not setStatus to make container process the request through ERROR dispatcher * [SHIRO-108] - Basic HTTP Auth: Empty password or username causes IllegalStateException * [SHIRO-115] - ActiveDirectoryRealm might by vulnerable to LDAP search code injection * [SHIRO-120] - AbstractLdapRealm's doGetAuthenticationInfo catches naming exception, but then only logs a message * [SHIRO-124] - MethodInvocation is missing a getThis() (or equivalent) method * [SHIRO-130] - ShiroFilter does not work with proxied security manager * [SHIRO-135] - AccessControlException exception on GAE with Grails * [SHIRO-138] - AbstractRememberMeManager attempts to process null/empty byte array * [SHIRO-141] - Problem with WebRememberMeManager * [SHIRO-142] - Jetty throws an IllegalStateException after redirect in AuthorizationFilter * [SHIRO-145] - Losing Session * [SHIRO-150] - RememberMeManager NPE * [SHIRO-154] - Adding ehcahe CacheManager to Spring Sample failes * [SHIRO-156] - SimpleAuthenticationInfo.merge does not merge principals if its internal principal collection is not mutable * [SHIRO-157] - RememberMeManager should no longer be consulted once a remembered identity is discovered * [SHIRO-158] - Date AbstractSessionManager.getLastAccessTime(Serializable) returns start time * [SHIRO-159] - ThreadLocal is not cleared upon the unloading of the webapp and the SHiro Servlet * [SHIRO-161] - No SecurityManager accessible to the calling code * [SHIRO-163] - ModularRealmAuthorizer.setRealms needs to call applyRolePermissionResolverToRealms * [SHIRO-164] - The request/response pair should be available at all times to web-related components * [SHIRO-167] - getServletContext allways return null with conf via spring (native mode) * [SHIRO-172] - Missing SVN properties ** Improvement * [SHIRO-59] - Refactor Realm implementations to favor delegation over inheritance * [SHIRO-83] - Make sessionId cookie optional * [SHIRO-86] - Add Builder design pattern for arbitrary Subject construction * [SHIRO-88] - Create a profile for installing javadocs and source to keep build time short * [SHIRO-104] - Default AuthenticationStrategy should be AtLeastOneSuccessful instead of All * [SHIRO-109] - RememberMeManager should have access to Subject context map * [SHIRO-110] - Remove org.apache.shiro.mgt.SubjectBinder and its usages * [SHIRO-111] - Web SecurityManager should not fail in non-request usages * [SHIRO-112] - Implement Externalizable for serializable classes * [SHIRO-114] - Break circular dependency between SubjectFactory and DefaultSecurityManager * [SHIRO-125] - Support overrding the credentialsMatcher for the implicit IniRealm * [SHIRO-128] - Remove convenience configuration methods * [SHIRO-131] - Improved Shiro Filter configuration for Spring environments * [SHIRO-133] - Automatically shut down the Session validation thread * [SHIRO-136] - Mark Spring as scope provided to let users specificy their own version of Spring * [SHIRO-137] - Go through Shiro dependencies and consider marking most third-party dependencies as provided * [SHIRO-139] - Cookie support refactoring - Simplify cookie configuration, support HttpOnly cookies and default session cookies to be HttpOnly = true * [SHIRO-144] - MemorySessionDao should be propably abstract * [SHIRO-146] - Annotation authorizations should throw UnauthenticationException if the subject identity is not known. * [SHIRO-148] -
Re: [ANN] Apache Shiro 1.0.0-incubating Released!
On 01/06/2010, Les Hazlewood lhazlew...@apache.org wrote: Dear Apache Shiro Community, We are proud and excited to offer Apache Shiro's first stable release as an Apache Incubator podling! Version 1.0.0-incubating is available immediately for download here: http://incubator.apache.org/shiro/download.html Sorry to keep going on about Shiro, but the download page does not follow standard ASF practice. The download page links to reposity.apache.org. However repository.apache.org is not to be used for direct publication to end users, it is for publishing to the main maven repo. Also, the downloads page does not have a link to the KEYS file. Nor does it have any documentation on how to use the sigs and hashes. The downloads page should only link to the ASF mirrors, see for example: http://incubator.apache.org/photark/photark-downloads.html Also, there is no DISCLAIMER in any of the archive files. AIUI, Incubator releases MUST contain a disclaimer: http://incubator.apache.org/guides/branding.html#disclaimers and http://incubator.apache.org/guides/mentor.html#documents-clean-up S. P.S. The website now makes the incubation status clear - thanks! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [ANN] Apache Shiro 1.0.0-incubating Released!
The download page links to reposity.apache.org. However repository.apache.org is not to be used for direct publication to end users, it is for publishing to the main maven repo. This wasn't clear on the apache infrastructure page - it states that repository.apache.org is part of the distribution infrastructure. Now that we've been notified that this is not the case, we'll fix it as soon as possible. Thanks! Also, the downloads page does not have a link to the KEYS file. Nor does it have any documentation on how to use the sigs and hashes. We'll fix that. The downloads page should only link to the ASF mirrors, see for example: http://incubator.apache.org/photark/photark-downloads.html Also, there is no DISCLAIMER in any of the archive files. AIUI, Incubator releases MUST contain a disclaimer: The branding link only specifies that podling websites must display that disclaimer. That exact disclaimer is the very first paragraph on the download page. AIUI, there is no mandate that a DISCLAIMER file must be included in the actual packaged distribution. Otherwise we assume the release would have been voted against. On a side note, we're doing our best to adhere to all requirements, and we're happy to do so. But it has been *incredibly* time consuming and frustrating to try to interpret what should be step-by-step courses of action to adhere to these requirements. Why isn't there a no-frills step-by-step, no room-for-error release checklist that podlings can follow to guarantee that all required criteria are met? It seems like such a checklist would be of the highest priority for the Incubator to ensure that personal interpretation is minimized or eliminated from the release process. This release management page [1] is incredibly long and full of policy and reasoning, which is all well and good if one wants to understand *why* these policies exist, but podlings really need a step-by-step *how-to* guide that references the 'why' document so we can service our communities as efficiently as possible. The 'why' guide is fantastic to read at our leisure, but the 'how' document would be far more useful to podlings when release time comes. My .02, Les [1] http://incubator.apache.org/guides/releasemanagement.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [ANN] Apache Shiro 1.0.0-incubating Released!
Hi folks, congratulation for getting the release out of the door ... :-) ... and shiro folks (aka JSecurity) did an excellent job. Regarding the no-frills step-by-step, no room-for-error release +) it is difficult to write +) different projects have different tools to release (manual, Ant, Maven) making the stuff even more difficult Maybe more stuff can be done to streamline your release process using M2 - maybe I can lend you a hand Cheers, Siegfried Goeschl On 01.06.10 22:26, Les Hazlewood wrote: The download page links to reposity.apache.org. However repository.apache.org is not to be used for direct publication to end users, it is for publishing to the main maven repo. This wasn't clear on the apache infrastructure page - it states that repository.apache.org is part of the distribution infrastructure. Now that we've been notified that this is not the case, we'll fix it as soon as possible. Thanks! Also, the downloads page does not have a link to the KEYS file. Nor does it have any documentation on how to use the sigs and hashes. We'll fix that. The downloads page should only link to the ASF mirrors, see for example: http://incubator.apache.org/photark/photark-downloads.html Also, there is no DISCLAIMER in any of the archive files. AIUI, Incubator releases MUST contain a disclaimer: The branding link only specifies that podling websites must display that disclaimer. That exact disclaimer is the very first paragraph on the download page. AIUI, there is no mandate that a DISCLAIMER file must be included in the actual packaged distribution. Otherwise we assume the release would have been voted against. On a side note, we're doing our best to adhere to all requirements, and we're happy to do so. But it has been *incredibly* time consuming and frustrating to try to interpret what should be step-by-step courses of action to adhere to these requirements. Why isn't there a no-frills step-by-step, no room-for-error release checklist that podlings can follow to guarantee that all required criteria are met? It seems like such a checklist would be of the highest priority for the Incubator to ensure that personal interpretation is minimized or eliminated from the release process. This release management page [1] is incredibly long and full of policy and reasoning, which is all well and good if one wants to understand *why* these policies exist, but podlings really need a step-by-step *how-to* guide that references the 'why' document so we can service our communities as efficiently as possible. The 'why' guide is fantastic to read at our leisure, but the 'how' document would be far more useful to podlings when release time comes. My .02, Les [1] http://incubator.apache.org/guides/releasemanagement.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [ANN] Apache Shiro 1.0.0-incubating Released!
Hi Sigfried, I guess that's my point. We use M2. I bet 80% (if not more) of podlings use M2. There shouldn't have to be much thought involved to get an M2-based project released - a de facto guide should exist and podlings can deviate from it where allowed and where it makes sense for their project. Until that 'baseline' exists, we all feel unnecessary pain. Thanks for your offer to help - I personally think there should be an incubator-wide editible wiki step-by-step guide that people can contribute to (via discussion) as necessary for M2 projects since that encompasses most Incubator projects. Any help in writing such a guide would be *immensely* appreciated! Thanks, Les On Tue, Jun 1, 2010 at 1:44 PM, Siegfried Goeschl siegfried.goes...@it20one.at wrote: Hi folks, congratulation for getting the release out of the door ... :-) ... and shiro folks (aka JSecurity) did an excellent job. Regarding the no-frills step-by-step, no room-for-error release +) it is difficult to write +) different projects have different tools to release (manual, Ant, Maven) making the stuff even more difficult Maybe more stuff can be done to streamline your release process using M2 - maybe I can lend you a hand Cheers, Siegfried Goeschl On 01.06.10 22:26, Les Hazlewood wrote: The download page links to reposity.apache.org. However repository.apache.org is not to be used for direct publication to end users, it is for publishing to the main maven repo. This wasn't clear on the apache infrastructure page - it states that repository.apache.org is part of the distribution infrastructure. Now that we've been notified that this is not the case, we'll fix it as soon as possible. Thanks! Also, the downloads page does not have a link to the KEYS file. Nor does it have any documentation on how to use the sigs and hashes. We'll fix that. The downloads page should only link to the ASF mirrors, see for example: http://incubator.apache.org/photark/photark-downloads.html Also, there is no DISCLAIMER in any of the archive files. AIUI, Incubator releases MUST contain a disclaimer: The branding link only specifies that podling websites must display that disclaimer. That exact disclaimer is the very first paragraph on the download page. AIUI, there is no mandate that a DISCLAIMER file must be included in the actual packaged distribution. Otherwise we assume the release would have been voted against. On a side note, we're doing our best to adhere to all requirements, and we're happy to do so. But it has been *incredibly* time consuming and frustrating to try to interpret what should be step-by-step courses of action to adhere to these requirements. Why isn't there a no-frills step-by-step, no room-for-error release checklist that podlings can follow to guarantee that all required criteria are met? It seems like such a checklist would be of the highest priority for the Incubator to ensure that personal interpretation is minimized or eliminated from the release process. This release management page [1] is incredibly long and full of policy and reasoning, which is all well and good if one wants to understand *why* these policies exist, but podlings really need a step-by-step *how-to* guide that references the 'why' document so we can service our communities as efficiently as possible. The 'why' guide is fantastic to read at our leisure, but the 'how' document would be far more useful to podlings when release time comes. My .02, Les [1] http://incubator.apache.org/guides/releasemanagement.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [ANN] Apache Shiro 1.0.0-incubating Released!
+1 on that step by step wiki guide. I'm willing to contribute/discuss as I believe our release process could be simpler. Cheers Francis On 1 Jun 2010 22:50, Les Hazlewood lhazlew...@apache.org wrote: Hi Sigfried, I guess that's my point. We use M2. I bet 80% (if not more) of podlings use M2. There shouldn't have to be much thought involved to get an M2-based project released - a de facto guide should exist and podlings can deviate from it where allowed and where it makes sense for their project. Until that 'baseline' exists, we all feel unnecessary pain. Thanks for your offer to help - I personally think there should be an incubator-wide editible wiki step-by-step guide that people can contribute to (via discussion) as necessary for M2 projects since that encompasses most Incubator projects. Any help in writing such a guide would be *immensely* appreciated! Thanks, Les On Tue, Jun 1, 2010 at 1:44 PM, Siegfried Goeschl siegfried.goes...@it20one.at wrote: Hi folks,...
London Java Community Unconference
I just wanted to let you know about a ConCom approved event in London, UK this month. There will be an Apache Way talk and a few ASF projects will be there. Maybe your projects should be too? As you may already have seen the London Java Community (LJC) are running their June Unconference is association with the ASF. The LJC represent about 1000 Java developers from the London (UK) area, LJC members have various levels of understanding of open source and recent LJC events suggest that they are keen to learn more. Apache is such a major player in the open source world but (incredible though it may seem) some people in the Java world still equate Apache with the http server project and have no understanding of the breadth, scope and culture of the ASF. In suggesting the unconference partnership the organisers goal is provide Apache committers with a platform and a different audience to the ones that already attend things like ApacheCon and to provide LJC members with an opportunity to gain a much broader understanding of the ASF. The unconference organisers would be delighted to welcome anyone who can talk about any aspect of the ASF on June the 26th The sign up details are here: http://skillsmatter.com/event/java-jee/london-java-community-unconference-02/zx-548 Ross Sent from my mobile device.
Re: [ANN] Apache Shiro 1.0.0-incubating Released!
On 01/06/2010, Les Hazlewood lhazlew...@apache.org wrote: The download page links to reposity.apache.org. However repository.apache.org is not to be used for direct publication to end users, it is for publishing to the main maven repo. This wasn't clear on the apache infrastructure page - it states that repository.apache.org is part of the distribution infrastructure. Now that we've been notified that this is not the case, we'll fix it as soon as possible. Thanks! Which page? Do you mean: http://www.apache.org/dev/release-publishing.html#distribution If so, I understand that is in the process of being updated. Also, the downloads page does not have a link to the KEYS file. Nor does it have any documentation on how to use the sigs and hashes. We'll fix that. Thanks! The downloads page should only link to the ASF mirrors, see for example: http://incubator.apache.org/photark/photark-downloads.html Also, there is no DISCLAIMER in any of the archive files. AIUI, Incubator releases MUST contain a disclaimer: The branding link only specifies that podling websites must display that disclaimer. That exact disclaimer is the very first paragraph on the download page. http://incubator.apache.org/guides/branding.html#disclaimers says: Podling web sites MUST include a clear disclaimer on their website and in all documentation (including releases) stating that they are in incubation. The important part here is (including releases). AIUI, there is no mandate that a DISCLAIMER file must be included in the actual packaged distribution. There is no requirement that the disclaimer be in a file called DISCLAIMER. However it must be present, as mentioned above. It is suggested that it is placed in a separate DISCLAIMER file as this makes it more obvious, and makes it easier to drop post-incubation. Otherwise we assume the release would have been voted against. The lack of a DISCLAIMER was reported as part of the vote. I don't know why it was not considered blocking. On a side note, we're doing our best to adhere to all requirements, and we're happy to do so. But it has been *incredibly* time consuming and frustrating to try to interpret what should be step-by-step courses of action to adhere to these requirements. Why isn't there a no-frills step-by-step, no room-for-error release checklist that podlings can follow to guarantee that all required criteria are met? It seems like such a checklist would be of the highest priority for the Incubator to ensure that personal interpretation is minimized or eliminated from the release process. I agree entirely. This release management page [1] is incredibly long and full of policy and reasoning, which is all well and good if one wants to understand *why* these policies exist, but podlings really need a step-by-step *how-to* guide that references the 'why' document so we can service our communities as efficiently as possible. The 'why' guide is fantastic to read at our leisure, but the 'how' document would be far more useful to podlings when release time comes. Agreed it is long-winded. Toward the end it contains the section: http://incubator.apache.org/guides/releasemanagement.html#notes-disclaimer which says: TODO: the incubator requires that users are informed that the by including a standard disclaimer. may be include in README, RELEASE_NOTES DISCLAIMER. It is recommended that it is not included in NOTICES This is very badly worded. But given that NOTICE must be included in releases it implies that the disclaimer must also be included in releases. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [ANN] Apache Shiro 1.0.0-incubating Released!
On Tue, Jun 1, 2010 at 4:42 PM, sebb seb...@gmail.com wrote: On 01/06/2010, Les Hazlewood lhazlew...@apache.org wrote: Otherwise we assume the release would have been voted against. The lack of a DISCLAIMER was reported as part of the vote. I don't know why it was not considered blocking. Either you vote or you don't, everything else is considered advisory, you know that. The release packages that most people in practice will use contain -incubating in the file name. I don't know what could be any more explicit. Anyhow, we'll add a file for the next release. Why isn't there a no-frills step-by-step, no room-for-error release checklist that podlings can follow to guarantee that all required criteria are met? It seems like such a checklist would be of the highest priority for the Incubator to ensure that personal interpretation is minimized or eliminated from the release process. Maven (the project) has super clear step-by-step instructions at http://maven.apache.org/developers/release/apache-release.html for releasing with Maven (kudos to Maven guys for that!) which I followed religiously. Maybe you could write another one for Maven-based podling releases but I'm not sure it's worth it. Most of the pain we (Shiro) experienced was with the website - these rules are really not clear and there's a million different competing technologies to put together a project website. Unless incubator starts dictating the technologies to use for a podling website (which I'd be strongly against), I don't see how one could write up a *simple* checklist. It's worth an effort to clarify the http://incubator.apache.org/guides/releasemanagement.html page though. Whatever the technology, I'd much rather improve something existing than whip up yet another semi-official Confluence page. Kalle - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
