Re: [VOTE] Accept project Imperius into the Incubator
Bertrand Delacretaz wrote: > On 9/30/07, Bill Stoddard <[EMAIL PROTECTED]> wrote: > >> ...Nominated Mentors >> >> -Bill Stoddard([EMAIL PROTECTED])... > > Are we willing to accept a podling with just one mentor? > > Although [1] doesn't set a minimum number, we usually (always?) have > more than one. The recent tradition is to try to obtain and hold three active mentors per podling, as best we can. I'd love to see two more folks to step up and help co-mentor. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept project Imperius into the Incubator
On 9/30/07, Bill Stoddard <[EMAIL PROTECTED]> wrote: > ...Nominated Mentors > > -Bill Stoddard([EMAIL PROTECTED])... Are we willing to accept a podling with just one mentor? Although [1] doesn't set a minimum number, we usually (always?) have more than one. (sorry, missed that in the discussion that lead to this vote) -Bertrand [1] http://incubator.apache.org/guides/proposal.html#template-mentors - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept project Imperius into the Incubator
On 9/30/07, Bill Stoddard <[EMAIL PROTECTED]> wrote: > > Please vote on accepting project Imperius into the Apache Incubator. The > vote will run 1 week, > until Sunday, Oct. 7, 2007 or until all Incubator PMC members have voted. > [X] +1 Accept Imperius project for incubation Matthieu
Re: [VOTE] Accept project Imperius into the Incubator
+1 Craig On Sep 30, 2007, at 7:06 AM, Bill Stoddard wrote: Greetings from North Carolina on a bright, beautiful, sunny fall day! Thank You to all those who gave comments on the proposal. I made one small tweak; Tomcat, rather than Geronimo, should be one of the first bindings. Please vote on accepting project Imperius into the Apache Incubator. The vote will run 1 week, until Sunday, Oct. 7, 2007 or until all Incubator PMC members have voted. [ ] +1 Accept Imperius project for incubation [ ] 0 Don't care [ ] -1 Reject for the following reason : Thanks, Bill -//- Abstract - Policy systems allow administrators to define policies that guide the automated administration of resources. Such automation saves time and effort by simplifying resource-management. We proposed to develop a policy-based management infrastructure that automates administrative tasks by executing policies written in the "Simplified Policy Language" (SPL), a standards-based policy language. Proposal -- This proposal seeks to create a project within the Apache Software Foundation to (1) develop a policy evaluator for the SPL policy language, and (2) develop bindings between the policy evaluator and projects such as Apache Geronimo or Apache Tomcat. Background --- As computer systems become more complicated, they continue to become increasingly complex and costly to manage. Various studies have shown that the cost of managing systems often exceeds the cost of purchasing them. The goal of the Imperius project is to reduce management burden by allowing administrators to specify policies that replace manual administrative actions. Rationale -- Policy-based management is one approach to reducing the cost of systems administration. Administrators define policies that express a "management intent", and the policy-based management system executes the policy, thereby reducing the burden on the administrator. For example, a policy might state "backup the database daily at 1am." A policy management system would interpret the policy, and trigger the database to perform a backup at the assigned time, offloading that task from the administrator. To allow more flexible semantics, such policies are often expressed as "If-Then" (also called "Condition-Action") rules. For example, "If the packet comes from subnet 6.7.8.*, Then place it on the high-priority outgoing queue" or "If the data in the database have changed by 10%, Then perform an incremental backup." Such policies allow for more complex automation. To implement these kinds of rule-based policies, the policy system must interact with the system's APIs. In the second example above, the system relies on the ability to measure the percentage of data that have changed since the last backup (or to compute that value from measurable data). Similarly, to execute the "then" clause, the policy system must be able to start an incremental backup on the database using the database's API. Expressed generally, a policy system must have a binding to the "instrumentation layer" or API for the system under management. Thus, policy systems consist of two major components: an evaluation engine and a binding to an instrumentation environment. The evaluation engine (1) accepts policies expressed according to a well-defined grammar, (2) collects the data needed to evaluate the policies, and (3) actuates the "Then" section as appropriate. This project would build an SPL evaluation engine and bindings to various Apache and non-Apache APIs. The design of SPL, a Preliminary DMTF standard, is inspired by existing policy languages and models including PDL (policy definition language) from Bell Laboratories, the Ponder policy language from Imperial College, and other policy languages. The basic unit of a SPL policy is a policy rule. An SPL policy rule consists of a condition, an action, and other fields. Multiple policy rules can be grouped into a policy group. Policy groups can be nested -- i.e., a policy group can contain another policy group. For the specification of the policy condition, SPL provides a rich set of operators that act on the following types: signed and unsigned short, regular and long integers, float and long float, character, string, Boolean, and calendar. We expect the community to develop a number of bindings between the evaluation engine and APIs. Examples include the API for Geronimo or Tomcat, and standard interfaces such as WSDM and CIM. The community may choose to develop a wide range of bindings, all leveraging the common SPL engine and policy syntax. The Imperius Policy Engine will be implemented in the form of a Java application. The SPL application will provide the following functionality: 1. PolicyManager - The PolicyManager acts as an orchestrator delegating tasks to its subcomponents. 2. PolicyDataStore - The PolicyDataStore is responsible for two major tasks: Policy Storage
Re: [VOTE] Accept project Imperius into the Incubator
On Sunday 30 September 2007 22:06, Bill Stoddard wrote: > Please vote on accepting project Imperius into the Apache Incubator. The > vote will run 1 week, until Sunday, Oct. 7, 2007 or until all Incubator PMC > members have voted. [x] +1 Accept Imperius project for incubation Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta [was: Effects on corporate backing withdrawals [was: Incubator Proposal: Pig]]
Niclas Hedhman wrote: > I don't know what to suggest, but perhaps recruiting one or more veteran > ASFer, either just off the member's list or some experienced Incubator > mentor, feeling this being important could just join the PMC and at least > ensure process with 3 pairs of eye balls. Yeah, we'll try to get a veteran (though not a member) to help us out as the chair for the initial phase. (speaking for HttpComponents, not JMeter) If anyone here feels like keeping an eye on us too, you're most welcome. We know our way through the code and public processes up to PMC, but we currently don't have an ASF member on board who is familiar with what's going on beyond PMC. (speaking for both) thanks for taking the time, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept project Imperius into the Incubator
Yo, On 9/30/07, Bill Stoddard <[EMAIL PROTECTED]> wrote: > Please vote on accepting project Imperius into the Apache Incubator. The vote > will run 1 week, > until Sunday, Oct. 7, 2007 or until all Incubator PMC members have voted. > > > [ X ] +1 Accept Imperius project for incubation Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Accept project Imperius into the Incubator
Greetings from North Carolina on a bright, beautiful, sunny fall day! Thank You to all those who gave comments on the proposal. I made one small tweak; Tomcat, rather than Geronimo, should be one of the first bindings. Please vote on accepting project Imperius into the Apache Incubator. The vote will run 1 week, until Sunday, Oct. 7, 2007 or until all Incubator PMC members have voted. [ ] +1 Accept Imperius project for incubation [ ] 0 Don't care [ ] -1 Reject for the following reason : Thanks, Bill -//- Abstract - Policy systems allow administrators to define policies that guide the automated administration of resources. Such automation saves time and effort by simplifying resource-management. We proposed to develop a policy-based management infrastructure that automates administrative tasks by executing policies written in the "Simplified Policy Language" (SPL), a standards-based policy language. Proposal -- This proposal seeks to create a project within the Apache Software Foundation to (1) develop a policy evaluator for the SPL policy language, and (2) develop bindings between the policy evaluator and projects such as Apache Geronimo or Apache Tomcat. Background --- As computer systems become more complicated, they continue to become increasingly complex and costly to manage. Various studies have shown that the cost of managing systems often exceeds the cost of purchasing them. The goal of the Imperius project is to reduce management burden by allowing administrators to specify policies that replace manual administrative actions. Rationale -- Policy-based management is one approach to reducing the cost of systems administration. Administrators define policies that express a "management intent", and the policy-based management system executes the policy, thereby reducing the burden on the administrator. For example, a policy might state "backup the database daily at 1am." A policy management system would interpret the policy, and trigger the database to perform a backup at the assigned time, offloading that task from the administrator. To allow more flexible semantics, such policies are often expressed as "If-Then" (also called "Condition-Action") rules. For example, "If the packet comes from subnet 6.7.8.*, Then place it on the high-priority outgoing queue" or "If the data in the database have changed by 10%, Then perform an incremental backup." Such policies allow for more complex automation. To implement these kinds of rule-based policies, the policy system must interact with the system's APIs. In the second example above, the system relies on the ability to measure the percentage of data that have changed since the last backup (or to compute that value from measurable data). Similarly, to execute the "then" clause, the policy system must be able to start an incremental backup on the database using the database's API. Expressed generally, a policy system must have a binding to the "instrumentation layer" or API for the system under management. Thus, policy systems consist of two major components: an evaluation engine and a binding to an instrumentation environment. The evaluation engine (1) accepts policies expressed according to a well-defined grammar, (2) collects the data needed to evaluate the policies, and (3) actuates the "Then" section as appropriate. This project would build an SPL evaluation engine and bindings to various Apache and non-Apache APIs. The design of SPL, a Preliminary DMTF standard, is inspired by existing policy languages and models including PDL (policy definition language) from Bell Laboratories, the Ponder policy language from Imperial College, and other policy languages. The basic unit of a SPL policy is a policy rule. An SPL policy rule consists of a condition, an action, and other fields. Multiple policy rules can be grouped into a policy group. Policy groups can be nested -- i.e., a policy group can contain another policy group. For the specification of the policy condition, SPL provides a rich set of operators that act on the following types: signed and unsigned short, regular and long integers, float and long float, character, string, Boolean, and calendar. We expect the community to develop a number of bindings between the evaluation engine and APIs. Examples include the API for Geronimo or Tomcat, and standard interfaces such as WSDM and CIM. The community may choose to develop a wide range of bindings, all leveraging the common SPL engine and policy syntax. The Imperius Policy Engine will be implemented in the form of a Java application. The SPL application will provide the following functionality: 1. PolicyManager - The PolicyManager acts as an orchestrator delegating tasks to its subcomponents. 2. PolicyDataStore - The PolicyDataStore is responsible for two major tasks: Policy Storage and the creation of Internal Policy Objects: a. Policy Storage: This involve
Re: Field of use constraint on OSOA license?
On Sunday 30 September 2007 01:53, Jeremy Boynes wrote: > The recent Tuscany distribution contains XSDs licensed under the OSOA > license[1] which contains the following: > "Permission to copy, make derivative works of, and distribute the > Service Component Architecture > JavaDoc, Interface Definition Files and XSD files in any medium > without fee or royalty as part > of a compliant implementation of the Service Component Architecture > Specification is hereby granted." > > Is the restriction to a "compliant implementation" a field of use > constraint that Tuscany project should be concerned about? Perhaps it is more of a matter for the legal-discuss@ list than here... But, I agree with Roland that this is not FoU restrictions. I find the formulation a bit odd, but think the intent is to ensure that the spec doesn't "evolve" beyond the control of OSOA. Especially since it mentions "Permission to ... make derivative works of ... Interface Definition Files". IANAL, -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta [was: Effects on corporate backing withdrawals [was: Incubator Proposal: Pig]]
On Sunday 30 September 2007 01:19, Roland Weber wrote: > The new HttpComponents as well > as the old HttpClient we maintain are being used by Apache > projects, so coming into the Incubator is not an option for > HttpComponents. I agree. And typically, TLPs receive somewhat more exposure than sub-projects and a better chance of building a stronger community. I don't know what to suggest, but perhaps recruiting one or more veteran ASFer, either just off the member's list or some experienced Incubator mentor, feeling this being important could just join the PMC and at least ensure process with 3 pairs of eye balls. It sounds to me there should be such interest... Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Field of use constraint on OSOA license?
Folks, At present, I believe that the OSOA SCA specifications do not contain any actual conformance statements that would allow anyone to judge whether an implementation is compliant or not. As a result, this restriction is somewhat moot. As a result, I don't consider this restriction of great concern to Tuscany. The situation is likely to be very different when it comes to the OASIS versions of the SCA specifications. OASIS requires conformance statements and the OASIS SCA TCs have charters which not only require the creation of conformance statements in the specifications but also require the creation of Test Suites for each of the specs. In this respect, the OASIS SCA specifications will be closer to the JCP JSR process, which requires a test suite to be created alongside the specifications. Folks who have views on conformance and test suites for SCA are welcome to submit their ideas to the relevant OASIS SCA TCs. Yours, Mike. Jeremy Boynes wrote: The recent Tuscany distribution contains XSDs licensed under the OSOA license[1] which contains the following: "Permission to copy, make derivative works of, and distribute the Service Component Architecture JavaDoc, Interface Definition Files and XSD files in any medium without fee or royalty as part of a compliant implementation of the Service Component Architecture Specification is hereby granted." Is the restriction to a "compliant implementation" a field of use constraint that Tuscany project should be concerned about? -- Jeremy [1] http://www.osoa.org/xmlns/sca/1.0/license.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
