Re: Mailing list search
Bump. On 25 October 2013 20:58, Noah Slater nsla...@apache.org wrote: Hi, Mailing list search on our site still points to the incubator: http://cloudstack.apache.org/mailing-lists.html I recall discussing this in the past with someone and was asked to hold back, as the Incubator lists still had most of the traffic. Is it time we switched this over? Thanks, -- Noah Slater https://twitter.com/nslater -- Noah Slater https://twitter.com/nslater
Mailing list search
Hi, Mailing list search on our site still points to the incubator: http://cloudstack.apache.org/mailing-lists.html I recall discussing this in the past with someone and was asked to hold back, as the Incubator lists still had most of the traffic. Is it time we switched this over? Thanks, -- Noah Slater https://twitter.com/nslater
Re: [VOTE] Minor edits to the by-laws
No. Thanks. I will abort this vote. I actually have another substantive change to make, but I didn't want to make it along with some stylistic changes. But I don't want to tire the list out. So I may combine them, as I am sure headers are non-controversial. On 16 August 2013 07:44, Daan Hoogland daan.hoogl...@gmail.com wrote: Noah, You use the same two-hash indent for two digit paragraph numbers as for three digit paragraph numbers. Is this intentional? regards, Daan On Fri, Aug 16, 2013 at 6:55 AM, Hugo Trippaers htrippa...@schubergphilis.com wrote: +1 Cheers, Hugo Sent from my iPhone On 16 aug. 2013, at 01:06, Noah Slater nsla...@apache.org wrote: Devs, Got some more cosmetic edits to make. :) I noticed that our by-laws look pretty crapy at the moment, as we're not actually marking up the headers properly. cf. http://cloudstack.apache.org/bylaws.html Per the by-laws, we're using a lazy majority for this vote. Please cast your vote now. I will tally the results in 72 hours. Here's my changelog: * Use proper headings Here's my patch: Index: bylaws.mdtext === --- bylaws.mdtext (revision 1514527) +++ bylaws.mdtext (working copy) @@ -22,7 +22,7 @@ responsibilities. These roles govern what tasks an individual may perform within the project. The roles are defined in the following sections: -2.1. Users +## 2.1. Users The most important participants in the project are people who use our software. Users can contribute to the Apache projects by providing feedback to developers @@ -31,7 +31,7 @@ user support forums. Users who participate in the project through any mechanism are considered to be Contributors. -2.2. Contributors +## 2.2. Contributors Contributors are all of the volunteers who are contributing time, code, documentation, or resources to the CloudStack Project. Contributions are not @@ -44,7 +44,7 @@ invited to become a Committer by the PMC. The invitation will be at the discretion of a supporting PMC member. -2.3. Committers +## 2.3. Committers The project's Committers are responsible for the project's technical management. Committers have access to all project source control repositories. @@ -62,7 +62,7 @@ 2.3.3. A Committer who makes a sustained contribution to the project may be invited by the PMC to become a member of the PMC, after approval of the PMC. -2.4. Project Management Committee +## 2.4. Project Management Committee The Project Management Committee (PMC) for Apache CloudStack is responsible to the board and the ASF for the management and oversight of the Apache CloudStack @@ -121,7 +121,7 @@ This section defines how voting is performed, the types of approvals, and which types of decision require which type of approval. -3.1. Voting +## 3.1. Voting 3.1.1. Decisions regarding the project are made by votes on the primary project development mailing list (dev@cloudstack.apache.org). Where necessary, PMC @@ -161,7 +161,7 @@ 3.1.5. Non-binding \-1 votes are not considered to be vetos for any decision. -3.2. Approvals +## 3.2. Approvals There are three types of approvals that can be sought. Section 3.4 describes actions and types of approvals needed for each action. @@ -175,7 +175,7 @@ 3.2.3. Lazy 2/3 Majority - Lazy 2/3 majority votes requires at least 3 binding votes and twice as many binding \+1 votes as binding \-1 votes. -3.3. Vetoes +## 3.3. Vetoes 3.3.1. Vetoes are only possible in a lazy consensus vote. @@ -189,14 +189,14 @@ veto to withdraw their veto. If a veto is not withdrawn, any action that has been vetoed must be reversed in a timely manner. -3.4. Actions +## 3.4. Actions This section describes the various actions which are undertaken within the project, the roles that have the right to start a vote on the action, the corresponding approval required for that action and those who have binding votes over the action. -3.4.1. Technical Decisions +## 3.4.1. Technical Decisions A technical decision is any decision that involves changes to the source code that we distribute in our official releases. @@ -215,7 +215,7 @@ Any user, contributor, committer, or PMC member can initiate a technical decision making process. -3.4.2. Non-Technical Decisions +## 3.4.2. Non-Technical Decisions A non-technical decisions is any decision that does not involve changes to the source code that we distribute in our official releases. @@ -235,7 +235,7 @@ Any user, contributor, committer, or PMC member can initiate a non-technical decision making process. -3.4.3. Release Plan +## 3.4.3. Release Plan Defines the timetable and work items for a release. The plan also nominates a Release Manager. @@ -245,7 +245,7 @@ Any active
[RESULTS] (Was: Re: [VOTE] Update by-laws: non-technical decisions and other minor changes)
Okay, thanks folks. 4 +1 votes, 3 of which are binding. The vote is a success. I will apply the patch. On 5 August 2013 22:43, Noah Slater nsla...@apache.org wrote: Hi dev, I have some more by-law changes to propose. This is essentially round 2 for these changes. I incorporated feedback from the last thread. Per the by-laws, we're using a lazy majority for this vote. Please cast your vote now. I will tally the results in 72 hours. Here's my changelog: * Removed some spurious nbsp; entities * Added A technical decision is any decision that involves changes to the source code that we distribute in our official releases. to § 3.4.1 (Technical Decisions). * Added discussion-lead before consensus gathering in this section. * With the improved definition, I have tightened up the wording so that technical decisions must be made on @dev. * Added § 3.4.2, Non-Technical Decisions. Non-technical decisions are defined as in the inverse of technical decisions. They can be made on whatever list is appropriate. Formal voting will use a lazy 2/3 majority. Votes cannot be vetoed. * Changed § 3.4.3. (Release Plan) to limit decisions to @dev. * Changed § 3.4.4. (Product Release) to limit decisions to @dev. * Changed § 3.4.5. (Adoption of New Codebase) to limit decisions to @dev. * Changed § 3.4.10. (Modifying Bylaws) to limit decisions to @dev. * Added an Oxford comma to the final paras of § 3.4.1. and § 3.4.2. * Section renumbering to accommodate § 3.4.2. And here's the patch: Index: bylaws.mdtext === --- bylaws.mdtext (revision 1510739) +++ bylaws.mdtext (working copy) @@ -198,41 +198,64 @@ 3.4.1. Technical Decisions +A technical decision is any decision that involves changes to the source code +that we distribute in our official releases. + Technical decisions should normally be made by the entire community using -consensusnbsp;gathering, and not through formal voting. +discussion-lead consensus gathering, and not through formal voting. -Technical decisions must be made on a project development mailing list. +Technical decisions must be made on the project development mailing list. During the consensus gathering process, technical decisions may be vetoed by any Committer with a valid reason. If a formal vote is started for a technical decision, the vote will be held as -a lazynbsp;consensusnbsp;of active committers. +a lazy consensus of active committers. -Any user, contributor, committer or PMC member can initiate a technical +Any user, contributor, committer, or PMC member can initiate a technical decision making process. -3.4.2. Release Plan +3.4.2. Non-Technical Decisions +A non-technical decisions is any decision that does not involve changes to the +source code that we distribute in our official releases. + +Non-technical decisions should normally be made by the entire community using +discussion-lead consensus-building, and not through formal voting. + +Non-technical decisions can be made on whichever project mailing list is most +appropriate. + +Non-technical decisions cannot be vetoed, but if there is strong opposition +a formal vote can be used to resolve the dispute. + +If a formal vote is started for a non-technical decision, the vote will be held +as a lazy 2/3 majority of active committers. + +Any user, contributor, committer, or PMC member can initiate a non-technical +decision making process. + +3.4.3. Release Plan + Defines the timetable and work items for a release. The plan also nominates a Release Manager. A lazy majority of active committers is required for approval. -Any active committer or PMC member may call a vote. The vote must occur on a +Any active committer or PMC member may call a vote. The vote must occur on the project development mailing list. -3.4.3. Product Release +3.4.4. Product Release When a release of one of the project's products is ready, a vote is required to accept the release as an official release of the project. Lazy Majority of active PMC members is required for approval. -Any active committer or PMC member may call a vote. The vote must occur on a +Any active committer or PMC member may call a vote. The vote must occur on the project development mailing list. -3.4.4. Adoption of New Codebase +3.4.5. Adoption of New Codebase When the codebase for an existing, released product is to be replaced with an alternative codebase. If such a vote fails to gain approval, the existing code @@ -242,10 +265,10 @@ Lazy 2/3 majority of active PMC members. -Any active committer or PMC member may call a vote. The vote must occur on a +Any active committer or PMC member may call a vote. The vote must occur on the project development mailing list. -3.4.5. New Committer +3.4.6. New Committer When a new committer is proposed for the project. @@ -254,7 +277,7
Re: [VOTE] Update by-laws: non-technical decisions and other minor changes
Thanks Hugo. Will wrap this up now! On 13 August 2013 06:30, Hugo Trippaers htrippa...@schubergphilis.comwrote: +1 Cheers, Hugo Sent from my iPhone On 12 aug. 2013, at 20:01, Noah Slater nsla...@apache.org wrote: Bumping the thread for a 3rd +1 vote from the PMC. Our by-laws stipulate we need 3 +1 PMC votes. Thanks. On 5 August 2013 22:43, Noah Slater nsla...@apache.org wrote: Hi dev, I have some more by-law changes to propose. This is essentially round 2 for these changes. I incorporated feedback from the last thread. Per the by-laws, we're using a lazy majority for this vote. Please cast your vote now. I will tally the results in 72 hours. Here's my changelog: * Removed some spurious nbsp; entities * Added A technical decision is any decision that involves changes to the source code that we distribute in our official releases. to § 3.4.1 (Technical Decisions). * Added discussion-lead before consensus gathering in this section. * With the improved definition, I have tightened up the wording so that technical decisions must be made on @dev. * Added § 3.4.2, Non-Technical Decisions. Non-technical decisions are defined as in the inverse of technical decisions. They can be made on whatever list is appropriate. Formal voting will use a lazy 2/3 majority. Votes cannot be vetoed. * Changed § 3.4.3. (Release Plan) to limit decisions to @dev. * Changed § 3.4.4. (Product Release) to limit decisions to @dev. * Changed § 3.4.5. (Adoption of New Codebase) to limit decisions to @dev. * Changed § 3.4.10. (Modifying Bylaws) to limit decisions to @dev. * Added an Oxford comma to the final paras of § 3.4.1. and § 3.4.2. * Section renumbering to accommodate § 3.4.2. And here's the patch: Index: bylaws.mdtext === --- bylaws.mdtext (revision 1510739) +++ bylaws.mdtext (working copy) @@ -198,41 +198,64 @@ 3.4.1. Technical Decisions +A technical decision is any decision that involves changes to the source code +that we distribute in our official releases. + Technical decisions should normally be made by the entire community using -consensusnbsp;gathering, and not through formal voting. +discussion-lead consensus gathering, and not through formal voting. -Technical decisions must be made on a project development mailing list. +Technical decisions must be made on the project development mailing list. During the consensus gathering process, technical decisions may be vetoed by any Committer with a valid reason. If a formal vote is started for a technical decision, the vote will be held as -a lazynbsp;consensusnbsp;of active committers. +a lazy consensus of active committers. -Any user, contributor, committer or PMC member can initiate a technical +Any user, contributor, committer, or PMC member can initiate a technical decision making process. -3.4.2. Release Plan +3.4.2. Non-Technical Decisions +A non-technical decisions is any decision that does not involve changes to the +source code that we distribute in our official releases. + +Non-technical decisions should normally be made by the entire community using +discussion-lead consensus-building, and not through formal voting. + +Non-technical decisions can be made on whichever project mailing list is most +appropriate. + +Non-technical decisions cannot be vetoed, but if there is strong opposition +a formal vote can be used to resolve the dispute. + +If a formal vote is started for a non-technical decision, the vote will be held +as a lazy 2/3 majority of active committers. + +Any user, contributor, committer, or PMC member can initiate a non-technical +decision making process. + +3.4.3. Release Plan + Defines the timetable and work items for a release. The plan also nominates a Release Manager. A lazy majority of active committers is required for approval. -Any active committer or PMC member may call a vote. The vote must occur on a +Any active committer or PMC member may call a vote. The vote must occur on the project development mailing list. -3.4.3. Product Release +3.4.4. Product Release When a release of one of the project's products is ready, a vote is required to accept the release as an official release of the project. Lazy Majority of active PMC members is required for approval. -Any active committer or PMC member may call a vote. The vote must occur on a +Any active committer or PMC member may call a vote. The vote must occur on the project development mailing list. -3.4.4. Adoption of New Codebase +3.4.5. Adoption of New Codebase When the codebase for an existing, released product is to be replaced with an alternative codebase. If such a vote fails to gain approval, the existing code @@ -242,10
[VOTE] Minor edits to the by-laws
@@ Any active PMC member may call a vote. The vote must occur on the PMC private mailing list. -3.4.7. New PMC Member +## 3.4.7. New PMC Member When a committer is proposed for the PMC. @@ -286,7 +286,7 @@ Any active PMC member may call a vote. The vote must occur on the PMC private mailing list. -3.4.8. Committer Removal +## 3.4.8. Committer Removal When removal of commit privileges is sought. Note: Such actions will also be referred to the ASF board by the PMC chair @@ -297,7 +297,7 @@ Any active PMC member may call a vote. The vote must occur on the PMC private mailing list. -3.4.9. PMC Member Removal +## 3.4.9. PMC Member Removal When removal of a PMC member is sought. Note: Such actions will also be referred to the ASF board by the PMC chair. @@ -307,7 +307,7 @@ Any active PMC member may call a vote. The vote must occur on the PMC private mailing list. -3.4.10. Modifying Bylaws +## 3.4.10. Modifying Bylaws Modifying this document. @@ -316,7 +316,7 @@ Any active committer or PMC member may call a vote. The vote must occur on the project development mailing list. -3.5. Voting Timeframes +## 3.5. Voting Timeframes Formal votes are open for a period of at least 72 hours to allow all active voters time to consider the vote. -- Noah Slater https://twitter.com/nslater
[RESULTS] (Was: Re: [VOTE] Update by-laws: non-technical decisions and other minor changes)
3 +1 votes, and the vote passes. I will update the by-laws now. Thanks! On 6 August 2013 20:06, Musayev, Ilya imusa...@webmd.net wrote: +1 -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Tuesday, August 06, 2013 1:58 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] Update by-laws: non-technical decisions and other minor changes +1 On 8/5/13 2:43 PM, Noah Slater nsla...@apache.org wrote: Hi dev, I have some more by-law changes to propose. This is essentially round 2 for these changes. I incorporated feedback from the last thread. Per the by-laws, we're using a lazy majority for this vote. Please cast your vote now. I will tally the results in 72 hours. Here's my changelog: * Removed some spurious nbsp; entities * Added A technical decision is any decision that involves changes to the source code that we distribute in our official releases. to § 3.4.1 (Technical Decisions). * Added discussion-lead before consensus gathering in this section. * With the improved definition, I have tightened up the wording so that technical decisions must be made on @dev. * Added § 3.4.2, Non-Technical Decisions. Non-technical decisions are defined as in the inverse of technical decisions. They can be made on whatever list is appropriate. Formal voting will use a lazy 2/3 majority. Votes cannot be vetoed. * Changed § 3.4.3. (Release Plan) to limit decisions to @dev. * Changed § 3.4.4. (Product Release) to limit decisions to @dev. * Changed § 3.4.5. (Adoption of New Codebase) to limit decisions to @dev. * Changed § 3.4.10. (Modifying Bylaws) to limit decisions to @dev. * Added an Oxford comma to the final paras of § 3.4.1. and § 3.4.2. * Section renumbering to accommodate § 3.4.2. And here's the patch: Index: bylaws.mdtext = == --- bylaws.mdtext (revision 1510739) +++ bylaws.mdtext (working copy) @@ -198,41 +198,64 @@ 3.4.1. Technical Decisions +A technical decision is any decision that involves changes to the +source code +that we distribute in our official releases. + Technical decisions should normally be made by the entire community using -consensusnbsp;gathering, and not through formal voting. +discussion-lead consensus gathering, and not through formal voting. -Technical decisions must be made on a project development mailing list. +Technical decisions must be made on the project development mailing list. During the consensus gathering process, technical decisions may be vetoed by any Committer with a valid reason. If a formal vote is started for a technical decision, the vote will be held as -a lazynbsp;consensusnbsp;of active committers. +a lazy consensus of active committers. -Any user, contributor, committer or PMC member can initiate a technical +Any user, contributor, committer, or PMC member can initiate a +technical decision making process. -3.4.2. Release Plan +3.4.2. Non-Technical Decisions +A non-technical decisions is any decision that does not involve +changes to the +source code that we distribute in our official releases. + +Non-technical decisions should normally be made by the entire +community using +discussion-lead consensus-building, and not through formal voting. + +Non-technical decisions can be made on whichever project mailing list +is most +appropriate. + +Non-technical decisions cannot be vetoed, but if there is strong opposition +a formal vote can be used to resolve the dispute. + +If a formal vote is started for a non-technical decision, the vote +will be held +as a lazy 2/3 majority of active committers. + +Any user, contributor, committer, or PMC member can initiate a non-technical +decision making process. + +3.4.3. Release Plan + Defines the timetable and work items for a release. The plan also nominates a Release Manager. A lazy majority of active committers is required for approval. -Any active committer or PMC member may call a vote. The vote must occur on a +Any active committer or PMC member may call a vote. The vote must +occur on the project development mailing list. -3.4.3. Product Release +3.4.4. Product Release When a release of one of the project's products is ready, a vote is required to accept the release as an official release of the project. Lazy Majority of active PMC members is required for approval. -Any active committer or PMC member may call a vote. The vote must occur on a +Any active committer or PMC member may call a vote. The vote must +occur on the project development mailing list. -3.4.4. Adoption of New Codebase +3.4.5. Adoption of New Codebase When the codebase for an existing, released product
Re: [RESULTS] (Was: Re: [VOTE] Update by-laws: non-technical decisions and other minor changes)
Ignore this. Unfortunately, we only have 2 +1 votes from the PMC. I am going to try to get a third. Sorry for the confusion. On 12 August 2013 18:55, Noah Slater nsla...@apache.org wrote: 3 +1 votes, and the vote passes. I will update the by-laws now. Thanks! On 6 August 2013 20:06, Musayev, Ilya imusa...@webmd.net wrote: +1 -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Tuesday, August 06, 2013 1:58 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] Update by-laws: non-technical decisions and other minor changes +1 On 8/5/13 2:43 PM, Noah Slater nsla...@apache.org wrote: Hi dev, I have some more by-law changes to propose. This is essentially round 2 for these changes. I incorporated feedback from the last thread. Per the by-laws, we're using a lazy majority for this vote. Please cast your vote now. I will tally the results in 72 hours. Here's my changelog: * Removed some spurious nbsp; entities * Added A technical decision is any decision that involves changes to the source code that we distribute in our official releases. to § 3.4.1 (Technical Decisions). * Added discussion-lead before consensus gathering in this section. * With the improved definition, I have tightened up the wording so that technical decisions must be made on @dev. * Added § 3.4.2, Non-Technical Decisions. Non-technical decisions are defined as in the inverse of technical decisions. They can be made on whatever list is appropriate. Formal voting will use a lazy 2/3 majority. Votes cannot be vetoed. * Changed § 3.4.3. (Release Plan) to limit decisions to @dev. * Changed § 3.4.4. (Product Release) to limit decisions to @dev. * Changed § 3.4.5. (Adoption of New Codebase) to limit decisions to @dev. * Changed § 3.4.10. (Modifying Bylaws) to limit decisions to @dev. * Added an Oxford comma to the final paras of § 3.4.1. and § 3.4.2. * Section renumbering to accommodate § 3.4.2. And here's the patch: Index: bylaws.mdtext = == --- bylaws.mdtext (revision 1510739) +++ bylaws.mdtext (working copy) @@ -198,41 +198,64 @@ 3.4.1. Technical Decisions +A technical decision is any decision that involves changes to the +source code +that we distribute in our official releases. + Technical decisions should normally be made by the entire community using -consensusnbsp;gathering, and not through formal voting. +discussion-lead consensus gathering, and not through formal voting. -Technical decisions must be made on a project development mailing list. +Technical decisions must be made on the project development mailing list. During the consensus gathering process, technical decisions may be vetoed by any Committer with a valid reason. If a formal vote is started for a technical decision, the vote will be held as -a lazynbsp;consensusnbsp;of active committers. +a lazy consensus of active committers. -Any user, contributor, committer or PMC member can initiate a technical +Any user, contributor, committer, or PMC member can initiate a +technical decision making process. -3.4.2. Release Plan +3.4.2. Non-Technical Decisions +A non-technical decisions is any decision that does not involve +changes to the +source code that we distribute in our official releases. + +Non-technical decisions should normally be made by the entire +community using +discussion-lead consensus-building, and not through formal voting. + +Non-technical decisions can be made on whichever project mailing list +is most +appropriate. + +Non-technical decisions cannot be vetoed, but if there is strong opposition +a formal vote can be used to resolve the dispute. + +If a formal vote is started for a non-technical decision, the vote +will be held +as a lazy 2/3 majority of active committers. + +Any user, contributor, committer, or PMC member can initiate a non-technical +decision making process. + +3.4.3. Release Plan + Defines the timetable and work items for a release. The plan also nominates a Release Manager. A lazy majority of active committers is required for approval. -Any active committer or PMC member may call a vote. The vote must occur on a +Any active committer or PMC member may call a vote. The vote must +occur on the project development mailing list. -3.4.3. Product Release +3.4.4. Product Release When a release of one of the project's products is ready, a vote is required to accept the release as an official release of the project. Lazy Majority of active PMC members is required for approval. -Any active committer or PMC member may call a vote. The vote must occur on a +Any active committer or PMC member may call a vote. The vote
Re: [VOTE] Update by-laws: non-technical decisions and other minor changes
Bumping the thread for a 3rd +1 vote from the PMC. Our by-laws stipulate we need 3 +1 PMC votes. Thanks. On 5 August 2013 22:43, Noah Slater nsla...@apache.org wrote: Hi dev, I have some more by-law changes to propose. This is essentially round 2 for these changes. I incorporated feedback from the last thread. Per the by-laws, we're using a lazy majority for this vote. Please cast your vote now. I will tally the results in 72 hours. Here's my changelog: * Removed some spurious nbsp; entities * Added A technical decision is any decision that involves changes to the source code that we distribute in our official releases. to § 3.4.1 (Technical Decisions). * Added discussion-lead before consensus gathering in this section. * With the improved definition, I have tightened up the wording so that technical decisions must be made on @dev. * Added § 3.4.2, Non-Technical Decisions. Non-technical decisions are defined as in the inverse of technical decisions. They can be made on whatever list is appropriate. Formal voting will use a lazy 2/3 majority. Votes cannot be vetoed. * Changed § 3.4.3. (Release Plan) to limit decisions to @dev. * Changed § 3.4.4. (Product Release) to limit decisions to @dev. * Changed § 3.4.5. (Adoption of New Codebase) to limit decisions to @dev. * Changed § 3.4.10. (Modifying Bylaws) to limit decisions to @dev. * Added an Oxford comma to the final paras of § 3.4.1. and § 3.4.2. * Section renumbering to accommodate § 3.4.2. And here's the patch: Index: bylaws.mdtext === --- bylaws.mdtext (revision 1510739) +++ bylaws.mdtext (working copy) @@ -198,41 +198,64 @@ 3.4.1. Technical Decisions +A technical decision is any decision that involves changes to the source code +that we distribute in our official releases. + Technical decisions should normally be made by the entire community using -consensusnbsp;gathering, and not through formal voting. +discussion-lead consensus gathering, and not through formal voting. -Technical decisions must be made on a project development mailing list. +Technical decisions must be made on the project development mailing list. During the consensus gathering process, technical decisions may be vetoed by any Committer with a valid reason. If a formal vote is started for a technical decision, the vote will be held as -a lazynbsp;consensusnbsp;of active committers. +a lazy consensus of active committers. -Any user, contributor, committer or PMC member can initiate a technical +Any user, contributor, committer, or PMC member can initiate a technical decision making process. -3.4.2. Release Plan +3.4.2. Non-Technical Decisions +A non-technical decisions is any decision that does not involve changes to the +source code that we distribute in our official releases. + +Non-technical decisions should normally be made by the entire community using +discussion-lead consensus-building, and not through formal voting. + +Non-technical decisions can be made on whichever project mailing list is most +appropriate. + +Non-technical decisions cannot be vetoed, but if there is strong opposition +a formal vote can be used to resolve the dispute. + +If a formal vote is started for a non-technical decision, the vote will be held +as a lazy 2/3 majority of active committers. + +Any user, contributor, committer, or PMC member can initiate a non-technical +decision making process. + +3.4.3. Release Plan + Defines the timetable and work items for a release. The plan also nominates a Release Manager. A lazy majority of active committers is required for approval. -Any active committer or PMC member may call a vote. The vote must occur on a +Any active committer or PMC member may call a vote. The vote must occur on the project development mailing list. -3.4.3. Product Release +3.4.4. Product Release When a release of one of the project's products is ready, a vote is required to accept the release as an official release of the project. Lazy Majority of active PMC members is required for approval. -Any active committer or PMC member may call a vote. The vote must occur on a +Any active committer or PMC member may call a vote. The vote must occur on the project development mailing list. -3.4.4. Adoption of New Codebase +3.4.5. Adoption of New Codebase When the codebase for an existing, released product is to be replaced with an alternative codebase. If such a vote fails to gain approval, the existing code @@ -242,10 +265,10 @@ Lazy 2/3 majority of active PMC members. -Any active committer or PMC member may call a vote. The vote must occur on a +Any active committer or PMC member may call a vote. The vote must occur on the project development mailing list. -3.4.5. New Committer +3.4.6. New Committer When a new committer is proposed for the project. @@ -254,7 +277,7
[RESULTS] (Was: Re: [VOTE] Whitespace changes to bylaws.mdtext)
We got 4 +1 votes, so the vote was successful. I'll make the changes now. Thanks peeps! On 29 July 2013 22:55, Noah Slater nsla...@apache.org wrote: Hi, I'd like to make several changes to our by-laws, but before I continue, I've prepared a changset that tidies up whitespace and hard wraps. This will make it easier to edit. The only non-whitespace change my patch makes is to correct two spelling errors: Transparancy - Transparency desicion - decision I am hoping this is a non-contentious change and can get the requisite 3 +1 votes. :) Per the by-laws, this is a lazy majority vote, and will be open for 72 hours. We need 3 +1 votes to pass, and more +1 votes than -1 votes. See the end of this email for the full patch. (Our ML does not allow attachments. And I want the change to be concretely tied to the votes.) Thanks, -- NS Index: bylaws.mdtext === --- bylaws.mdtext (revision 1508205) +++ bylaws.mdtext (working copy) @@ -1,6 +1,6 @@ Title: Apache CloudStack Project Bylaws -#1. Introduction +# 1. Introduction 1.1. This document defines the bylaws under which the Apache CloudStack project operates. It defines the roles and responsibilities of the project, who may @@ -13,26 +13,23 @@ operation and background of the foundation. 1.3. CloudStack operates under a set of principles known collectively as the -Apache Way. Those principles are: Transparancy, consensus, non-affiliation, +Apache Way. Those principles are: Transparency, consensus, non-affiliation, respect for fellow developers, and meritocracy, in no specific order. -#2. Roles and Responsibilities +# 2. Roles and Responsibilities Apache projects define a set of roles with associated rights and -responsibilities. These roles govern what tasks an individual may perform within -the project. The roles are defined in the following sections: +responsibilities. These roles govern what tasks an individual may perform +within the project. The roles are defined in the following sections: 2.1. Users The most important participants in the project are people who use our software. -Users can contribute to the Apache projects by providing feedback to -developers in -the form of bug reports and feature suggestions. As well, users can -participate in -the Apache community by helping other users on mailing lists and user support -forums. Users who participate in the project through any mechanism are -considered -to be Contributors. +Users can contribute to the Apache projects by providing feedback to developers +in the form of bug reports and feature suggestions. As well, users can +participate in the Apache community by helping other users on mailing lists and +user support forums. Users who participate in the project through any mechanism +are considered to be Contributors. 2.2. Contributors @@ -49,10 +46,10 @@ 2.3. Committers -The project's Committers are responsible for the project's technical management. -Committers have access to all project source control repositories. Committers -may cast binding votes on any technical discussion regarding the project (or any -sub-project). +The project's Committers are responsible for the project's technical +management. Committers have access to all project source control repositories. +Committers may cast binding votes on any technical discussion regarding the +project (or any sub-project). 2.3.1. Committer access is by invitation only and must be approved by a lazy consensus of the active PMC members. @@ -105,22 +102,21 @@ board quarterly on developments within the CloudStack project. The chair must be an active PMC member. -2.4.5. If the current chair of the PMC resigns, or the term of the -current chair expires, the PMC will attempt to reach consensus on a new -chair through discussion, confirming that consensus via a vote to -recommend a new chair using a lazy 2/3 majority voting method. -In the case that consensus is not achieved, the PMC -will vote for a chair using Single Transferable Vote (STV) voting. -Due to the fact that the discussions are about specific individuals, -this vote would be held on the cloudstack-private mailing list. -The decision must be ratified by the Apache board. +2.4.5. If the current chair of the PMC resigns, or the term of the current +chair expires, the PMC will attempt to reach consensus on a new chair through +discussion, confirming that consensus via a vote to recommend a new chair using +a lazy 2/3 majority voting method. In the case that consensus is not achieved, +the PMC will vote for a chair using Single Transferable Vote (STV) voting. Due +to the fact that the discussions are about specific individuals, this vote +would be held on the cloudstack-private mailing list. The decision must be +ratified by the Apache board. -2.4.6. The role of PMC chair will have a one year
[VOTE] Update by-laws: non-technical decisions and other minor changes
private mailing list. -3.4.7. Committer Removal +3.4.8. Committer Removal When removal of commit privileges is sought. Note: Such actions will also be referred to the ASF board by the PMC chair @@ -274,7 +297,7 @@ Any active PMC member may call a vote. The vote must occur on the PMC private mailing list. -3.4.8. PMC Member Removal +3.4.9. PMC Member Removal When removal of a PMC member is sought. Note: Such actions will also be referred to the ASF board by the PMC chair. @@ -284,13 +307,13 @@ Any active PMC member may call a vote. The vote must occur on the PMC private mailing list. -3.4.9. Modifying Bylaws +3.4.10. Modifying Bylaws Modifying this document. Lazy majority of active PMC members -Any active committer or PMC member may call a vote. The vote must occur on a +Any active committer or PMC member may call a vote. The vote must occur on the project development mailing list. 3.5. Voting Timeframes -- Noah Slater https://twitter.com/nslater
[VOTE] Whitespace changes to bylaws.mdtext
Hi, I'd like to make several changes to our by-laws, but before I continue, I've prepared a changset that tidies up whitespace and hard wraps. This will make it easier to edit. The only non-whitespace change my patch makes is to correct two spelling errors: Transparancy - Transparency desicion - decision I am hoping this is a non-contentious change and can get the requisite 3 +1 votes. :) Per the by-laws, this is a lazy majority vote, and will be open for 72 hours. We need 3 +1 votes to pass, and more +1 votes than -1 votes. See the end of this email for the full patch. (Our ML does not allow attachments. And I want the change to be concretely tied to the votes.) Thanks, -- NS Index: bylaws.mdtext === --- bylaws.mdtext (revision 1508205) +++ bylaws.mdtext (working copy) @@ -1,6 +1,6 @@ Title: Apache CloudStack Project Bylaws -#1. Introduction +# 1. Introduction 1.1. This document defines the bylaws under which the Apache CloudStack project operates. It defines the roles and responsibilities of the project, who may @@ -13,26 +13,23 @@ operation and background of the foundation. 1.3. CloudStack operates under a set of principles known collectively as the -Apache Way. Those principles are: Transparancy, consensus, non-affiliation, +Apache Way. Those principles are: Transparency, consensus, non-affiliation, respect for fellow developers, and meritocracy, in no specific order. -#2. Roles and Responsibilities +# 2. Roles and Responsibilities Apache projects define a set of roles with associated rights and -responsibilities. These roles govern what tasks an individual may perform within -the project. The roles are defined in the following sections: +responsibilities. These roles govern what tasks an individual may perform +within the project. The roles are defined in the following sections: 2.1. Users The most important participants in the project are people who use our software. -Users can contribute to the Apache projects by providing feedback to -developers in -the form of bug reports and feature suggestions. As well, users can -participate in -the Apache community by helping other users on mailing lists and user support -forums. Users who participate in the project through any mechanism are -considered -to be Contributors. +Users can contribute to the Apache projects by providing feedback to developers +in the form of bug reports and feature suggestions. As well, users can +participate in the Apache community by helping other users on mailing lists and +user support forums. Users who participate in the project through any mechanism +are considered to be Contributors. 2.2. Contributors @@ -49,10 +46,10 @@ 2.3. Committers -The project's Committers are responsible for the project's technical management. -Committers have access to all project source control repositories. Committers -may cast binding votes on any technical discussion regarding the project (or any -sub-project). +The project's Committers are responsible for the project's technical +management. Committers have access to all project source control repositories. +Committers may cast binding votes on any technical discussion regarding the +project (or any sub-project). 2.3.1. Committer access is by invitation only and must be approved by a lazy consensus of the active PMC members. @@ -105,22 +102,21 @@ board quarterly on developments within the CloudStack project. The chair must be an active PMC member. -2.4.5. If the current chair of the PMC resigns, or the term of the -current chair expires, the PMC will attempt to reach consensus on a new -chair through discussion, confirming that consensus via a vote to -recommend a new chair using a lazy 2/3 majority voting method. -In the case that consensus is not achieved, the PMC -will vote for a chair using Single Transferable Vote (STV) voting. -Due to the fact that the discussions are about specific individuals, -this vote would be held on the cloudstack-private mailing list. -The decision must be ratified by the Apache board. +2.4.5. If the current chair of the PMC resigns, or the term of the current +chair expires, the PMC will attempt to reach consensus on a new chair through +discussion, confirming that consensus via a vote to recommend a new chair using +a lazy 2/3 majority voting method. In the case that consensus is not achieved, +the PMC will vote for a chair using Single Transferable Vote (STV) voting. Due +to the fact that the discussions are about specific individuals, this vote +would be held on the cloudstack-private mailing list. The decision must be +ratified by the Apache board. -2.4.6. The role of PMC chair will have a one year term. The intention -of this term is to allow for a rotation of the role amongst the PMC -members. This intention does not prohibit the PMC from selecting the -same chair to serve consecutive terms. +2.4.6. The role of PMC chair will have a one year term. The
Re: [DISCUSS] Bylaw changes for new committer / new PMC member votes
The by-laws already stipulate lazy 2/3 majority for the Chair. Chip is proposing that the same applies to committers and PMC members. I see no reason to make it any more complex than that. On 24 July 2013 18:33, Mathias Mullins mathias.mull...@citrix.com wrote: So I'm not even a committer yet, but this is an idea on how I think I would want to be voted in. For Committer - 2/3 Lazy This makes sure that at least 2 people basically nominated, and seconded and the votes were 2:1 in favor of the person coming in. For PMC - 3/4 Lazy This is the leadership of the project and there needs to be a true consensus and not just a majority to bring someone in. This allows for a higher consensus to be reached. For Chairman (I think you guys missed this one, maybe it was applied) - 3/4 Lazy with no -1 Binding Veto The PMC has to be in Consensus and there can't really be a major dissent in my thought process. Veto also requires a through explanation why. 2 cents, Matt On 7/19/13 1:27 PM, Noah Slater nsla...@apache.org wrote: Specifically, Chip is calling for us to change committer / PMC votes from lazy consensus to 2/3 majority. (That is, the vote type for that specific decision making process changes, but the vote type definitions are left alone.) On 19 July 2013 17:32, Chip Childers chip.child...@sungard.com wrote: On Fri, Jul 19, 2013 at 04:29:07PM +, Chiradeep Vittal wrote: There's several places in the by laws that call for Lazy Consensus. Are we discussing modifying all of them or just new committer votes? New committer and PMC membership. sorry, I think the email could be more clear. This is per the $subject: new committer / new PMC member votes only. On 7/19/13 9:02 PM, Chip Childers chip.child...@sungard.com wrote: As it stands now, we currently use a Lazy Consensus model (yes Noah, I know we didn't define that term correctly as of now, but I think that's a different discussion). We currently have that term defined as: Lazy Consensus - Lazy consensus requires 3 binding +1 votes and no binding -1 votes. I'd like to propose that we change the PMC and committer voting rule to use the Lazy 2/3 Majority approach defined as: Lazy 2/3 majority votes requires at least 3 binding votes and twice as many binding +1 votes as binding -1 votes. Are there any objections to me starting a VOTE on this change? -- NS -- NS
Re: [VOTE] Update by-laws to add section for non-technical decision making (Was: Re: [RESULTS][SUMMARY][DISCUSS][VOTE] List CloudStack related books on the website)
Nope. Sorry. Feel free to run with it. If not, I can see about doing another vote in the next few days. On 24 July 2013 18:02, Mathias Mullins mathias.mull...@citrix.com wrote: Noah, Did you ever review / report / re-vote this? Thanks, Matt On 6/25/13 11:17 AM, Noah Slater nsla...@apache.org wrote: Thanks for the feedback, Matt. Anyone else got any feedback on this? Might cut a new vote. On 24 June 2013 05:12, Mathias Mullins mathias.mull...@citrix.com wrote: Noah, I agree that there needs to be a delineation. Here's my option on wording describing what is non-technical: +3.4.2. Non-Technical Decisions +Non-technical decisions should normally be made by the entire community using +discussion-lead consensus-building, and not through formal voting. + +Non-technical decisions are defined as a decision that do not directly affect +the code in any branch of the project. +Including coding, testing, documentation or management of the code base. + +Non-technical decisions can be made on whichever project mailing list is most +appropriate. + +Non-technical decisions cannot be vetoed, but if there is strong opposition +a formal vote can be used to resolve the dispute. + +If a formal vote is started for a non-technical decision, the vote will be held +as a lazy 2/3 majority of active committers. + +Any user, contributor, committer or PMC member can initiate a non-technical +decision making process. Matt Mullins Cloud Platforms Implementation Engineer Worldwide Cloud Services Citrix System, Inc. +1 (407) 920-1107 Office/Cell Phone matt.mull...@citrix.com On 6/20/13 11:59 AM, Noah Slater nsla...@apache.org wrote: Less terse follow up... ;) Note that our current by-laws effectively state that any technical decision needs to happen on dev@. I am just clarifying the intent. Note also that we currently do not define what a technical decision is, but it is my opinion that this is any decision which relates to the CloudStack source code. (We might want to make it a little broader than that. Open to suggestions.) Almost everything we do involves technology. Whether that is editing the website, wiki, JIRA, mailing lists, etc. That doesn't mean that those activities are technical activities or involve technical decisions. Do you think our by-laws need a section clarifying technical vs. non-technical? What should it say? On 20 June 2013 15:14, Joe Brockmeier j...@zonker.net wrote: On Thu, Jun 20, 2013, at 08:21 AM, Noah Slater wrote: Devs, I would like to call a vote on the following modification to our by-laws. This is in response to the Summary of changes: * Addition of 3.4.2. Non-Technical Decisions section. This specifies that non-technical decisions can be made on any appropriate list (i.e. marketing@) Erm. Does this mean that marketing can't make any technical decisions about the Web site, for instance? I think this needs to be better worded. Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ -- NS -- NS -- NS
Re: [VOTE] Update by-laws to add section for non-technical decision making (Was: Re: [RESULTS][SUMMARY][DISCUSS][VOTE] List CloudStack related books on the website)
Everyone is free to propose changes to the by-laws. If you want to make a patch and call a vote on it, by all means, go ahead. :) That sot of stuff is a good way to become a committer in the first place. ;) On 24 July 2013 18:34, Mathias Mullins mathias.mull...@citrix.com wrote: I'm not a committer so I don't want really to take this one on the Bylaws side. :-) Matt On 7/24/13 1:19 PM, Noah Slater nsla...@apache.org wrote: Nope. Sorry. Feel free to run with it. If not, I can see about doing another vote in the next few days. On 24 July 2013 18:02, Mathias Mullins mathias.mull...@citrix.com wrote: Noah, Did you ever review / report / re-vote this? Thanks, Matt On 6/25/13 11:17 AM, Noah Slater nsla...@apache.org wrote: Thanks for the feedback, Matt. Anyone else got any feedback on this? Might cut a new vote. On 24 June 2013 05:12, Mathias Mullins mathias.mull...@citrix.com wrote: Noah, I agree that there needs to be a delineation. Here's my option on wording describing what is non-technical: +3.4.2. Non-Technical Decisions +Non-technical decisions should normally be made by the entire community using +discussion-lead consensus-building, and not through formal voting. + +Non-technical decisions are defined as a decision that do not directly affect +the code in any branch of the project. +Including coding, testing, documentation or management of the code base. + +Non-technical decisions can be made on whichever project mailing list is most +appropriate. + +Non-technical decisions cannot be vetoed, but if there is strong opposition +a formal vote can be used to resolve the dispute. + +If a formal vote is started for a non-technical decision, the vote will be held +as a lazy 2/3 majority of active committers. + +Any user, contributor, committer or PMC member can initiate a non-technical +decision making process. Matt Mullins Cloud Platforms Implementation Engineer Worldwide Cloud Services Citrix System, Inc. +1 (407) 920-1107 Office/Cell Phone matt.mull...@citrix.com On 6/20/13 11:59 AM, Noah Slater nsla...@apache.org wrote: Less terse follow up... ;) Note that our current by-laws effectively state that any technical decision needs to happen on dev@. I am just clarifying the intent. Note also that we currently do not define what a technical decision is, but it is my opinion that this is any decision which relates to the CloudStack source code. (We might want to make it a little broader than that. Open to suggestions.) Almost everything we do involves technology. Whether that is editing the website, wiki, JIRA, mailing lists, etc. That doesn't mean that those activities are technical activities or involve technical decisions. Do you think our by-laws need a section clarifying technical vs. non-technical? What should it say? On 20 June 2013 15:14, Joe Brockmeier j...@zonker.net wrote: On Thu, Jun 20, 2013, at 08:21 AM, Noah Slater wrote: Devs, I would like to call a vote on the following modification to our by-laws. This is in response to the Summary of changes: * Addition of 3.4.2. Non-Technical Decisions section. This specifies that non-technical decisions can be made on any appropriate list (i.e. marketing@) Erm. Does this mean that marketing can't make any technical decisions about the Web site, for instance? I think this needs to be better worded. Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ -- NS -- NS -- NS -- NS
Re: [DISCUSS] Bylaw changes for new committer / new PMC member votes
Specifically, Chip is calling for us to change committer / PMC votes from lazy consensus to 2/3 majority. (That is, the vote type for that specific decision making process changes, but the vote type definitions are left alone.) On 19 July 2013 17:32, Chip Childers chip.child...@sungard.com wrote: On Fri, Jul 19, 2013 at 04:29:07PM +, Chiradeep Vittal wrote: There's several places in the by laws that call for Lazy Consensus. Are we discussing modifying all of them or just new committer votes? New committer and PMC membership. sorry, I think the email could be more clear. This is per the $subject: new committer / new PMC member votes only. On 7/19/13 9:02 PM, Chip Childers chip.child...@sungard.com wrote: As it stands now, we currently use a Lazy Consensus model (yes Noah, I know we didn't define that term correctly as of now, but I think that's a different discussion). We currently have that term defined as: Lazy Consensus - Lazy consensus requires 3 binding +1 votes and no binding -1 votes. I'd like to propose that we change the PMC and committer voting rule to use the Lazy 2/3 Majority approach defined as: Lazy 2/3 majority votes requires at least 3 binding votes and twice as many binding +1 votes as binding -1 votes. Are there any objections to me starting a VOTE on this change? -- NS
Re: [DISCUSS] Bylaw changes for new committer / new PMC member votes
Yes, ignoring our egregious mis-use of that term, I am +1 on your idea. Though, perhaps 3/4 is safer. Consensus is important, yes. But the bigger the PMC, the harder it is to achieve. And more often than not, I see no reason to block an action when a supermajority are clearly in favour of it. Let's not trade hard-nosed consensus for sclerosis. On 19 July 2013 16:32, Chip Childers chip.child...@sungard.com wrote: As it stands now, we currently use a Lazy Consensus model (yes Noah, I know we didn't define that term correctly as of now, but I think that's a different discussion). We currently have that term defined as: Lazy Consensus - Lazy consensus requires 3 binding +1 votes and no binding -1 votes. I'd like to propose that we change the PMC and committer voting rule to use the Lazy 2/3 Majority approach defined as: Lazy 2/3 majority votes requires at least 3 binding votes and twice as many binding +1 votes as binding -1 votes. Are there any objections to me starting a VOTE on this change? -- NS
Re: [VOTE] Update by-laws to add section for non-technical decision making (Was: Re: [RESULTS][SUMMARY][DISCUSS][VOTE] List CloudStack related books on the website)
Thanks for the feedback, Matt. Anyone else got any feedback on this? Might cut a new vote. On 24 June 2013 05:12, Mathias Mullins mathias.mull...@citrix.com wrote: Noah, I agree that there needs to be a delineation. Here's my option on wording describing what is non-technical: +3.4.2. Non-Technical Decisions +Non-technical decisions should normally be made by the entire community using +discussion-lead consensus-building, and not through formal voting. + +Non-technical decisions are defined as a decision that do not directly affect +the code in any branch of the project. +Including coding, testing, documentation or management of the code base. + +Non-technical decisions can be made on whichever project mailing list is most +appropriate. + +Non-technical decisions cannot be vetoed, but if there is strong opposition +a formal vote can be used to resolve the dispute. + +If a formal vote is started for a non-technical decision, the vote will be held +as a lazy 2/3 majority of active committers. + +Any user, contributor, committer or PMC member can initiate a non-technical +decision making process. Matt Mullins Cloud Platforms Implementation Engineer Worldwide Cloud Services Citrix System, Inc. +1 (407) 920-1107 Office/Cell Phone matt.mull...@citrix.com On 6/20/13 11:59 AM, Noah Slater nsla...@apache.org wrote: Less terse follow up... ;) Note that our current by-laws effectively state that any technical decision needs to happen on dev@. I am just clarifying the intent. Note also that we currently do not define what a technical decision is, but it is my opinion that this is any decision which relates to the CloudStack source code. (We might want to make it a little broader than that. Open to suggestions.) Almost everything we do involves technology. Whether that is editing the website, wiki, JIRA, mailing lists, etc. That doesn't mean that those activities are technical activities or involve technical decisions. Do you think our by-laws need a section clarifying technical vs. non-technical? What should it say? On 20 June 2013 15:14, Joe Brockmeier j...@zonker.net wrote: On Thu, Jun 20, 2013, at 08:21 AM, Noah Slater wrote: Devs, I would like to call a vote on the following modification to our by-laws. This is in response to the Summary of changes: * Addition of 3.4.2. Non-Technical Decisions section. This specifies that non-technical decisions can be made on any appropriate list (i.e. marketing@) Erm. Does this mean that marketing can't make any technical decisions about the Web site, for instance? I think this needs to be better worded. Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ -- NS -- NS
[VOTE] Update by-laws to add section for non-technical decision making (Was: Re: [RESULTS][SUMMARY][DISCUSS][VOTE] List CloudStack related books on the website)
this document. Lazy majority of active PMC members -Any active committer or PMC member may call a vote. The vote must occur on a +Any active committer or PMC member may call a vote. The vote must occur on the project development mailing list. 3.5. Voting Timeframes On 20 June 2013 13:14, Noah Slater nsla...@apache.org wrote: Sebastian, Thanks for the wrap up. I am happy with the way we proceeded here. It was a good compromise. As for the process stuff: Apache — as a community — uses discussion-lead consensus-based decision-making. (And formal voting is just one manifestation of that.) This should permeate everything we do. Every list, in other words. So the question isn't where can votes happen? (answer: everywhere Apache people exist!) but where must certain types of decision be made? I think we've established through past discussions around event organising, etc, that any sort of decision-making process in relation to marketing, the website, events, and branding, can, and probably should, happen on marketing@. There is no need to CC dev@. Any general, project-level stuff can be handled on dev@. In fact, when in doubt, do it on dev@ is a decent rule of thumb. Perhaps we have not documented that marketing@ list is a suitable forum for certain types of decision making. It would probably be a good idea to do so. (But not doing so in the short term does not make existing decisions invalid. There is plenty of evidence in the mailing list archives to demonstrate the PMC is happy with this.) As for the by-laws. I agree. I will post a patch in a few minutes. On 17 June 2013 21:05, Rohit Yadav bhais...@apache.org wrote: On Tue, Jun 18, 2013 at 12:30 AM, Chip Childers chip.child...@sungard.comwrote: Adding Rohit via his a.o address. Thanks, yes please refrain from using my old/new corporate email addresses. I'll stick to my initial vote and would propose listing the books on the wiki immediately. Cheers. On Mon, Jun 17, 2013 at 02:52:31PM -0400, Sebastien Goasguen wrote: Ilya, Rohit, Joe, Noah, I am re-sending this with you in CC to make sure you read it. Since there was little response the wiki link has been established already, but I would like to get feedback on explicitly modifying the bylaws to explain that marketing topics happen on the marketing list and that Lazy majority or Lazy 2/3 majority will be required. -sebastien On Jun 12, 2013, at 6:12 AM, Sebastien Goasguen run...@gmail.com wrote: Hi, (note only marketing@) Apologies for a belated wrap up of this important vote. Please reply in-line. [RESULTS]: +1 : 24 (Sebastien, Giles, Nguyen, Ryan, Kelly, Geoff, Roland, Alex, Nehal, Sapm4kev, Gaspare, Kelcey, José,OutbackDingo, Todd, Eric, David, Kimihiko, Radhika, Clayton, Chip, Chiradeep, Tariq, Mark) -0 : 2 (Noah, Joe also vote +0) -1: 2 (Rohit, Ilya) [SUMMARY]: Rohit would be +1 on listing in the wiki, Ilya would be +0 on listing in the wiki. So it seems that we would have unanimous consensus for listing on the wiki, even though there is a strong majority for the website. [DISCUSS]: I felt it was important to poll folks that are only on dev@ or users@and the results show that some folks who have never voted, got engaged in this VOTE. This is a very positive side effect despite the confusion that I created by bcc all lists. Our bylaws [1] do not cover votes on non-technical matters, so while we have lazy majority on this vote it seems that this situation is not covered by the bylaws. Moreover section 3.1.1 of bylaws says that decisions on the project happen on dev@, so it seems that votes even on marketing@are not allowed (unsure about this). I propose the following: 1-To move forward without having to re-cast a vote, I propose to list immediately the books on the Wiki, and inform Packt. I just created the page [2] 2- If people agree that we have a bylaw loophole, we need to modify the bylaws to allow votes on marketing@ and agree on using Lazy majority or Lazy 2/3 majority. Once we agree, I will inform users@ and dev@ and invite folks who participated in this vote to join marketing@ 3- We could then re-cast a vote to list on the website [1] http://cloudstack.apache.org/bylaws.html [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Books Ps: fwiw, I think this is overly complicated but the only way forward in the apache way. -Sebastien -- NS -- NS
Re: [VOTE] Update by-laws to add section for non-technical decision making (Was: Re: [RESULTS][SUMMARY][DISCUSS][VOTE] List CloudStack related books on the website)
Uh... [This is in response to the] quoted thread wherein Sebastian highlights that we have nothing in our by-laws to tell us how to make general non-technical decisions. On 20 June 2013 14:21, Noah Slater nsla...@apache.org wrote: Devs, I would like to call a vote on the following modification to our by-laws. This is in response to the Summary of changes: * Addition of 3.4.2. Non-Technical Decisions section. This specifies that non-technical decisions can be made on any appropriate list (i.e. marketing@) and also allows us to vote on them with lazy 2/3 majority. * Changed The vote must occur on a project development mailing list. to The vote must occur on the project development mailing list. in several places. This makes it explicit that these decisions must be made on the dev@list. * Minor rewordings, typographical changes, corrections, section renumbering, etc. (I would separate out the minor changes for a separate change, but as we're voting on each change to this file, I want to reduce voting churn.) Per the by-laws, we're using a lazy majority for this vote. Please cast your vote now. I will tally the results in 72 hours. Diff we're voting on: Index: bylaws.mdtext === --- bylaws.mdtext (revision 1494950) +++ bylaws.mdtext (working copy) @@ -203,9 +203,9 @@ 3.4.1. Technical Decisions Technical decisions should normally be made by the entire community -using consensusnbsp;gathering, and not through formal voting. +using discussion-lead consensus-building, and not through formal voting. -Technical decisions must be made on a project development mailing list. +Technical decisions must be made on the project development mailing list. During the consensus gathering process, technical decisions may be vetoed by any Committer with a valid reason. @@ -213,30 +213,47 @@ If a formal vote is started for a technical decision, the vote will be held as a lazynbsp;consensusnbsp;of active committers. -Any user, contributor, committer or PMC member can initiate a technical desicion +Any user, contributor, committer or PMC member can initiate a technical decision making process. -3.4.2. Release Plan +3.4.2. Non-Technical Decisions +Non-technical decisions should normally be made by the entire community using +discussion-lead consensus-building, and not through formal voting. + +Non-technical decisions can be made on whichever project mailing list is most +appropriate. + +Non-technical decisions cannot be vetoed, but if there is strong opposition +a formal vote can be used to resolve the dispute. + +If a formal vote is started for a non-technical decision, the vote will be held +as a lazy 2/3 majority of active committers. + +Any user, contributor, committer or PMC member can initiate a non-technical +decision making process. + +3.4.3. Release Plan + Defines the timetable and work items for a release. The plan also nominates a Release Manager. A lazy majority of active committers is required for approval. -Any active committer or PMC member may call a vote. The vote must occur on a +Any active committer or PMC member may call a vote. The vote must occur on the project development mailing list. -3.4.3. Product Release +3.4.4. Product Release When a release of one of the project's products is ready, a vote is required to accept the release as an official release of the project. Lazy Majority of active PMC members is required for approval. -Any active committer or PMC member may call a vote. The vote must occur on a +Any active committer or PMC member may call a vote. The vote must occur on the project development mailing list. -3.4.4. Adoption of New Codebase +3.4.5. Adoption of New Codebase When the codebase for an existing, released product is to be replaced with an alternative codebase. If such a vote fails to gain approval, the existing code @@ -246,10 +263,10 @@ Lazy 2/3 majority of active PMC members. -Any active committer or PMC member may call a vote. The vote must occur on a +Any active committer or PMC member may call a vote. The vote must occur on the project development mailing list. -3.4.5. New Committer +3.4.6. New Committer When a new committer is proposed for the project. @@ -258,7 +275,7 @@ Any active PMC member may call a vote. The vote must occur on the PMC private mailing list. -3.4.6. New PMC Member +3.4.7. New PMC Member When a committer is proposed for the PMC. @@ -267,7 +284,7 @@ Any active PMC member may call a vote. The vote must occur on the PMC private mailing list. -3.4.7. Committer Removal +3.4.8. Committer Removal When removal of commit privileges is sought. Note: Such actions will also be referred to the ASF board by the PMC chair @@ -278,7 +295,7 @@ Any active PMC member may call a vote. The vote must occur on the PMC private mailing list
Re: [VOTE] Update by-laws to add section for non-technical decision making (Was: Re: [RESULTS][SUMMARY][DISCUSS][VOTE] List CloudStack related books on the website)
I don't consider a website change to be technical. On 20 June 2013 15:14, Joe Brockmeier j...@zonker.net wrote: On Thu, Jun 20, 2013, at 08:21 AM, Noah Slater wrote: Devs, I would like to call a vote on the following modification to our by-laws. This is in response to the Summary of changes: * Addition of 3.4.2. Non-Technical Decisions section. This specifies that non-technical decisions can be made on any appropriate list (i.e. marketing@) Erm. Does this mean that marketing can't make any technical decisions about the Web site, for instance? I think this needs to be better worded. Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ -- NS
Re: [VOTE] Update by-laws to add section for non-technical decision making (Was: Re: [RESULTS][SUMMARY][DISCUSS][VOTE] List CloudStack related books on the website)
Less terse follow up... ;) Note that our current by-laws effectively state that any technical decision needs to happen on dev@. I am just clarifying the intent. Note also that we currently do not define what a technical decision is, but it is my opinion that this is any decision which relates to the CloudStack source code. (We might want to make it a little broader than that. Open to suggestions.) Almost everything we do involves technology. Whether that is editing the website, wiki, JIRA, mailing lists, etc. That doesn't mean that those activities are technical activities or involve technical decisions. Do you think our by-laws need a section clarifying technical vs. non-technical? What should it say? On 20 June 2013 15:14, Joe Brockmeier j...@zonker.net wrote: On Thu, Jun 20, 2013, at 08:21 AM, Noah Slater wrote: Devs, I would like to call a vote on the following modification to our by-laws. This is in response to the Summary of changes: * Addition of 3.4.2. Non-Technical Decisions section. This specifies that non-technical decisions can be made on any appropriate list (i.e. marketing@) Erm. Does this mean that marketing can't make any technical decisions about the Web site, for instance? I think this needs to be better worded. Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ -- NS
Re: Summary of IRC meeting in #cloudstack-meeting, Wed Jun 12 17:08:56 2013
While we're talking about bot etiquette... ;) If people used #info and #action, important takeaway points would be included at the top of the email. As it is, it's a bit hard to read through the logs if you just want to get a jist. On 13 June 2013 15:56, Joe Brockmeier j...@zonker.net wrote: On Thu, Jun 13, 2013, at 04:48 AM, Daan Hoogland wrote: Reading the meeting summary, I learned about the [off] directive the hard way. Is there a irc-etiquette for dummies somewhere that handles ASFBot and other things newbees should know? There's a manual for ASFBot here: http://wilderness.apache.org/manual.html Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ -- NS
Re: Move project bylaws from the wiki to svn/published on the website?
Nice one. Thanks Chip! On 31 May 2013 17:38, Chip Childers chip.child...@sungard.com wrote: On Wed, May 22, 2013 at 11:32:58AM -0400, Chip Childers wrote: Hi all, I'd like to propose moving the project's bylaws [1] from the wiki to the project's website svn location. IMO, this will allow for a cleaner update process (easier to provide a diff of a proposed change). Any objections? I'll assume lazy consensus on this change and make it next week if nobody has a strong objection. -chip [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Apache+CloudStack+Project+Bylaws This is done now. Bylaws are now visible at: http://cloudstack.apache.org/bylaws.html Proposals to change the bylaws should now be in the form of diffs of the source file: https://svn.apache.org/repos/asf/cloudstack/site/trunk/content/bylaws.mdtext The wiki page content has been replaced with a pointer to the official source now. -- NS
Re: [VOTE] Release Apache CloudStack 4.1.0 (fifth round)
John, note that releases are majority approval, so -1 votes are not vetos. We'd only abort the vote if we failed to get three binding +1 votes, or there were more -1 votes than +1 votes. On 29 May 2013 15:09, John Burwell jburw...@basho.com wrote: -0. I don't believe we should be shipping a release with known clock sync issues (see CLOUDSTACK-2492 https://issues.apache.org/jira/browse/CLOUDSTACK-2492). Since the community voted to go forward, I will not cast a -1. However, I feel it is important to highlight operational issues that, in my view, a system such as CloudStack should never knowingly ship. -John On Wed, May 29, 2013 at 4:29 AM, Wido den Hollander w...@widodh.nl wrote: +1 (binding) Since the changes are only Deb related in this case I'm basing my vote on previous rounds. I verified the Deb packages this time and both the Management server and AWS API install cleanly now. I'm not an expert on the AWS API, but I see the Mgmt server listening on port 7080. On 05/28/2013 03:47 PM, Chip Childers wrote: Hi All, I've created a 4.1.0 release, with the following artifacts up for a vote. The changes from round 4 are related to DEB packaging, some translation strings, and a functional patch to make bridge type optional during the agent setup (for backward compatibility). Git Branch and Commit SH: https://git-wip-us.apache.org/**repos/asf?p=cloudstack.git;a=** shortlog;h=refs/heads/4.1 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.1 Commit: a5214bee99f6c5582d755c9499f7d9**9fd7b5b701 List of changes: https://git-wip-us.apache.org/**repos/asf?p=cloudstack.git;a=** blob_plain;f=CHANGES;hb=4.1 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.1 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/**dist/dev/cloudstack/4.1.0/ https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/ PGP release keys (signed using A99A5D58): https://dist.apache.org/repos/**dist/release/cloudstack/KEYS https://dist.apache.org/repos/dist/release/cloudstack/KEYS Testing instructions are here: https://cwiki.apache.org/**confluence/display/CLOUDSTACK/** Release+test+procedure https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+procedure Vote will be open for 72 hours. For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- NS
Re: [VOTE] Release Apache CloudStack 4.1.0 (fifth round)
Or that... ;) Generally, the RM is free to abort for any reason! (Though, typically, we'd expect it to be a good one.) On 29 May 2013 19:39, Chip Childers chip.child...@sungard.com wrote: On Wed, May 29, 2013 at 07:37:59PM +0100, Noah Slater wrote: John, note that releases are majority approval, so -1 votes are not vetos. We'd only abort the vote if we failed to get three binding +1 votes, or there were more -1 votes than +1 votes. Or if there was something horribly wrong that was a surprise to everyone... -- NS
Re: [VOTE] List CloudStack related books on the website
Agree with the we don't have to get this perfect right away approach. On 28 May 2013 18:17, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: +1 While I appreciate the don't-play-favorites sentiments, I do feel that we are over thinking this issue. If favoritism becomes an issue, we can revisit. At that point, I'd imagine that there would be half-a-dozen books on CloudStack and listing/not listing them won't make much difference -- so we could remove ALL books. We're not there yet. At this point in time, it is appropriate to support such efforts. -- Chiradeep On 5/27/13 1:27 AM, Sebastien Goasguen run...@gmail.com wrote: Hi, After a relatively long discussion on the marketing@ list about the Packt Book [1] I would like to call a vote. Proposal: I propose to list CloudStack related books on our website [2]. The page listing these books would contain the following disclaimer: This listing does not represent official endorsement by the Apache CloudStack project. The Apache CloudStack project does not recommend one book versus another nor does it guarantee the quality of the books. Inclusion of a book in the listing would be done via a vote on the marketing@ list. As a quick summary, alternatives to this proposal were to: 1-not do anything 2-list the books on the wiki A few of us have already expressed their opinions and discussed the possibilities. Check [1]. Vote will be open for 96 hours (To accommodate Memorial day in the USA). Reply with: [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) PS: If edits of the disclaimer are needed but that they do not change the meaning of it, the disclaimer will be modified but the vote will not be restarted. [1] http://markmail.org/thread/r4qdmbonmx6yq2uv [2] http://cloudstack.apache.org -Sebastien -- NS
Re: [DISCUSS] Should we be releasing -beta releases?
Sebastien, Nope, we don't do votes on the users@ list. That list is just for user support. Decision making happens on dev@*, and if users want to take part in that, they can subscribe. * Or marketing@, private@, and security@ On 27 May 2013 08:53, Sebastien Goasguen run...@gmail.com wrote: On May 24, 2013, at 12:26 PM, Chip Childers chip.child...@sungard.com wrote: On Tue, May 14, 2013 at 10:41:30AM -0400, Chip Childers wrote: As a way to get more user feedback on our major feature releases, what does everyone think about releasing one or two -beta releases for each major feature release? This might fall in line with some of the stated concerns about our release schedule (see [1]). I've stated a desire to be quicker about our releases (my vote was 4 months). I've also been saying quite publicly that we should never release if we know about upgrade issues (that's the cost of having actual users of our project, which I'm more than willing for us to pay). Perhaps -betaX releases would be helpful to get attention from the users to test the release (including upgrade paths). The stated assumption could be: -beta releases are not releases that can be upgraded *from*, but are intended to help support testing by end users that want to check the upcoming release against their expected feature set and upgrade path. I would see the first -beta-1 being released about 1 month after feature freeze. For example, for 4.2.0, it would be on 2013-06-30. I would only do a -beta-2 (or later) beta release if required due to testing results. I would also suggest that the -beta-* releases would *not* have any particular quality criteria (well... perhaps minimal, like blocking on issues that fundamentally make the software unstable). I'm not sure about my own proposal here, but I wanted to throw it out and see if any of you have feedback / thoughts. -chip [1] http://markmail.org/message/3ctdwor5hfbpa3vx To summarize the discussions of this thread: 1) The idea of ensuring that we get user testing of release candidates is one that most agree with. 2) Concerns were raised about the overhead of officially releasing beta releases, especially if there is any expectation that there would be an upgrade path from a -beta to an official release. I'd like to simplify this by saying that we should actually plan on announcing the start of each round of voting on RC's to the users@ list. We can get feedback from them on each round. Why don't we include users@ in the voting thread in the first place ? The entire community can vote, correct ? committers and non-committers. Asking @users for feedback make it sound a little bit like feedback is welcome but not voting. And while I don't really love having a bunch of rounds of voting, 4.1.0 has basically proven that user engagement testing the RC's is critical. I think that we might also consider (at a release manager's discretion) periodically announcing a request for testing of the feature branch's code during the QA part of our release cycles. +1 Shout if you disagree. -- NS
Re: [DISCUSS] Should we be releasing -beta releases?
Users are *by definition* people who do not vote. The minute a user votes they become a developer. ;) I agree with you that interaction with the user@ list should use inclusive language, and should call for participation in the decision-making process that happens on dev@. Daan, monitor this list for emails that start with [DISCUSS] and [VOTE]! :) On 28 May 2013 22:37, Daan Hoogland daan.hoogl...@gmail.com wrote: I am not a commiter and did not know there where things at all that I could vote on. Nice to hear. What things? How to recognise them? regards, Daan On Tue, May 28, 2013 at 11:14 PM, Sebastien Goasguen run...@gmail.com wrote: On May 28, 2013, at 2:36 PM, Noah Slater nsla...@apache.org wrote: Sebastien, Nope, we don't do votes on the users@ list. That list is just for user support. Decision making happens on dev@*, and if users want to take part in that, they can subscribe. This needs to be made clearer then, otherwise it seems that users are really second class citizens and that they are not allowed to vote. Chip's email to users@ says something like we welcome your feedback, which is different than if you want to vote, you can by registering to the dev list and casting your vote there * Or marketing@, private@, and security@ On 27 May 2013 08:53, Sebastien Goasguen run...@gmail.com wrote: On May 24, 2013, at 12:26 PM, Chip Childers chip.child...@sungard.com wrote: On Tue, May 14, 2013 at 10:41:30AM -0400, Chip Childers wrote: As a way to get more user feedback on our major feature releases, what does everyone think about releasing one or two -beta releases for each major feature release? This might fall in line with some of the stated concerns about our release schedule (see [1]). I've stated a desire to be quicker about our releases (my vote was 4 months). I've also been saying quite publicly that we should never release if we know about upgrade issues (that's the cost of having actual users of our project, which I'm more than willing for us to pay). Perhaps -betaX releases would be helpful to get attention from the users to test the release (including upgrade paths). The stated assumption could be: -beta releases are not releases that can be upgraded *from*, but are intended to help support testing by end users that want to check the upcoming release against their expected feature set and upgrade path. I would see the first -beta-1 being released about 1 month after feature freeze. For example, for 4.2.0, it would be on 2013-06-30. I would only do a -beta-2 (or later) beta release if required due to testing results. I would also suggest that the -beta-* releases would *not* have any particular quality criteria (well... perhaps minimal, like blocking on issues that fundamentally make the software unstable). I'm not sure about my own proposal here, but I wanted to throw it out and see if any of you have feedback / thoughts. -chip [1] http://markmail.org/message/3ctdwor5hfbpa3vx To summarize the discussions of this thread: 1) The idea of ensuring that we get user testing of release candidates is one that most agree with. 2) Concerns were raised about the overhead of officially releasing beta releases, especially if there is any expectation that there would be an upgrade path from a -beta to an official release. I'd like to simplify this by saying that we should actually plan on announcing the start of each round of voting on RC's to the users@list. We can get feedback from them on each round. Why don't we include users@ in the voting thread in the first place ? The entire community can vote, correct ? committers and non-committers. Asking @users for feedback make it sound a little bit like feedback is welcome but not voting. And while I don't really love having a bunch of rounds of voting, 4.1.0 has basically proven that user engagement testing the RC's is critical. I think that we might also consider (at a release manager's discretion) periodically announcing a request for testing of the feature branch's code during the QA part of our release cycles. +1 Shout if you disagree. -- NS -- NS
Re: [DISCUSS] Should we be releasing -beta releases?
Yep! Welcome! On 28 May 2013 22:56, Daan Hoogland daan.hoogl...@gmail.com wrote: wow, I obtained voting right by subscribing. Beats Verhoeven's view on the matter, the starship troopers way ;) On Tue, May 28, 2013 at 11:43 PM, Noah Slater nsla...@apache.org wrote: Users are *by definition* people who do not vote. The minute a user votes they become a developer. ;) I agree with you that interaction with the user@ list should use inclusive language, and should call for participation in the decision-making process that happens on dev@. Daan, monitor this list for emails that start with [DISCUSS] and [VOTE]! :) On 28 May 2013 22:37, Daan Hoogland daan.hoogl...@gmail.com wrote: I am not a commiter and did not know there where things at all that I could vote on. Nice to hear. What things? How to recognise them? regards, Daan On Tue, May 28, 2013 at 11:14 PM, Sebastien Goasguen run...@gmail.com wrote: On May 28, 2013, at 2:36 PM, Noah Slater nsla...@apache.org wrote: Sebastien, Nope, we don't do votes on the users@ list. That list is just for user support. Decision making happens on dev@*, and if users want to take part in that, they can subscribe. This needs to be made clearer then, otherwise it seems that users are really second class citizens and that they are not allowed to vote. Chip's email to users@ says something like we welcome your feedback, which is different than if you want to vote, you can by registering to the dev list and casting your vote there * Or marketing@, private@, and security@ On 27 May 2013 08:53, Sebastien Goasguen run...@gmail.com wrote: On May 24, 2013, at 12:26 PM, Chip Childers chip.child...@sungard.com wrote: On Tue, May 14, 2013 at 10:41:30AM -0400, Chip Childers wrote: As a way to get more user feedback on our major feature releases, what does everyone think about releasing one or two -beta releases for each major feature release? This might fall in line with some of the stated concerns about our release schedule (see [1]). I've stated a desire to be quicker about our releases (my vote was 4 months). I've also been saying quite publicly that we should never release if we know about upgrade issues (that's the cost of having actual users of our project, which I'm more than willing for us to pay). Perhaps -betaX releases would be helpful to get attention from the users to test the release (including upgrade paths). The stated assumption could be: -beta releases are not releases that can be upgraded *from*, but are intended to help support testing by end users that want to check the upcoming release against their expected feature set and upgrade path. I would see the first -beta-1 being released about 1 month after feature freeze. For example, for 4.2.0, it would be on 2013-06-30. I would only do a -beta-2 (or later) beta release if required due to testing results. I would also suggest that the -beta-* releases would *not* have any particular quality criteria (well... perhaps minimal, like blocking on issues that fundamentally make the software unstable). I'm not sure about my own proposal here, but I wanted to throw it out and see if any of you have feedback / thoughts. -chip [1] http://markmail.org/message/3ctdwor5hfbpa3vx To summarize the discussions of this thread: 1) The idea of ensuring that we get user testing of release candidates is one that most agree with. 2) Concerns were raised about the overhead of officially releasing beta releases, especially if there is any expectation that there would be an upgrade path from a -beta to an official release. I'd like to simplify this by saying that we should actually plan on announcing the start of each round of voting on RC's to the users@list. We can get feedback from them on each round. Why don't we include users@ in the voting thread in the first place ? The entire community can vote, correct ? committers and non-committers. Asking @users for feedback make it sound a little bit like feedback is welcome but not voting. And while I don't really love having a bunch of rounds of voting, 4.1.0 has basically proven that user engagement testing the RC's is critical. I think that we might also consider (at a release manager's discretion) periodically announcing a request for testing of the feature branch's code during the QA part of our release cycles. +1 Shout if you disagree. -- NS
Re: [VOTE] Release Apache CloudStack 4.1.0 (fourth round)
Is this am argument for keeping the Debian packaging in a seperate repo? cloudstack-deb, perhaps? Repositories are cheap. On Monday, 27 May 2013, Wido den Hollander wrote: Hi Chip, I'm sorry, this is a -1 again. Hiroaki found a bug in the Deb packaging again, with commit: c4d61897d93420093dfbb046502b3f**5e0d31fb9f The agent wasn't depending on nfs-common, which would cause problems for users installing and running with NFS. I also found another bug in the Deb packaging which I caused yesterday: d9084df9a9e46d663b8ef11639af52**8caab91bb5 server.xml and tomcat6.conf are both symlinks and with I listed the files in /var/lib/dpkg/info/cloudstack-**management.list it didn't show these symlinks are part of the package. Anyway, again, this is just packaging issues, code wise it works for me. Wido On 05/26/2013 04:54 PM, Chip Childers wrote: Hi All, I've created a 4.1.0 release, with the following artifacts up for a vote. The changes from round 3 are two commits related to DEB packaging. Git Branch and Commit SH: https://git-wip-us.apache.org/**repos/asf?p=cloudstack.git;a=** shortlog;h=refs/heads/4.1https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.1 Commit: db007da15290970c842c3229a11051**c20b512a65 List of changes: https://git-wip-us.apache.org/**repos/asf?p=cloudstack.git;a=** blob_plain;f=CHANGES;hb=4.1https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.1 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/**dist/dev/cloudstack/4.1.0/https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/ PGP release keys (signed using A99A5D58): https://dist.apache.org/repos/**dist/release/cloudstack/KEYShttps://dist.apache.org/repos/dist/release/cloudstack/KEYS Testing instructions are here: https://cwiki.apache.org/**confluence/display/CLOUDSTACK/** Release+test+procedurehttps://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+procedure Vote will be open for 72 hours. For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- NS
Re: [VOTE] List CloudStack related books on the website
As a committer you have a binding vote. However, our by-laws do not make it clear what sort of decision-making process we use for non-technical matters such as this. So I am not sure whether your -1 counts as a veto. On 27 May 2013 19:14, Rohit Yadav bhais...@apache.org wrote: -1 list of books etc. on website (binding, if committers are allowed to do that). The list should be on the project wiki and not on the website. Even if we have the right intention, the website should ought not be seen as platform of promoting anything other than the materials published within Apache CloudStack, which means promoting anything which means books, goodies and things of that sort. What we can do is create a wiki on things about CloudStack, which we already have and in the education/how-to section add list of books related to CloudStack or cloud computing, but on the wiki and not on the website. Cheers. On Mon, May 27, 2013 at 1:57 PM, Sebastien Goasguen run...@gmail.com wrote: Hi, After a relatively long discussion on the marketing@ list about the Packt Book [1] I would like to call a vote. Proposal: I propose to list CloudStack related books on our website [2]. The page listing these books would contain the following disclaimer: This listing does not represent official endorsement by the Apache CloudStack project. The Apache CloudStack project does not recommend one book versus another nor does it guarantee the quality of the books. Inclusion of a book in the listing would be done via a vote on the marketing@ list. As a quick summary, alternatives to this proposal were to: 1-not do anything 2-list the books on the wiki A few of us have already expressed their opinions and discussed the possibilities. Check [1]. Vote will be open for 96 hours (To accommodate Memorial day in the USA). Reply with: [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) PS: If edits of the disclaimer are needed but that they do not change the meaning of it, the disclaimer will be modified but the vote will not be restarted. [1] http://markmail.org/thread/r4qdmbonmx6yq2uv [2] http://cloudstack.apache.org -Sebastien -- NS
Re: Move project bylaws from the wiki to svn/published on the website?
+1 On 22 May 2013 16:32, Chip Childers chip.child...@sungard.com wrote: Hi all, I'd like to propose moving the project's bylaws [1] from the wiki to the project's website svn location. IMO, this will allow for a cleaner update process (easier to provide a diff of a proposed change). Any objections? I'll assume lazy consensus on this change and make it next week if nobody has a strong objection. -chip [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Apache+CloudStack+Project+Bylaws -- NS
Re: [DISCUSS] Should we be releasing -beta releases?
We need to be careful about how we approach this. A release is something that is voted on. A release candidate is something that is about to be voted on. If you you don't vote on something, it's not a release. And if you've voted on something, it's no longer a candidate. :) Two things we could do: * Vote on, and officially release, beta/alpha versions. (This comes with the overhead of the release procedure, and community fatigue of the voting/testing cycle.) * Set up easy-to-access nightlies. Link to them from a place on the dev section of the site, and make sure that people who we send there release that these are _not_ releases. On 17 May 2013 07:56, Nitin Mehta nitin.me...@citrix.com wrote: +1. Need the beta especially because folks would want to test early and crossing the last mile can take a bit of time. But hopefully its not too much of an overhead. Thanks, -Nitin On 16/05/13 7:27 AM, Musayev, Ilya imusa...@webmd.net wrote: +1, perhaps I'm late to this thread, but this makes lot of sense. Original message From: Pranav Saxena pranav.sax...@citrix.com Date: To: dev@cloudstack.apache.org,aemne...@gmail.com Subject: RE: [DISCUSS] Should we be releasing -beta releases? +1 to what Ahmad says here . Perfect reasoning . There have been many users on the list asking for some capability /feature present in CloudStack when it's actually under development in the current release. Beta release would allow them to get a feel of it . Definitely , it would help to further refine any new feature further when actually tested in a production environment . -Original Message- From: Ahmad Emneina [mailto:aemne...@gmail.com] Sent: Wednesday, May 15, 2013 12:07 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Should we be releasing -beta releases? +1 I feel this allows for users who are chomping at the bit to get a hold of feature X. Tinker with feature X, expose bugs or use case issues well before an official release. Saves on the disappointment as well. ;) On Tue, May 14, 2013 at 9:34 AM, Chip Childers chip.child...@sungard.comwrote: On Tue, May 14, 2013 at 11:59:14AM -0400, David Nalley wrote: Are you going to support upgrades from your Betas to release (and betaN to betaN+1)? If the answer is no, then there is no interest on my part. It's not better than us producing nightly builds, or highlighting jenkins builds. Perhaps doing a better job of highlighting nightly builds at key moments is the right answer to the problem I was trying to solve (more user testing of upgrades)? The beta idea comes with some overhead, and perhaps that overhead isn't worth the benefit (if there are other ways to achieve that goal). And that's why I floated the idea... to get reactions. On Tue, May 14, 2013 at 11:03 AM, Chip Childers chip.child...@sungard.com wrote: On Tue, May 14, 2013 at 03:56:36PM +0100, Daan Hoogland wrote: As a relative outsider; any branch that is not released yet is a beta release. Why make it more explicit. Wouldn't this add support burdon? Make a branch 'in beta' and appoint a guard to make sure no new feartures but only fixes go in (kind of how you are working right now) So we do that today. However, a release as a -beta will get more user attention eariler in our release cycle (at least that's my theory). We need that user attention to help us ensure that upgrades work. Daan On Tue, May 14, 2013 at 3:49 PM, Joe Brockmeier j...@zonker.net wrote: On Tue, May 14, 2013, at 09:41 AM, Chip Childers wrote: As a way to get more user feedback on our major feature releases, what does everyone think about releasing one or two -beta releases for each major feature release? Yes to beta releases. I know that users could test at any time, but we need explicit targets for users that say now is a good time to test this and give feedback. +1 Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ -- NS
Fwd: Grace Hopper Open Source Day
This sounds like a great initiative. Anyone interested in coordinating this? -- Forwarded message -- From: Jim Jagielski j...@jagunet.com Date: 17 May 2013 14:11 Subject: Grace Hopper Open Source Day To: memb...@apache.org memb...@apache.org Cc: Apache Board bo...@apache.org I am forwarding this email on behalf of Leslie Hawthorn, a co-worker of mine @ RedHat. In the spirit of GSOC, I wanted to see if there is interest within the ASF and any of its projects in the effort. -- Hello everyone, Now in its third year, the Grace Hopper Open Source Day event is seeking applications from open source projects who wish to provide mentorship in contributing to open source projects to the attendees of the Grace Hopper Celebration of Women in Computing Conference. [0] Applications close at 23:59 PM Pacific Standard Time on May 31, 2013. You can find out more about Grace Hopper Open Source Day, why you may want your project to participate in it and the benefits for participating projects and attendees in the GHOSD FAQ. [1] Please note that this activity is not sponsored by OSAS or Red Hat - it is a labor of love in my volunteer time. I thought the easiest and fastest way to reach out to the folks who participate in our many upstreams was to post a note here so that interested folk at Red Hat could forward it along. You would still need to go through the usual processes of requesting travel funding from your manager or time away if you planned to attend on your own dime. I am a member of the GHOSD planning committee and would be happy to answer any questions folks may have regarding participation once they've read through the FAQ. [0] - http://gracehopper.org [1] - http://systers.org/systers-dev/doku.php/ghc13FAQ Best, Leslie Hawthorn Community Action and Impact Open Source and Standards (OSAS) @ Red Hat -- NS
Re: Release Verification Tool - if you're interested
Wow. This is a great idea! On CouchDB we have couchdb-admin.git and we keep stuff like this in that repos. Might we want to consider something similar? (We also use it to keep email templates in, etc.) https://git-wip-us.apache.org/repos/asf?p=couchdb-admin.git On 23 April 2013 14:36, Chip Childers chip.child...@sungard.com wrote: Hi all, Going through the process of validating the RC's (and several validation rounds before announcing an RC), I got tired of manually following the steps in our release testing process [1]. Some of the steps do require that you manually work with the release, however many of the up-front steps are easily scripted. I put together a generic framework for defining and running a set of release verification instructions yesterday, including the definition of the CloudStack release verification steps as the example configuration [2]. Feel free to use it if you think it would help you (especially the RM's that may have to re-spin an RC over and over to ensure that it's right). -chip [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+procedure [2] https://github.com/chipchilders/cloudstack-release-verification-tool -- NS
Re: New Committer: Isaac Chiang
Congratulations! On 4 May 2013 13:54, Sebastien Goasguen run...@gmail.com wrote: The Project Management Committee (PMC) for Apache CloudStack has asked Isaac Chiang to become a committer and we are pleased to announce that they have accepted. Among several things, Isaac has translated the entire documentation in zh-TW almost alone. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Isaac, --Sebastien on behalf of the CloudStack PMC -- NS
Re: [DISCUSS] Authorship of translations
(Copied from elsewhere...) I've been involved in similar discussions about what to do with pull requests on GitHub, etc. I think the general consensus was that as long as there is a reasonable indication that the work was being contributed to the project, then we are okay to include it. i.e. If somebody submits a PR to the CloudStack mirror, then we can include that if we want to, without doing any other checks. But if we spot a PR on a Citrix GitHub repository, that we could apply to CloudStack, we need to contact the original author, to make sure we have permission. The key being that we must establish reasonable intent. And I think we have that in the scenario you describe. In fact, we used to have a checkbox in JIRA that you used to have to tick to indicate when you were uploading that indicated were giving permission for the project to include your work. We removed that checkbox a while ago. I believe we took that action, because there was consensus that attaching a patch established intent. As for authorship. From a legal/policy perspective, author information should be kept out of source files. There are various reasons for this. But the gist is that it can give the impression that individual people own the various bits of code. And obviously, this can discourage participation. This is why all Apache source files state copyright as The Apache Software Foundation, meaning the lot of us, i.e. shared. Now, I can appreciate that PO files might be a bit different. I took a look at a few of them, and I don't see a problem from a policy perspective, especially if these is standard meta-data, or helps the translation effort. Now understanding how translations take place, I would ask: might having the last translator name in there discourage other translators from participating? As you mention, these files are machine generated, so my guess is: no. So, I think all that remains is a stylistic question. How do we want to attribute the hard work and dedication of our translation team? I know that with code, this is often done with an Author tag in Git, or in the comment, or what have you. But there are other options. What about a THANKSfile? On Apache CouchDB, our THANKS file is actually maintained in two ways. For anything that does not come in with an Author tag in Git, we put it in the file manually. For anything in Git, we actually automate that. See: https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob_plain;f=bootstrap;hb=HEAD Grep for THANKS to see the code that updates the file. This is done when we are preparing a release artefact. Which might not work for us on CloudStack, as, presently, our release artefacts are pristine copies of our Git repository. But we might consider making a script that updates THANKS, and then checking in the changes. On 27 April 2013 01:00, David Nalley da...@gnsa.us wrote: Why don't we ask them their preference (keeping dev@ in the loop as well) --David On Fri, Apr 26, 2013 at 3:39 PM, Sebastien Goasguen run...@gmail.com wrote: On Apr 26, 2013, at 11:22 AM, David Nalley da...@gnsa.us wrote: As such - I do not see a material difference in how the projects that are already using translate.a.o and how we function. Do we bring it up to legal-discuss ? I am happy to do so. What question would we ask? I see two possible questions, let me know if that isn't the case. If the question is 'Is accepting contributions from a plethora of contributors to a project specific instance an acceptable way of doing business' I think the answer is obvious that translate.a.o does exactly that mechanism and there seem to be no issues from a process standpoint. If the question is 'Can the Transifex Apache CloudStack l10n projects serve as an official contribution point' - I personally am comfortable saying that the message is currently clear that we treat them as official. I also don't see a problem with doing so. Is this a point of contention with anyone else? Is there a problem there that I am not seeing? Is there another question? I am fine with your statements and have no questions for legal-discuss. I was merely bringing it up in the open to make sure people knew about it. The only issue left IMHO is how we ack the authors of translations in git ? -sebastien -- NS
Re: [DISCUSS] Enable GitHub pull request notification (Was: Re: GitHub pull requests (Was: Re: Github integration))
Okay, I believe consensus was established. You can track this request here: https://issues.apache.org/jira/browse/INFRA-6225 Chip, I've been privy to lots of conversations about this issue you bring up. Across quite a few foundation lists, it seems that the general feeling is that it should be clear to most people that the canonical repository is the one hosted at the ASF. Of course, if that isn't the case, and we run into problems, then we should re-evaluate our GitHub integration. On 27 April 2013 19:57, Chip Childers chip.child...@sungard.com wrote: On Apr 27, 2013, at 2:55 PM, David Nalley da...@gnsa.us wrote: On Sat, Apr 27, 2013 at 12:35 PM, Noah Slater nsla...@apache.org wrote: Devs, I would like to propose that we turn on notifications for pull requests that are made via GitHub. This will ensure that PRs are not lost between the cracks. I believe this integration is already available, and we just need to request it. You do not need to respond if you are in agreement. If there is no response in 72 hours, I will assume lazy consensus. If we reach consensus, I will start the corresponding [VOTE] thread and complete the rest of process. (Please note that when I brought this up originally, the idea had a +1 from Prasanna and Rohit. But I do not believe I stated lazy consensus So I am doing this a second time, properly. Sorry about that folks!) Thanks, I think, but am not sure, that after the first PR against a github repo that infra@ sets up forwarding rules so they end up on dev@. (I do lots of infra git work, but not github work). That said, I see there has been one, but I don't recall that coming to dev@ [1]. Regardless, my opinion is that there really isn't an option - if we are going to have a github mirror, we also need to be able to deal with the pull requests there. Ignoring folks that submit pull requests is inappropriate. Agreed, but frankly I'd consider not having a github mirror. Not sure the value, when you consider the confusion it causes WRT the canonical source repo. [1] https://github.com/apache/incubator-cloudstack/pull/1 --David -- NS
Re: [DISCUSS] Primary maintainers?
Yep, I thought so. So can we just remove this column, and have a single column then? On 3 May 2013 19:38, Animesh Chaturvedi animesh.chaturv...@citrix.comwrote: Noah I had already withdrawn auto-assignment in the same thread [1] with following comment [Animesh] +1, that is the reason Apache projects do not use @author tag. I take back my original argument of auto-assigning based on maintainers list. I did a search but did not find any community using auto-assignment. The community argument wins. Regarding removing the primary maintainers I agree that it can be dropped and just call it maintainers or other inviting name. [1] http://markmail.org/message/udidz5fsgolng2xs?q=list:org%2Eapache%2Eincubator%2Ecloudstack-dev+auto+assignment+from :Animesh+Chaturvedipage=1 -Original Message- From: Noah Slater [mailto:nsla...@apache.org] Sent: Friday, May 03, 2013 6:04 AM To: dev@cloudstack.apache.org Subject: [DISCUSS] Primary maintainers? Hi folks, While reading the meeting minutes, I found a link to: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Current+Maintai ners+Per+Component I feel concerned about the distinction between primary maintainer and secondary maintainer. I believe this could discourage contribution. So I thought I'd bring this up here so we can have a chat about it. If you had a group of maintainers, and it was obvious that this lis could be one person, or several, then you would feel like you could join it if you wanted to. It would feel like a team effort. A loose organisation of interested parties. If there is a primary maintainer, then there is a feeling that this piece of code is owned by somebody, and all you can do is perhaps assist that person. Or perhaps you need to clear everything with that person first? How does it work? (This is the reason Apache projects do not have lead developers or BFDLs. It discourages participation, and fosters a subservient permission culture where we want a do-ocracy. It's also the reason we don't put author names in source code file. We never want someone to look at something, with an idea to fix or improve it and think, oh, I better not, this isn't mine.) I took a peek through my email for additional context, and I found: On 2 April 2013 23:45, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Can I propose that whoever wants to contribute in fixing defects for a specific module add their name as maintainer of that module in component maintainer list [1]? And we update how to contribute wiki on this process . During 4.1 there are a large number of major issues that as community we ended up not addressing and given that number of unassigned issues is high % should we consider auto-assign based on the maintainers list? This is still not optimal since auto-assign will go to primary maintainer and secondary maintainers still need to pull in defects but is better than one person triaging defects. I understand the motivation behind this, but I believe the outcome of that thread was a consensus that auto-assignment does not happen in any other Apache projects, and should not happen here either. (So no need for this primary maintainer column.) -- NS -- NS
Re: [DISCUSS] Primary maintainers?
That sounds great, Animesh. Thank you! On 3 May 2013 19:59, Animesh Chaturvedi animesh.chaturv...@citrix.comwrote: Yes I will merge primary and secondary maintainers into one column. I also started a separate thread yesterday on JIRA component based filters and email subscriptions so that whoever is interested can be notified on potential opportunities to work on. When you get a chance please review and provide feedback Animesh -Original Message- From: Noah Slater [mailto:nsla...@apache.org] Sent: Friday, May 03, 2013 11:40 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Primary maintainers? Yep, I thought so. So can we just remove this column, and have a single column then? On 3 May 2013 19:38, Animesh Chaturvedi animesh.chaturv...@citrix.comwrote: Noah I had already withdrawn auto-assignment in the same thread [1] with following comment [Animesh] +1, that is the reason Apache projects do not use @author tag. I take back my original argument of auto-assigning based on maintainers list. I did a search but did not find any community using auto-assignment. The community argument wins. Regarding removing the primary maintainers I agree that it can be dropped and just call it maintainers or other inviting name. [1] http://markmail.org/message/udidz5fsgolng2xs?q=list:org%2Eapache%2Einc ubator%2Ecloudstack-dev+auto+assignment+from :Animesh+Chaturvedipage=1 -Original Message- From: Noah Slater [mailto:nsla...@apache.org] Sent: Friday, May 03, 2013 6:04 AM To: dev@cloudstack.apache.org Subject: [DISCUSS] Primary maintainers? Hi folks, While reading the meeting minutes, I found a link to: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Current+Maint ai ners+Per+Component I feel concerned about the distinction between primary maintainer and secondary maintainer. I believe this could discourage contribution. So I thought I'd bring this up here so we can have a chat about it. If you had a group of maintainers, and it was obvious that this lis could be one person, or several, then you would feel like you could join it if you wanted to. It would feel like a team effort. A loose organisation of interested parties. If there is a primary maintainer, then there is a feeling that this piece of code is owned by somebody, and all you can do is perhaps assist that person. Or perhaps you need to clear everything with that person first? How does it work? (This is the reason Apache projects do not have lead developers or BFDLs. It discourages participation, and fosters a subservient permission culture where we want a do-ocracy. It's also the reason we don't put author names in source code file. We never want someone to look at something, with an idea to fix or improve it and think, oh, I better not, this isn't mine.) I took a peek through my email for additional context, and I found: On 2 April 2013 23:45, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Can I propose that whoever wants to contribute in fixing defects for a specific module add their name as maintainer of that module in component maintainer list [1]? And we update how to contribute wiki on this process . During 4.1 there are a large number of major issues that as community we ended up not addressing and given that number of unassigned issues is high % should we consider auto-assign based on the maintainers list? This is still not optimal since auto-assign will go to primary maintainer and secondary maintainers still need to pull in defects but is better than one person triaging defects. I understand the motivation behind this, but I believe the outcome of that thread was a consensus that auto-assignment does not happen in any other Apache projects, and should not happen here either. (So no need for this primary maintainer column.) -- NS -- NS -- NS
Re: CloudStack GitHub repository
Aha, thanks! On 29 April 2013 04:28, Joe Brockmeier j...@zonker.net wrote: Noah, I opened a bug on this weeks ago, and had reported to the mailing list. https://issues.apache.org/jira/browse/INFRA-6130 On Sat, Apr 27, 2013, at 11:28 AM, Noah Slater wrote: Devs, I have requested that our GitHub repository be moved to indicate we are no longer in incubation. Follow along here: https://issues.apache.org/jira/browse/INFRA-6203 Thanks, -- NS Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ -- NS
Re: Cloudstack.org domain
Okay, thanks Prasanna! On 17 April 2013 07:44, Prasanna Santhanam t...@apache.org wrote: On Tue, Apr 16, 2013 at 02:07:45PM +0100, Noah Slater wrote: Okay, some success. Here is a mail sent to infrastruct...@apache.org: On 16 April 2013 13:44, Tony Stevenson pct...@apache.org wrote: Noah Slater wrote on Tue, Apr 16, 2013 at 01:33:39PM +0100: Hi, It recently came up on the CloudStack list that if cloudstack.orgmoves over to ASF control, we would not be able to point foo.cloudstack.org at an external VM. (Say, a committer is running a CI/build/whatever service.) Is this the case? Are there any exceptions to this? I ask not because I want to drag up old discussions for the sake of it, but because we have some ongoing trademark stuff with CouchDB, and one of the things I am planning to propose is that we move couchdb.org to ASF control. But if the above is policy, that wouldn't work. http://docs.couchdb.org/points at a third-party hosted service, for instance. And we are working on a Jenkins setup that is not on ASF hardware (because the ASF is unable to provide us with the hardware we require at this time). Could someone clarify this for me? Noah we have several instances of DNS records pointing to non-ASF hosted services. We would clearly very much prefer that we didnt have to do this, but I do not believe it is against policy. Our issue comes from the fact the machine is not under our control, and as such anyone could just add $bad-content within the apache.org namespace. At the moment, from memory, all records that point to non-ASF hardware, are still machines we control. Your asking for something above and beyond this, and I suspect if this is what the PMC wants then that would be done. But it would need to be requested, following a vote thread and that link given to us so we can see the process :) This is from a private list, but I have been granted permission to share it with this one. For those with the appropriate karma, the thread starts here: http://s.apache.org/ZLE So, if we put together a definitive plan of action for the domain, and the services we want to host / point to, along with who is operating them, and what the plan for that is, and vote on it, it looks like we can proceed. (But we should be mindful of Infra's concerns, and take them into account while drafting the proposal.) Thanks Noah. That helps clear some confusions. But I've moved jenkins.cs.o to a different namespace as was done before with docs.cs.o. jenkins.cs.o now resides at jenkins.buildacloud.org. One of the difficulties for moving our jobs to builds@ was the performance and hardware considerations. I think some infra@ folks are aware of the problems we have with having to stack up enough hardware to run tests for our system. Having a separate managed jenkins is useful for us to quickly fix problems as is often the case with automated testing. Some of the other cs.o services are managed by David and myself. David has the necessary karma within infra to look into these when things go bad. Unless others feel that the services should remain on cloudstack.org I think we have a reasonable backup plan for now. Anyone think otherwise? -- Prasanna., -- NS
CloudStack GitHub repository
Devs, I have requested that our GitHub repository be moved to indicate we are no longer in incubation. Follow along here: https://issues.apache.org/jira/browse/INFRA-6203 Thanks, -- NS
[DISCUSS] Enable GitHub pull request notification (Was: Re: GitHub pull requests (Was: Re: Github integration))
Devs, I would like to propose that we turn on notifications for pull requests that are made via GitHub. This will ensure that PRs are not lost between the cracks. I believe this integration is already available, and we just need to request it. You do not need to respond if you are in agreement. If there is no response in 72 hours, I will assume lazy consensus. If we reach consensus, I will start the corresponding [VOTE] thread and complete the rest of process. (Please note that when I brought this up originally, the idea had a +1 from Prasanna and Rohit. But I do not believe I stated lazy consensus So I am doing this a second time, properly. Sorry about that folks!) Thanks, On 7 October 2012 03:03, Noah Slater nsla...@tumbolia.org wrote: I've been talking with Paul Davis about how we can fix this situation. But no, at the moment, you cannot merge them directly in GitHub. However, while we might advocate RB as the preferred way to submit patches, I do not think we should lock out people who prefer to work within the confines of GitHub. This question is not just about should we get notifications sent. It is more about should we open this up as a supported channel for receiving contributions? On Sun, Oct 7, 2012 at 1:59 AM, Brett Porter br...@apache.org wrote: On 30/09/2012, at 2:31 AM, Noah Slater nsla...@tumbolia.org wrote: Breaking off this question: On Sat, Sep 29, 2012 at 3:50 PM, Donal Lafferty donal.laffe...@citrix.comwrote: WRT emails for all GIT pulls, wouldn't broadcasting pull requests clutter the dev mailing list? No, I don't think so. A GitHub pull request is the same as someone coming to the list and asking us to apply a patch. If they become a nuisance (what a wonderful problem to have!) we could funnel them elsewhere. PR integration on GitHub will attract a broader base of contributions from the community. My understanding of the current pull request integration is that notifications can be sent to the list, but can not be closed or interacted with on github (other than requesting the original reporter to close them, or an administrator) - so it's not really integration as much as avoiding it slipping through the cracks when someone finds the github repo. Is that still the case? Particularly with review board in place, it would seem like getting notifications of PRs is a good idea, but explicitly encouraging their use is not. - Brett -- NS -- NS
Re: CloudStack GitHub repository
Thanks, Rohit. I marked mine as a dupe! On 27 April 2013 17:30, Rohit Yadav bhais...@apache.org wrote: Thanks Noah, I've had raised an issue with infra a long time ago but that is still open: https://issues.apache.org/jira/browse/INFRA-6061 Cheers. On Sat, Apr 27, 2013 at 9:58 PM, Noah Slater nsla...@apache.org wrote: Devs, I have requested that our GitHub repository be moved to indicate we are no longer in incubation. Follow along here: https://issues.apache.org/jira/browse/INFRA-6203 Thanks, -- NS -- NS
Re: [DISCUSS] Enable GitHub pull request notification (Was: Re: GitHub pull requests (Was: Re: Github integration))
On 27 April 2013 17:35, Noah Slater nsla...@apache.org wrote: If we reach consensus, I will start the corresponding [VOTE] thread and complete the rest of process. D'oh. That's what I get for copying and pasting email templates. Edit: if we reach consensus, I will just go ahead and request the notifications. No need for a vote on something like this unless lazy consensus fails. ;) -- NS
Re: [DISCUSS] Enable GitHub pull request notification (Was: Re: GitHub pull requests (Was: Re: Github integration))
Good question, John! We will handle it the same way we handle patches that come in via JIRA, or the mailing list, or any other channel. i.e. The creation of a PR against the official mirror is seen as an indication of intent that the work be contributed to the project, as the Apache licenses quite cleverly handles the rest, so we don't have to do anything in particular. On 27 April 2013 18:05, John Burwell jburw...@basho.com wrote: Noah, How do we handle the contributor agreement/IP issues when handling code submitted through a Github PR? Thanks, -John On Sat, Apr 27, 2013 at 12:45 PM, Noah Slater nsla...@apache.org wrote: On 27 April 2013 17:35, Noah Slater nsla...@apache.org wrote: If we reach consensus, I will start the corresponding [VOTE] thread and complete the rest of process. D'oh. That's what I get for copying and pasting email templates. Edit: if we reach consensus, I will just go ahead and request the notifications. No need for a vote on something like this unless lazy consensus fails. ;) -- NS -- NS
Re: [DISCUSS] ACS Release 4 month v/s 6 month
Thanks for the great summary Animesh. Agree with Chip. Great thread. :) On 26 April 2013 01:11, Chip Childers chip.child...@sungard.com wrote: On Thu, Apr 25, 2013 at 05:02:05PM -0700, Animesh Chaturvedi wrote: Let me attempt to summarize this thread, if I missed any glaring points feel free to bring them up 4 months: Proponents (9): Chip, Alex, David, Noah, Hugo, Joe, Sebastian, Prasanna, Rohit Reasoning: * We have not given proper shot to 4 month cycle, this was just the first time. Level of automation has increased between 4.0 to 4.1 which lays groundwork for better automation * Longer feature cycle will mean more features and bigger and more complex release * Faster feedback loop to respond and address problems and shorter wait time for feature delivery 6 months: Proponents (12): Will, Animesh, Edison, Frank, Min, Ilya, Kelven, Edison, Sudha, Radhika, Nitin, Mice Reasoning: * ACS currently has heavy reliance on manual testing and majority of QA comes from 1 company. Shorter release cycle puts more dependence on timely availability of QA to keep up to quality goals * ACS release is expected to be of good quality and support upgrades. Longer QA cycle will mean more soak time and better quality. * Less overhead on release fixed cost work (release notes, generating release artifacts) * Longer cycles also provides more flexibility in schedule for individuals in defect fixing I still see there is difference of opinion and not a clear consensus with 12 out of 21 ( approx. 60%) preferring 6 months. But going by the argument of not having given proper shot to 4 month cycle I will say we can keep 4.2 as a 4 month cycle and pull in all effort to make it successful. If it turns out that we can work with 4 month schedule that's well and good otherwise we can bring this topic again based on the results of running 4 month cycle. If there is no objection I will proceed with creating 4.2 release page, dashboards etc. on Monday Thanks Animesh Well summarized, and the right way forward when there is no consensus to change is to stay the course. I'm quite happy that this didn't degenerate into a holy war [1] of sorts actually. Well debated folks. Yes, let's revisit after 4.2, and even possibly again after that. -chip [1] http://producingoss.com/en/common-pitfalls.html#holy-wars -- NS
Re: Google Summer of Code 2013 Mentor Registration
This would make a good blog post and tweet! On 9 April 2013 21:25, Sebastien Goasguen run...@gmail.com wrote: Folks, [BCC: users@] Apache Software Foundation (ASF) has been accepted has a mentoring organization for the 2013 Google Summer of Code. If you wish to be a mentor for a student to work on a CloudStack project there are several administrative steps that you will need to do: 1-Add your project idea to JIRA, using the label gsoc2013. Then add an entry in the wiki page I started: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Student+Projects 2-register on the code-awa...@apache.org list 3-Follow the email from Ulrich Stark below which tells you to register on the melange site run by Google and then inform the PMC ( priv...@cloudstack.apache.org) that you want to be a mentor. Note that all in all GSoC is a ~4months program, being a mentor will require a firm commitment to the students who may need mentorship/guidance on a daily basis. -Sebastien Begin forwarded message: From: Ulrich Stärk u...@apache.org Subject: Google Summer of Code 2013 Mentor Registration Date: April 9, 2013 10:34:01 AM EDT To: p...@apache.org Cc: code-awa...@apache.org Reply-To: priv...@cloudstack.apache.org Reply-To: code-awa...@apache.org Dear PMCs, I'm happy to announce that the ASF has made it onto the list of 177 accepted organizations for Google Summer of Code 2013! [1,2] It is now time for the mentors to sign up, so please pass this email on to your community and podlings. Mentor signup requires two steps: mentor signup in Melange and PMC acknowledgement. If you want to mentor a project in this year's SoC you will have to 1. Be an Apache committer. 2. Register with Melange and set up a profile [3]. 3. Add your username (formerly known as link_id) to [4]. This is NOT your email address but your Melange username. You can find it at the top of any page once you are logged in. 4. Request an acknowledgement from the PMC for which you want to mentor projects. Use the below template and do not forget to copy code-awa...@apache.org. 5. Once a PMC member acknowledges the request to mentor, and only then, go to [2] and click the Start a connection button. PMCs, read carefully please. We request that each mentor is acknowledged by a PMC member. This is to ensure the mentor is in good standing with the community. When you receive a request for acknowledgement, please ACK it and cc code-awa...@apache.org Cheers, Uli mentor request email template: to: private@project.apache.org cc: code-awa...@apache.org subject: GSoC 2013 mentor request for mentor name project PMC, please acknowledge my request to become a mentor for Google Summer of Code 2013 projects for Apache project. My Melange username is username. custom content [1] https://google-melange.appspot.com/gsoc/accepted_orgs/google/gsoc2013 [2] https://google-melange.appspot.com/gsoc/org/google/gsoc2013/apache [3] https://google-melange.appspot.com/gsoc/homepage/google/gsoc2013 [4] https://svn.apache.org/repos/private/committers/GsocLinkId.txt -- NS
Re: [DISCUSS] ACS Release 4 month v/s 6 month
I see where David is coming from. The longer you leave a release branch, the harder it becomes to QA, the harder it comes to test, and the harder it becomes to release. As has been mentioned already, you can think of this as a release cost. More regular releases keep complexity down, and reduce anxiety over will my feature make the next release? (Only applicable in a time-based system, like we have it.) There's also something else to consider. Releases are like the heartbeat of a project. They stimulate activity, and they are pillars around which to market the project and spread the word. Hence, they bring new contributors to the project. We should be aiming to do as many of them as possible. In fact, frequency of releases is a reasonable proxy indicator for project health. Not that that there's much difference between 4 months and 6 months. (Now, 2 years might be a different matter...) But I'm just illustrating a point here. :) I think Joe hits the nail on the head when he points out that we haven't really given it enough time to know whether 4 months is working for us. I would suggest we give it give it a while longer, and then re-evaluate. On 24 April 2013 06:30, Alex Huang alex.hu...@citrix.com wrote: I side with Dave and Chip on this one. The 4 month dev cycle has forced CloudStack to own up to its problems in planning, testing, and automation. Until that has been settled, going to a longer release cycle is actually not beneficial to this community. --Alex -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Tuesday, April 23, 2013 2:50 AM To: cloudstack-...@incubator.apache.org Subject: [DISCUSS] ACS Release 4 month v/s 6 month Folks We started discussing 4 month v/s 6 month release cycle in a another thread [1]. Since the subject of that thread was different, community may not have participated in this important discussion fully. I am are bringing this discussion to its own thread. Here is the summary so far please refer to [1] for more details. Summary of discussion: - Animesh pointed out the technical debt that we have accumulated so far needs extra time to resolve - David, Chip favor shorter release cycle of 4 month and keeping master always stable and in good quality and enhancing automation as a solution to reduce QA manual effort. A focused defect fixing activity may be needed to reduce technical debt - Will brought up several points in the discussion: He called out heavy dependence on manual QA for a release and pointed out that manual QA may not be always available to match up ACS release schedule. Release overhead for 4 month release is still high and suggest that moving to 6 month will save on release overhead and that time can be used for strengthening automation. - Joe agrees partly in release overhead being significant for major release If I missed out any important point please feel free to bring into the thread. There were some other discussion in [1] on release planning conference and chip's clarification on time based v/s feature based releases but we will not discuss those in this thread. Community has agreed to time-based release already. [1] http://markmail.org/thread/6suq2fhltdvgvcxd -- NS
Re: [DISCUSS] Making simple installs easier.
Also + for the initiative! On 23 April 2013 20:15, Chiradeep Vittal chiradeep.vit...@citrix.comwrote: On 4/21/13 3:21 PM, David Nalley da...@gnsa.us wrote: Hi folks. I've been thinking about our install process lately. We currently require folks to muck about with firewall settings, NFS settings, network configuration, etc. This makes configuration painful, our docs VERY platform specific, and easily prone to mistakes which result in failure to get things to work. Even the 'install.sh' from the 3.0.x and earlier days doesn't do enough. What I want to do is get rid of sections 2-4 of the quick install guide, and replace it with - 'run this one or two lines worth of commands' (http://s.apache.org/runbook) My natural reaction was to reach for puppet - but I am not sure that's the right answer. To do things right, I'd need several puppet modules like stdlib, puppetlabs-firewall, etc, which is a fair bit of overhread - and oh, yeah, need to install the puppet client. I think Chef is probably in a similar problem space. I don't want to resort to shell scripts of python - config management tools know the difference between apt and yum, and can still get a package installed with one declaration, same thing with firewall rules. Is something like Ansible or SaltStack a better choice?? I don't see it right now if it is, but I don't have much experience with either of those two. The all-in-one installation process I'd like to see: Install your host OS Install an meta-RPM/Deb that either (installs everything, or alternatively configures a repo - or just installs the repo and the stuff I need to install with) Run a command that activates one of these config tools - configures the machine, installs the packages I need, and gets me to the point where I'm ready to login and go through the beautiful new user gui setup stuff. I still want to keep the documentation around, it's invaluable for experienced users and more complex deployments - but right now it's far too much overhead (probably an hour or two) to get things installed and setup to the point where you are ready to run the 'Welcome to CloudStack GUI' if you just want to try CloudStack out. So why am I writing this email instead of diving in and solving this problem? Well honestly, I'd like some external opinions. I want to make sure that I am not seeing a 'nail' simply because I have a hammer in my hand. How can we most easily do this? So - how do we make the 'brand-new' user experience much better? We develop a platform for orchestration of complex systems, this should be a solved problem. --David +1 for the initiative. If I look at Apache Hadoop's single node operation documentation[1], it is considerably simpler. Apache Tomcat installation is also fairly trivial. [1] http://hadoop.apache.org/docs/stable/single_node_setup.html -- NS
Re: [DISCUSS] Making simple installs easier.
(Typo, but you can fill in any number you feel like...) On 24 April 2013 12:57, Noah Slater nsla...@apache.org wrote: Also + for the initiative! On 23 April 2013 20:15, Chiradeep Vittal chiradeep.vit...@citrix.comwrote: On 4/21/13 3:21 PM, David Nalley da...@gnsa.us wrote: Hi folks. I've been thinking about our install process lately. We currently require folks to muck about with firewall settings, NFS settings, network configuration, etc. This makes configuration painful, our docs VERY platform specific, and easily prone to mistakes which result in failure to get things to work. Even the 'install.sh' from the 3.0.x and earlier days doesn't do enough. What I want to do is get rid of sections 2-4 of the quick install guide, and replace it with - 'run this one or two lines worth of commands' (http://s.apache.org/runbook) My natural reaction was to reach for puppet - but I am not sure that's the right answer. To do things right, I'd need several puppet modules like stdlib, puppetlabs-firewall, etc, which is a fair bit of overhread - and oh, yeah, need to install the puppet client. I think Chef is probably in a similar problem space. I don't want to resort to shell scripts of python - config management tools know the difference between apt and yum, and can still get a package installed with one declaration, same thing with firewall rules. Is something like Ansible or SaltStack a better choice?? I don't see it right now if it is, but I don't have much experience with either of those two. The all-in-one installation process I'd like to see: Install your host OS Install an meta-RPM/Deb that either (installs everything, or alternatively configures a repo - or just installs the repo and the stuff I need to install with) Run a command that activates one of these config tools - configures the machine, installs the packages I need, and gets me to the point where I'm ready to login and go through the beautiful new user gui setup stuff. I still want to keep the documentation around, it's invaluable for experienced users and more complex deployments - but right now it's far too much overhead (probably an hour or two) to get things installed and setup to the point where you are ready to run the 'Welcome to CloudStack GUI' if you just want to try CloudStack out. So why am I writing this email instead of diving in and solving this problem? Well honestly, I'd like some external opinions. I want to make sure that I am not seeing a 'nail' simply because I have a hammer in my hand. How can we most easily do this? So - how do we make the 'brand-new' user experience much better? We develop a platform for orchestration of complex systems, this should be a solved problem. --David +1 for the initiative. If I look at Apache Hadoop's single node operation documentation[1], it is considerably simpler. Apache Tomcat installation is also fairly trivial. [1] http://hadoop.apache.org/docs/stable/single_node_setup.html -- NS -- NS
Re: [VOTE] Apache CloudStack 4.0.2
Yes, we have rules. :) A release will pass if it receives 3 binding +1 votes, and more +1 votes than -1 votes in total. On 17 April 2013 15:11, Marcus Sorensen shadow...@gmail.com wrote: Do we have rules set out around this? It seems that we wouldn't stop a time-based bug fix release from going out just because it doesn't fix every bug we know of, only if it introduces a bug. On Apr 17, 2013 8:09 AM, Joe Brockmeier j...@zonker.net wrote: On Wed, Apr 17, 2013, at 08:50 AM, Sebastien Goasguen wrote: Ok solved in 95f87bd96e0db0d061e37245166059d5eb7a073b But unfortunately I want to raise https://issues.apache.org/jira/browse/CLOUDSTACK-528 which is a blocker for 4.0.2 and yet still open. Nicolas emailed several times about it already . I'm aware of the issue, but as of yet no one has stepped up to fix it and we've got a slew of other issues that are in the release. Will stop the vote due to the RAT issues, and if anyone would like to step up on 528 now would be a very good time to do so. Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ -- NS
Re: [VOTE] Apache CloudStack 4.0.2
It's a little more nuanced than that. ;) It's very possible that we would ship a new release that actually introduces known bugs. It is much less likely that we would ship a release that introduces known critical bugs. In the end, it is up to the community to decide. And that is a process of a release manager making the cut, and calling the vote. And then we use our by-laws and voting rules to decide what we do! :) On 17 April 2013 15:49, Marcus Sorensen shadow...@gmail.com wrote: OK, so the answer is no, we just decide as we go... On Apr 17, 2013 8:15 AM, Chip Childers chip.child...@sungard.com wrote: On Wed, Apr 17, 2013 at 08:11:38AM -0600, Marcus Sorensen wrote: Do we have rules set out around this? It seems that we wouldn't stop a time-based bug fix release from going out just because it doesn't fix every bug we know of, only if it introduces a bug. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Apache+CloudStack+Project+Bylaws#ApacheCloudStackProjectBylaws-3.DecisionMaking Section 3.4.3. - Lazy Majority of PMC -- NS
Re: Cloudstack.org domain
I'm not sure how useful this is to you, but I just started a thread on infrastruct...@apache.org with the subject ASF DNS pointing to non-ASF machines. It happens that I am involved with another project in a similar predicament, and I would like to get some additional clarity on the policy. If there's anything that seems relevant I will loop back to this thread. On 10 April 2013 07:55, Prasanna Santhanam t...@apache.org wrote: Time to find an alternate domain for jenkins then. :( On Tue, Apr 09, 2013 at 05:40:56PM +0100, Noah Slater wrote: Ack :( On 9 April 2013 17:38, David Nalley da...@gnsa.us wrote: It was on infra-private as that was where I was told to carry the conversation when I asked in IRC. I don't think that there is any negotiation to be done, multiple infra contractors over a period of almost a year have echoed similar sentiments. --David On Tue, Apr 9, 2013 at 12:35 PM, Noah Slater nsla...@apache.org wrote: Strange this was on infra-private, and not infra (which is also private). I only subscribe to the latter. I found your message now. Disappointing. I had not realised that this was policy. (I guess undocumented.) Wonder if there's any room for negotiation... On 9 April 2013 17:21, David Nalley da...@gnsa.us wrote: On Tue, Apr 9, 2013 at 11:50 AM, Noah Slater nsla...@apache.org wrote: Do you have a link to the discussion thread, David? I can't find anything in my mail. You'll need to use your member karma, as it's on infra-private: 097901ce30c3$c69ff210$53dfd630$@16degrees.com.au -- NS -- NS -- Prasanna., -- NS
Re: Cloudstack.org domain
Okay, some success. Here is a mail sent to infrastruct...@apache.org: On 16 April 2013 13:44, Tony Stevenson pct...@apache.org wrote: Noah Slater wrote on Tue, Apr 16, 2013 at 01:33:39PM +0100: Hi, It recently came up on the CloudStack list that if cloudstack.org moves over to ASF control, we would not be able to point foo.cloudstack.org at an external VM. (Say, a committer is running a CI/build/whatever service.) Is this the case? Are there any exceptions to this? I ask not because I want to drag up old discussions for the sake of it, but because we have some ongoing trademark stuff with CouchDB, and one of the things I am planning to propose is that we move couchdb.org to ASF control. But if the above is policy, that wouldn't work. http://docs.couchdb.org/points at a third-party hosted service, for instance. And we are working on a Jenkins setup that is not on ASF hardware (because the ASF is unable to provide us with the hardware we require at this time). Could someone clarify this for me? Noah we have several instances of DNS records pointing to non-ASF hosted services. We would clearly very much prefer that we didnt have to do this, but I do not believe it is against policy. Our issue comes from the fact the machine is not under our control, and as such anyone could just add $bad-content within the apache.org namespace. At the moment, from memory, all records that point to non-ASF hardware, are still machines we control. Your asking for something above and beyond this, and I suspect if this is what the PMC wants then that would be done. But it would need to be requested, following a vote thread and that link given to us so we can see the process :) This is from a private list, but I have been granted permission to share it with this one. For those with the appropriate karma, the thread starts here: http://s.apache.org/ZLE So, if we put together a definitive plan of action for the domain, and the services we want to host / point to, along with who is operating them, and what the plan for that is, and vote on it, it looks like we can proceed. (But we should be mindful of Infra's concerns, and take them into account while drafting the proposal.) On 16 April 2013 13:34, Noah Slater nsla...@apache.org wrote: I'm not sure how useful this is to you, but I just started a thread on infrastruct...@apache.org with the subject ASF DNS pointing to non-ASF machines. It happens that I am involved with another project in a similar predicament, and I would like to get some additional clarity on the policy. If there's anything that seems relevant I will loop back to this thread. On 10 April 2013 07:55, Prasanna Santhanam t...@apache.org wrote: Time to find an alternate domain for jenkins then. :( On Tue, Apr 09, 2013 at 05:40:56PM +0100, Noah Slater wrote: Ack :( On 9 April 2013 17:38, David Nalley da...@gnsa.us wrote: It was on infra-private as that was where I was told to carry the conversation when I asked in IRC. I don't think that there is any negotiation to be done, multiple infra contractors over a period of almost a year have echoed similar sentiments. --David On Tue, Apr 9, 2013 at 12:35 PM, Noah Slater nsla...@apache.org wrote: Strange this was on infra-private, and not infra (which is also private). I only subscribe to the latter. I found your message now. Disappointing. I had not realised that this was policy. (I guess undocumented.) Wonder if there's any room for negotiation... On 9 April 2013 17:21, David Nalley da...@gnsa.us wrote: On Tue, Apr 9, 2013 at 11:50 AM, Noah Slater nsla...@apache.org wrote: Do you have a link to the discussion thread, David? I can't find anything in my mail. You'll need to use your member karma, as it's on infra-private: 097901ce30c3$c69ff210$53dfd630$@16degrees.com.au -- NS -- NS -- Prasanna., -- NS -- NS
Re: [DISCUSS] Don't assign tickets to people when triaging
On 11 April 2013 04:08, Abhinandan Prateek abhinandan.prat...@citrix.comwrote: Now is it wrong to ask the community members who have expertise on UI to fix it, in a bid to help Chip get the release out ? It is certainly not wrong to co-ordinate with people in an effort to ship a release. (I would point out, however, that it is not Chip getting the release out. It is the community. But maybe I am misinterpreting your remark here...) 2. Assign a bug that is open for more than 3 days and none of the community member has shown interest in picking it up. This period can vary depending on how close a branch where bug is noted is close to a release. Three days? That is a very short period of time, when you consider the size of our JIRA queue, and the average timespan of a ticket. I really don't see why bugs that are not on the critical path of a release should be assigned at all. As has already been pointed out several times in this thread, this is an exclusionary practice which is likely to put off new contributions to the project. It will calcify the existing structure and roles, and will hamper CloudStack's ability to grow as a project. I don't understand why non-critical bugs cannot be categorised into components. And then engineers can pick up items of the component backlogs as they become free or want to work on CloudStack. This sort of approach is inclusionary. Anybody can go to JIRA and click on one of the component reports, and just take a ticket, and start working on it. (Without having to contact the person it is assigned to to ask if they may start on it. Which, in reality, nobody is going to to do.) I also reject the idea that engineers need tickets assigned to them as either a) some sort of communication method, or b) some way to spur them into action. Firstly, we have the mailing list as a communication method. If you want a particular set of bugs to be worked on, or whatever, then post a message to the list, and ask for participation. Secondly, we should not be spurring anybody into action. This is a volunteer project, and people contribute as and when they can. They should not be managed like an employee would be managed. Which is why it's so important that we build structures that are open to chaotic volunteer efforts. If $company is employing people to work on CloudStack, and wants to spur its employees into action around a certain feature or component, then that is fine. But this activity must be kept away from the lists. Perhaps have $company internal email threads where you ask people to focus on things. Any time that activity leaks on to the list, it sends the wrong message about how to participate in the project, and sends the wrong message about $company's relationship to the project. 3. Assign or request to community for picking up a bug if it is blocking the work that a community member may be working on. Again, this is presumptuous. There is no minimum level of participation. So saying Bob, this is your bug, so fix it, because it is blocking me is the wrong attitude to take. Instead, we should be using every opportunity we have, every construct we build, as a way to invite further participation from the community. A better approach would be to mark the bug as blocking some other work, and then post a note to the list saying this bug is blocking me, can I have some help with it please? In an email like that, feel free to CC the engineers you expect might want to / be able to help out, or mention them by name. But don't make a habit of saying Bob, this bug is blocking me, can you fix it when you could say this bug is blocking me, can someone fix it? /cc Bob -- NS
Re: [DISCUSS] Don't assign tickets to people when triaging
Of course releases are important. But if our current cadence is putting too much pressure on the community, one option might be to do our releases further apart from each other. Or, we get strict about the principal of time based releases: i.e. if your feature is not ready for the freeze, then it doesn't make it in. No big deal. If it's ready for the next freeze, then we'll ship it then. Also, I may be reading your message wrong, but there's no need for this to be a divisive argument. There are no sides to this. As a community, it is up to us all to identify our problems, and figure out solutions. So what problems do you think we'll run in to if we stop assigning the majority of bugs, and how do you think we can mitigate those problems? Or do you have another idea in mind altogether? On 11 April 2013 12:40, Abhinandan Prateek abhinandan.prat...@citrix.comwrote: I think it will be good if we also find out a process so that the release cycle is not affected by unclaimed bugs sitting out there. Here I am assuming the releases are important. I guess the discussion has turned into keeping things free without offering solutions to problems that that system will create. On 11/04/13 5:04 PM, John Burwell jburw...@basho.com wrote: +1 On Apr 11, 2013, at 7:22 AM, Noah Slater nsla...@apache.org wrote: On 11 April 2013 11:22, Abhinandan Prateek abhinandan.prat...@citrix.comwrote: 7-8 days is a huge time lost. I was suggesting that this to be 3 days. Let other community members chime in too. I should have replied to this in my previous missive. But I want to reenforce how unhealthy I believe this practice is. 7-8 days, or even 3 days being a huge time loss makes absolutely no sense to me at all. Assigning a bug should not mean it gets fixed any faster. If it does, then we need to change the way we are working. (And if this means changing the JIRA ticket workflow, then so be it. If something isn't working for us, we change it.) In fact, I would go so far as to say that we should think of assigning bugs as an exclusionary practice. Every time you assign a bug, you're shutting out the community. That's how we should think about it. Assign the bug, shut out the community. And so, I would say we should try to avoid doing it, unless it is absolutely necessary. (Such as when you're co-ordinating some release critical work, or when you, yourself, are about to start work on something. Of course, it's perfectly fine to shut out the community, if you're doing that at the same time as starting work on something!) -- NS -- NS
Re: [DISCUSS] Don't assign tickets to people when triaging
I believe it is possible to mention someone in a JIRA ticket in such a way that they get notified. Might this be an effective way of CCing someone into the conversation, without prescribing who should fix it? Might there be some room for exploration here? On Thursday, 11 April 2013, Abhinandan Prateek wrote: Yes, I think we need to space our releases further apart. I had big trouble when master was unstable for a while and specially on VMware it was difficult to deploy and test features. Yes for each issue I could have shouted on mail list I saw people doing that but the fact is that instability was around for a while. Doesn't it make sense that in such scenarios we could do things in a more pro active manner. Again I donot see much difference in asking someone on Jira to pick a issue vs sending a email, but will agree to whatever the community decides here. Also community members should volunteer to own some part so that in above circumstances a person looking for some fix can approach that member, once again a suggestion. On 11-Apr-2013, at 5:17 PM, Noah Slater nsla...@apache.orgjavascript:; wrote: Of course releases are important. But if our current cadence is putting too much pressure on the community, one option might be to do our releases further apart from each other. Or, we get strict about the principal of time based releases: i.e. if your feature is not ready for the freeze, then it doesn't make it in. No big deal. If it's ready for the next freeze, then we'll ship it then. Also, I may be reading your message wrong, but there's no need for this to be a divisive argument. There are no sides to this. As a community, it is up to us all to identify our problems, and figure out solutions. So what problems do you think we'll run in to if we stop assigning the majority of bugs, and how do you think we can mitigate those problems? Or do you have another idea in mind altogether? On 11 April 2013 12:40, Abhinandan Prateek abhinandan.prat...@citrix.com javascript:;wrote: I think it will be good if we also find out a process so that the release cycle is not affected by unclaimed bugs sitting out there. Here I am assuming the releases are important. I guess the discussion has turned into keeping things free without offering solutions to problems that that system will create. On 11/04/13 5:04 PM, John Burwell jburw...@basho.com javascript:; wrote: +1 On Apr 11, 2013, at 7:22 AM, Noah Slater nsla...@apache.orgjavascript:; wrote: On 11 April 2013 11:22, Abhinandan Prateek abhinandan.prat...@citrix.com javascript:;wrote: 7-8 days is a huge time lost. I was suggesting that this to be 3 days. Let other community members chime in too. I should have replied to this in my previous missive. But I want to reenforce how unhealthy I believe this practice is. 7-8 days, or even 3 days being a huge time loss makes absolutely no sense to me at all. Assigning a bug should not mean it gets fixed any faster. If it does, then we need to change the way we are working. (And if this means changing the JIRA ticket workflow, then so be it. If something isn't working for us, we change it.) In fact, I would go so far as to say that we should think of assigning bugs as an exclusionary practice. Every time you assign a bug, you're shutting out the community. That's how we should think about it. Assign the bug, shut out the community. And so, I would say we should try to avoid doing it, unless it is absolutely necessary. (Such as when you're co-ordinating some release critical work, or when you, yourself, are about to start work on something. Of course, it's perfectly fine to shut out the community, if you're doing that at the same time as starting work on something!) -- NS -- NS -- NS
Re: [DISCUSS] Don't assign tickets to people when triaging
On 11 April 2013 15:11, Joe Brockmeier j...@zonker.net wrote: I'm against a policy of never assigning tickets, but it shouldn't be the norm for one set of folks to triage tickets and assign them to another set of folks. Me too. We should establish: a) A rule that we avoid ticket assignment by default, and b) A clear set of exceptions to that rule... -- NS
Re: [DISCUSS] Don't assign tickets to people when triaging
To me, it seems like what you're describing are components. You assign or sort the ticket into a component. Then I guess, people who are interested can watch that component for new issues. I am not sure if there's a way to watch a component in JIRA so that you get email notifications for it. I took a look, but couldn't find anything. Perhaps Infra would install a plugin for us. (I noticed that at least one such plugin exists.) At the very least, you could save a report as a favourite... On 11 April 2013 15:20, Abhinandan Prateek abhinandan.prat...@citrix.comwrote: On the Jira notification my suggestion will be to have a goto list of people for various domains of expertise. Anyone can register for these domains. When a bug is filed, the filer selects one of the domains he thinks that is right for getting the bug to be resolved. This alerts the people who have volunteered for that domain. We may take this one step future in that for each domain we can have a designated contact person who may once in a while take a look at the list of open issues in that domain and may further take action for quicker resolution. I think I had enough inputs for the day :-), Moreover the day is ending in my timezone. I guess that did bring some issues to the notice of community, I will expect other community members to think of solutions. With so many passionate members in this community I think we will arrive at a good solution that works. Kudos to the community ! On 11/04/13 7:17 PM, Noah Slater nsla...@apache.org wrote: I believe it is possible to mention someone in a JIRA ticket in such a way that they get notified. Might this be an effective way of CCing someone into the conversation, without prescribing who should fix it? Might there be some room for exploration here? On Thursday, 11 April 2013, Abhinandan Prateek wrote: Yes, I think we need to space our releases further apart. I had big trouble when master was unstable for a while and specially on VMware it was difficult to deploy and test features. Yes for each issue I could have shouted on mail list I saw people doing that but the fact is that instability was around for a while. Doesn't it make sense that in such scenarios we could do things in a more pro active manner. Again I donot see much difference in asking someone on Jira to pick a issue vs sending a email, but will agree to whatever the community decides here. Also community members should volunteer to own some part so that in above circumstances a person looking for some fix can approach that member, once again a suggestion. On 11-Apr-2013, at 5:17 PM, Noah Slater nsla...@apache.orgjavascript:; wrote: Of course releases are important. But if our current cadence is putting too much pressure on the community, one option might be to do our releases further apart from each other. Or, we get strict about the principal of time based releases: i.e. if your feature is not ready for the freeze, then it doesn't make it in. No big deal. If it's ready for the next freeze, then we'll ship it then. Also, I may be reading your message wrong, but there's no need for this to be a divisive argument. There are no sides to this. As a community, it is up to us all to identify our problems, and figure out solutions. So what problems do you think we'll run in to if we stop assigning the majority of bugs, and how do you think we can mitigate those problems? Or do you have another idea in mind altogether? On 11 April 2013 12:40, Abhinandan Prateek abhinandan.prat...@citrix.com javascript:;wrote: I think it will be good if we also find out a process so that the release cycle is not affected by unclaimed bugs sitting out there. Here I am assuming the releases are important. I guess the discussion has turned into keeping things free without offering solutions to problems that that system will create. On 11/04/13 5:04 PM, John Burwell jburw...@basho.com javascript:; wrote: +1 On Apr 11, 2013, at 7:22 AM, Noah Slater nsla...@apache.orgjavascript:; wrote: On 11 April 2013 11:22, Abhinandan Prateek abhinandan.prat...@citrix.com javascript:;wrote: 7-8 days is a huge time lost. I was suggesting that this to be 3 days. Let other community members chime in too. I should have replied to this in my previous missive. But I want to reenforce how unhealthy I believe this practice is. 7-8 days, or even 3 days being a huge time loss makes absolutely no sense to me at all. Assigning a bug should not mean it gets fixed any faster. If it does, then we need to change the way we are working. (And if this means changing the JIRA ticket workflow, then so be it. If something isn't working for us, we change it.) In fact, I would go so far as to say that we should think of assigning
Re: [DISCUSS] Don't assign tickets to people when triaging
+1 On 11 April 2013 15:39, Chip Childers chip.child...@sungard.com wrote: On Thu, Apr 11, 2013 at 12:51:34PM +, Abhinandan Prateek wrote: Yes, I think we need to space our releases further apart. That's a different discussion, which you are free to raise if you'd like. Also community members should volunteer to own some part so that in above circumstances a person looking for some fix can approach that member, once again a suggestion. I've been reading through this thread, and I'll pick the owner comment above as a starting point for my personal opinions. This is a reaction to the whole thread really, so take a minute to read to the end please. Owning some part is antithetical to a healthy community approach. Certainly people will gravitate to certain areas, and by all means everyone should feel free to work on areas of the code-base that they feel like they want to improve or support. This may lead to people effectively being the primary do-er for certain areas (examples: Wido has been working on DEB packaging, Rohit has been working on CloudMonkey), but we shouldn't ever consider this ownership. I feel personally welcome to make a change in CloudMonkey, and would certainly consider it important to collaborate with anyone (especially Rohit) that may have input and insights. The idea of ownership if a part of the software is something I'm strongly against. Even the idea of maintainers seems like it is problematic in implementation. How do we decide who the official maintainer is? How do we decide when someone else should do that... And frankly, doesn't a maintainer model really discourage others from working in named areas? All of these attempts to structure the community appear to be natural responses when you have a background in corporate development (product or otherwise), which is my background as well. It doesn't work here, and you have to fight the urge to apply the same solutions (WRT structure and process) in this environment. If you haven't read Producing OSS [1], go do that. What we really need is for those individuals that are interested in participating in this community to actively participate. Read the ML, take on bugs, focus on the shared community release goals. If you consider yourself interested in this project, then don't wait for assignments from someone else. Watch the lists, notice areas where you can help, discuss if you disagree with proposed community goals as they are being formed. Personal responsibility and interest in contributing to the shared community goals is what we should all expect of each other. We should not expect that others in the community will spoon feed tasks out. If that happens within someone's $dayjob, that's not a community concern. You'll notice that I have rarely assigned a bug. In a couple of instances, I've pushed something to someone that I know is *actively* working in an area of the code. I've also assigned a bug as purely an administrative step, when I know someone is already working on the issue, but may not have had the time to assign the bug to themselves. Release blockers that I don't easily associated with some ongoing and known work are highlighted in emails, with a request for someone to grab them. Releases are the shared goals of the community, but building a strong community is more important than any specific release. That's why this conversation started really. So yes, I want blockers to be addressed. Yes, I want us to get our releases out. Yes, I'd like us to be close to our proposed schedules. No, I'm not willing to have a release take priority over the more important goal of building a stronger and stronger community. -chip [1] http://www.producingoss.com/ -- NS
Re: Cloudstack.org domain
I shouldn't expect so. On 9 April 2013 14:13, Chip Childers chip.child...@sungard.com wrote: On Tue, Apr 09, 2013 at 01:34:01PM +0530, Prasanna Santhanam wrote: On Wed, Apr 03, 2013 at 07:21:30PM -0400, David Nalley wrote: On Wed, Apr 3, 2013 at 8:39 AM, Chip Childers chip.child...@sungard.com wrote: Hi all, One of our graduation checklist items is to get the cloudstack.org domain migrated to ASF infra for registration ownership and probably also for name services (although I'm not sure what the approach is for the latter). Can someone from Citrix with the right authority please work with infra@ to get this completed? -chip I'll take care of this. I'll start the conversation with infra and report back here. I'm assuming this will takeout the following services: a) jenkins.cs.o b) paste.cs.o (replaced by apaste.info) Not necessarily. Changing ownership / nameservers shouldn't force us to drop those A records from the zone file, right? If David hears otherwise from infra@, then we can figure it out from there. -- NS
Re: Cloudstack.org domain
Do you have a link to the discussion thread, David? I can't find anything in my mail. On 9 April 2013 15:46, David Nalley da...@gnsa.us wrote: On Tue, Apr 9, 2013 at 9:13 AM, Chip Childers chip.child...@sungard.com wrote: On Tue, Apr 09, 2013 at 01:34:01PM +0530, Prasanna Santhanam wrote: On Wed, Apr 03, 2013 at 07:21:30PM -0400, David Nalley wrote: On Wed, Apr 3, 2013 at 8:39 AM, Chip Childers chip.child...@sungard.com wrote: Hi all, One of our graduation checklist items is to get the cloudstack.org domain migrated to ASF infra for registration ownership and probably also for name services (although I'm not sure what the approach is for the latter). Can someone from Citrix with the right authority please work with infra@ to get this completed? -chip I'll take care of this. I'll start the conversation with infra and report back here. I'm assuming this will takeout the following services: a) jenkins.cs.o b) paste.cs.o (replaced by apaste.info) Not necessarily. Changing ownership / nameservers shouldn't force us to drop those A records from the zone file, right? If David hears otherwise from infra@, then we can figure it out from there. Yes it will. Infra indicates they won't point to any non-ASF resources. --David -- NS
Re: Cloudstack.org domain
Ack :( On 9 April 2013 17:38, David Nalley da...@gnsa.us wrote: It was on infra-private as that was where I was told to carry the conversation when I asked in IRC. I don't think that there is any negotiation to be done, multiple infra contractors over a period of almost a year have echoed similar sentiments. --David On Tue, Apr 9, 2013 at 12:35 PM, Noah Slater nsla...@apache.org wrote: Strange this was on infra-private, and not infra (which is also private). I only subscribe to the latter. I found your message now. Disappointing. I had not realised that this was policy. (I guess undocumented.) Wonder if there's any room for negotiation... On 9 April 2013 17:21, David Nalley da...@gnsa.us wrote: On Tue, Apr 9, 2013 at 11:50 AM, Noah Slater nsla...@apache.org wrote: Do you have a link to the discussion thread, David? I can't find anything in my mail. You'll need to use your member karma, as it's on infra-private: 097901ce30c3$c69ff210$53dfd630$@16degrees.com.au -- NS -- NS
Re: [DISCUSS] Don't assign tickets to people when triaging
When you say it's understandable that people being paid to work on CloudStack full time engage in cookie licking, do you mean to say you think it is acceptable? Or do you believe we should be working to prevent it? On 9 April 2013 19:14, Rohit Yadav bhais...@apache.org wrote: On Tue, Apr 9, 2013 at 11:56 AM, Prasanna Santhanam t...@apache.org wrote: On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi wrote: [Animesh] Folks I wanted to get your opinion on auto-assignment based on the component maintainers list. We can also create shared issues filters based on components. Folks can subscribe to the filters of interest and receive daily email notification. I have no opinion and am okay whichever way - auto-assign/unassigned. But these workflows should be _*clearly*_ mentioned to contributors and where they will go looking for them - wiki, website etc. A non-sponsored new/old (casual/hippie) contributor would try to search among unassigned issues, while managers/developers/committers whose $dayjob allows them to work on ACS fulltime will tend to do 'cookie lickin' which is understandable and will assure that someone gets the privilege to work on it and their employers will make sure the task would be done :) I would prefer an environment where every contributor (sponsored or otherwise) would assign the tickets themselves, and unassign if they cannot do it or don't have time/resources for it. We've already seen several occasions where someone assigns an issue to someone and we see cycle of assignments because the assigner had no clue about the issue or did not really know who would could really resolve the issue. Just saying. Cheers. Triaging and assigning issues at the time of release to contributors/committers by the Release Manager shouldn't be a problem at all as long as it's communicated (as Chip did for the RC bugs) Thanks, -- Prasanna., -- NS
Re: [DISCUSS] Don't assign tickets to people when triaging
Got it. Thanks! :) On 9 April 2013 19:29, Rohit Yadav bhais...@apache.org wrote: On Tue, Apr 9, 2013 at 11:51 PM, Noah Slater nsla...@apache.org wrote: When you say it's understandable that people being paid to work on CloudStack full time engage in cookie licking, do you mean to say you think it is acceptable? Hell NO, understandable == I understand how people work in the companies who pay them to work on ACS. But understandable != acceptable. Or do you believe we should be working to prevent it? Yes! That's what I'm saying: we should be working to prevent it. A way I suggested is to inculcate the habit among ourselves (all contributors) and promote the culture within ACS community to take initiatives and to assign the tickets themselves. No one should assign tickets to others unless a person has jira ACL issues and has explicitly asked for same on public ML to someone/anyone. Cheers. On 9 April 2013 19:14, Rohit Yadav bhais...@apache.org wrote: On Tue, Apr 9, 2013 at 11:56 AM, Prasanna Santhanam t...@apache.org wrote: On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi wrote: [Animesh] Folks I wanted to get your opinion on auto-assignment based on the component maintainers list. We can also create shared issues filters based on components. Folks can subscribe to the filters of interest and receive daily email notification. I have no opinion and am okay whichever way - auto-assign/unassigned. But these workflows should be _*clearly*_ mentioned to contributors and where they will go looking for them - wiki, website etc. A non-sponsored new/old (casual/hippie) contributor would try to search among unassigned issues, while managers/developers/committers whose $dayjob allows them to work on ACS fulltime will tend to do 'cookie lickin' which is understandable and will assure that someone gets the privilege to work on it and their employers will make sure the task would be done :) I would prefer an environment where every contributor (sponsored or otherwise) would assign the tickets themselves, and unassign if they cannot do it or don't have time/resources for it. We've already seen several occasions where someone assigns an issue to someone and we see cycle of assignments because the assigner had no clue about the issue or did not really know who would could really resolve the issue. Just saying. Cheers. Triaging and assigning issues at the time of release to contributors/committers by the Release Manager shouldn't be a problem at all as long as it's communicated (as Chip did for the RC bugs) Thanks, -- Prasanna., -- NS -- NS
Re: April board report
Chip, it looks better like this, for sure. Wondering if you're seen this: http://community.apache.org/boardreport.html (I only just found it myself!) I think we can probably loose most, if not all, of the current activity section. Perhaps even condense it into a handful of bullet points, and stick it under one of the named sections in the board report template here. This is also a useful guide: http://apache.org/foundation/board/reporting I think we've covered all the major basis, if still a little more verbose than most reports I've seen. You've might want to re-work to fit the template, but I hardly doubt it's necessary. Perhaps we should add a bullet point item about the hat wearing issues we've been discussing? (See the thread on assigning bugs to people in JIRA.) On 5 April 2013 17:24, Chip Childers chip.child...@sungard.com wrote: On Fri, Apr 05, 2013 at 04:03:27PM +0100, Noah Slater wrote: Looks like good info, Chip. This would make a good public project update. But perhaps this is a little wordy for a board report. Is there a way we can compress this? Perhaps cutting out any secondary or tertiary detail. The board typically review about 40 reports per month, I think? So there's a lot for them to read through already. Can folks take another look please? I shortened it a bit. I don't want to remove the core points though, until I get asked to not share as much information from the board itself (or a director who may want to help before we submit). On 5 April 2013 15:49, Chip Childers chip.child...@sungard.com wrote: Hi all, I have to submit our board report by Wed of next week, so I drafted a version here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/2013-04+Board+Report+for+Apache+CloudStack Can everyone take a look please? For information about what's expected, and what's not wanted, please see: http://apache.org/foundation/board/reporting Edits / additions using the guidance above are welcome (directly or via this thread). Thanks! -chip -- NS -- NS
Re: April board report
Looks like good info, Chip. This would make a good public project update. But perhaps this is a little wordy for a board report. Is there a way we can compress this? Perhaps cutting out any secondary or tertiary detail. The board typically review about 40 reports per month, I think? So there's a lot for them to read through already. On 5 April 2013 15:49, Chip Childers chip.child...@sungard.com wrote: Hi all, I have to submit our board report by Wed of next week, so I drafted a version here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/2013-04+Board+Report+for+Apache+CloudStack Can everyone take a look please? For information about what's expected, and what's not wanted, please see: http://apache.org/foundation/board/reporting Edits / additions using the guidance above are welcome (directly or via this thread). Thanks! -chip -- NS
Re: Mailing lists and markmail
I think they might just pick it up automatically. I don't believe Infra ever ping them. On 3 April 2013 13:52, Chip Childers chip.child...@sungard.com wrote: Does anyone want to own figuring out how to notify markmail about our mailing list changes? We've changed: 1) moved from incubator.apache.org to cloudstack.apache.org 2) added marketing and announce lists -chip -- NS
Re: CloudStack announcement list now available
Okay, this is the diff: https://paste.apache.org/g5hX I don't... I am confused. Heh. The live site looks different from what is apparently in Subversion... On 3 April 2013 14:28, Noah Slater nsla...@apache.org wrote: Dropping users@... You did? I just edited a page on the site, seconds before reading this email... Confused. I'll jump on IRC. On 3 April 2013 14:25, Chip Childers chip.child...@sungard.com wrote: On Wed, Apr 03, 2013 at 02:19:14PM +0100, Noah Slater wrote: Dear community, I would like to announce that we now have an announcement list. To wit: annou...@cloudstack.apache.org This is a low-volume public list for release announcements and security disclosures only. Subscribe by sending an email to: announce-subscr...@cloudstack.apache.org This list is not mentioned on the website yet, but it should be there soon. Actually I took care of that this morning ;-) Thanks, -- NS -- NS -- NS
Re: [DISCUSS] create a general@ mailing list?
Just a note that the previous two +1 votes are actually -1 votes in the context of the DISCUSS topic. I am also ready to cast my -1 vote. On 28 March 2013 16:56, Kelceydamage@bbits kel...@bbits.ca wrote: +1 from me as well. It duplicates or segregates, neither of which seem like a positive change. -kd Sent from my iPhone On Mar 28, 2013, at 9:46 AM, Joe Brockmeier j...@zonker.net wrote: On Thu, Mar 28, 2013, at 09:57 AM, Chip Childers wrote: Given that we have a mix of responses to this question (some for it and some against it), and that the pattern seems to be tied to the unliked practice of creating umbrella communities, I believe that we should not make the change within CloudStack. +1 Maybe someday we'll need one. But we're a long way from that right now. Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ -- NS
Re: New Committer: Animesh Chaturvedi
Grats! On 28 March 2013 19:57, Alex Huang alex.hu...@citrix.com wrote: The Podling Project Management Committee (PPMC) for Apache CloudStack has asked Animesh Chaturvedi to become a committer and we are pleased to announce that they have accepted. Being a committer enables easier contribution to the project since there is no need to go via the patch submission process. This should enable better productivity. Please join me in congratulating Sateesh! --Alex on behalf of the CloudStack PPMC -- NS
Re: New committer: Hiroaki Kawai
Congrats! On 25 March 2013 13:39, David Nalley da...@gnsa.us wrote: The Project Management Committee (PMC) for Apache CloudStack has asked Hiroaki Kawai to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Kawai-san --David on behalf of the CloudStack PMC -- NS
Re: New committer: Geoff Higginbottom
Grats! On 25 March 2013 15:25, Chip Childers chip.child...@sungard.com wrote: The Project Management Committee (PMC) for Apache CloudStack has asked Geoff Higginbottom to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Geoff! -chip on behalf of the CloudStack PMC -- NS
Re: [DISCUSS] create a general@ mailing list?
This proposal troubles me. The dev list is supposed to be the single place you can monitor as a contributor, and be assured that all development activity is happening there. We should absolutely be minimising the other places people need to check. And also, I do not want to have to rely on other people to be doing my filtering for me. I don't want to have to trust that if a dev-storage discussion becomes relevant for the general dev list, that it will be moved there. Obviously, the idea of general@ has precedent, but at least the concept seems distinct enough. It's going to be very infrequent that a PMC-level discussion ends up in a patch review, or vice versa. If we start splitting out the dev@ list into subjects, we risk fracturing the community. That's not to say it hasn't been done before. Hadoop do it. But perhaps there is some reason it works for them. TL;DR: We need to consider the community impact carefully. :) On 25 March 2013 23:14, Alex Huang alex.hu...@citrix.com wrote: Then agree to discuss it on dev list. Doesn't seem very hard to do to me. There's going to be people like you and me who'll be monitoring and reminding people that the feature is cross components. --Alex -Original Message- From: Joe Brockmeier [mailto:j...@zonker.net] Sent: Monday, March 25, 2013 3:54 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] create a general@ mailing list? On Mon, Mar 25, 2013, at 05:45 PM, Alex Huang wrote: To me the dev list is already a general list. I rather see more topic oriented lists like: dev-network, dev-storage, dev-hypervisor. What happens if a topic crosses over between storage, networking and hypervisors (or some subset)? I think it would be *very* hard to make that workable. Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ -- NS
Re: [DISCUSS] create a general@ mailing list?
P.S. Chip, I would consider asking on general@hadoop.a.o about this... On 21 March 2013 03:42, Chip Childers chip.child...@sungard.com wrote: I've noticed that some of the projects separate discussions between dev and general administrative items via a general@ and a dev@ list. For example, the last email I sent was about project meta-data. It's not specifically about developing cloudstack, but about managing our community activities. Does anyone think it makes sense to break that type of discussion out into a general@ list? -- NS
Re: [DISCUSS] create a general@ mailing list?
The users@ list is for users[1]: A user is someone that uses our software. They contribute to the Apache projects by providing feedback to developers in the form of bug reports and feature suggestions. Users participate in the Apache community by helping other users on mailing lists and user support forums. The dev@ list is for committers[2]: A committer is a developer that was given write access to the code repository[...] Not needing to depend on other people for the patches, they are actually making short-term decisions for the project. [1] http://www.apache.org/foundation/how-it-works.html#users [2] http://www.apache.org/foundation/how-it-works.html#committers On 26 March 2013 09:58, Giles Sirett giles.sir...@shapeblue.com wrote: Noah Isn't that what users@ is for ? - or is that really intended for true, well, users (Cloudstack doesn't really have users in the traditional sense) Kind Regards Giles D: +44 20 3603 0541 | M: +44 796 111 2055 giles.sir...@shapeblue.com -Original Message- From: Noah Slater [mailto:nsla...@apache.org] Sent: 26 March 2013 09:51 To: cloudstack Subject: Re: [DISCUSS] create a general@ mailing list? P.S. Chip, I would consider asking on general@hadoop.a.o about this... On 21 March 2013 03:42, Chip Childers chip.child...@sungard.com wrote: I've noticed that some of the projects separate discussions between dev and general administrative items via a general@ and a dev@ list. For example, the last email I sent was about project meta-data. It's not specifically about developing cloudstack, but about managing our community activities. Does anyone think it makes sense to break that type of discussion out into a general@ list? -- NS This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark. -- NS
[DISCUSS] Commit email notifications
Hey CloudStack devs, A bit of potential cross pollination here... I take it you've all noticed the screen-full-of-emails-generated-by-a-Git-push thing we have going on? Well, Paul Davis has figured out a way to get all those commits wrapped up into a single thread in mail clients that support threading. (See the forwarded message.) Is this something we're interested in switching to? Thanks, -- Forwarded message -- From: Paul Davis paul.joseph.da...@gmail.com Date: 20 March 2013 09:13 Subject: Commit email notifications To: d...@couchdb.apache.org First off, apologies for the commit spam. But hopefully I've managed to find a decent combination of useful information and helpful threading for most email clients. I got caught in the wind playing with email headers trying to set the Message-Id and In-Reply-To/References headers to get threading to work for the git email notifications. Then I remembered that GMail basically ignores those. So I've gone and also changed the subject formatting so that GMail does play nicely with threads. Basically, I've switched between these two email styles for commit notifications: Old Style: [1/4] git commit: test commit 1/3 New Style: [1/4] git commit: updated refs/heads/testing-email-notifications to 51293df The first one has the benefit of showing what the actual commit was about (this same information is repeated in the body) but the downside is that GMail does terrible thing in conversation view with these. I added a few things to the subject formatting and then set the format CouchDB uses to the style shown. This style has the benefit that each push to the repo should generate unique GMail conversations for each branch updated and also gives us a bit of a log on individual updates (a more thorough log is available via a URL I'm too lazy to lookup at 4am). One of the major thorns I've been chewing on for awhile is when we make an identical commit to more than one version branch and push all of those updated branches in one go. The old version would group them into a single GMail conversation which is a bit misleading and sometimes hard to pick apart. The new format should avoid that but at the loss of reading the git log --oneline history type log (that's really out of order so not totally useful). So if I'm crazy and people really like the single push fills your inbox approach let me know and I'll revert it and be more formal about the change. Though hopefully this new behavior is a net positive for everyone involved as my 4am brain seems to think is reasonable which means I've probably pissed off a whole bunch of people. -- NS
