Re: concerns about high overhead in Apache incubator releases
Jun, hopefully you will get the support you need on your dev list. However, please do not hesitate to come back to this list if you need clarity. It may take too many emails and you might need a thick skin, but we will help in our strange way. Sent from my mobile device, please forgive errors and brevity. On Nov 29, 2011 4:47 AM, Jun Rao jun...@gmail.com wrote: Thanks everyone for the feedback. This is very constructive and helpful. We will try to roll out a new RC accordingly. We are grateful for all the help that we got from Apache members and are proud to be part of Apache. Jun On Mon, Nov 28, 2011 at 1:05 PM, ant elder ant.el...@gmail.com wrote: On Sun, Nov 27, 2011 at 7:13 PM, Jun Rao jun...@gmail.com wrote: Dear Apache members, Over the past 2 months, the Kafka Apache incubator project has been trying to release its very first version in Apache. After 7 RCs, we are still not done. Part of this is because most of us are new to the Apache release process and are learning things along the way. However, I think Apache can do a better job in the incubating process to make releases much less painful. In the following, I will summarize some of problems that we had experienced. This is not an accusation, nor is it personal. I just hope that we can all learn from our experience so that Kafka and other incubator projects can release more smoothly in the future. 1. There is no good example to follow. As a new incubator project, the natural thing for us to do when it comes to releasing our code is to follow what other Apache projects do. However, more than once, the feedback that we got is that those are not good examples to follow. It seems that those bad examples are not isolated cases. 2. Different Apache members have different interpretations of the same rule. It seems that there is no consensus on some of the basic rules even among Apache members. For example, what constitutes a source distribution and what should be put in the NOTICE file? Since all it takes is one negative vote to block a release, this increases the turnover rate of RCs. 3. Not enough constructive and comprehensive suggestions. Some of the issues that are present in Kafka RC7 exist in RC1. Those issues could have been resolved much earlier had there been more constructive and comprehensive feedbacks from early on. Instead, often, the feedback just points out the violation of one or two issues that are enough to block a release. People like Ant Edler have made some constructive suggestions and we really appreciate that. We could use more suggestions like that. 4. Not enough flexibility in applying the rules. Some of the rules don't make common sense. For example, if we publish a new RC that simply fixes a few lines in NOTICE/LICENSE. We are still required to go through a full 3-day vote in Kafka and another full 3-day vote in Apache general. This, coupled with the high turnover rate of RCs, can delay the release for a significant long time. Both Chris Douglas and Ant Edler wanted to relax the rule slightly to help us speed things up. However, not every Apache member tolerates such flexibility. Again, all it takes is just one vote to kill a release. To summarize, our experience of releasing in Apache has not been very pleasant so far. I am not sure if our experience is the exception or the norm among incubator projects. In any case, I sincerely hope that at least some of those concerns can be addressed in Apache to make the release process more enjoyable, especially for new comers. Thanks, Jun I'd like to apologize on behalf of the Incubator for this less than excellent experience with your first release. Releases can be hard and they are one of the top things poddlings need to learn how to do but we should have been a bit better at teaching this and not let this release become such a long drawn out and painful process. As others have also commented in this email thread releases can't be veto'ed so just because you have a -1 or negative comment doesn't mean you need to respin right away. It does mean though that others might be put off from voting +1 so if that happens get your mentors to sort out it if its an issue or not, and don't be shy about emailing them directly if they are not participating already. Your email also mentions rules in several places - there aren't that many rules so before assuming something really is a rule try to find where its document that it is, and if no one can find that doc then its not a rule. Also, rules are only defined on policy pages so just because some guide type page says something doesn't make it true. For example, the comment about needing to vote once on kafka-dev for 72 hours and then again on general@ for another 72 hours - nothing says that
Re: [IP CLEARANCE] Apache Geronimo 2.2 Dependency Upgrades
On Mon, Nov 28, 2011 at 11:56 PM, Kevan Miller kevan.mil...@gmail.com wrote: The Apache Geronimo project has received a contribution which updates a number of Geronimo dependencies and associated code updates. The code contributions have been attached to https://issues.apache.org/jira/browse/GERONIMO-6217 I've committed the IP Clearance form to the Incubator website -- http://incubator.apache.org/ip-clearance/geronimo-dependency-upgrades.html The Geronimo community has passed a vote to accept the contribution -- http://mail-archives.apache.org/mod_mbox/geronimo-dev/20.mbox/%3c1bc3ab3f-2b25-4ce4-ba7b-5c8b4764e...@gmail.com%3e This stage of the IP clearance process is a 72-hour lazy consensus. Barring a -1, the ip clearance for this contribution will pass in 72 hours. Yes :-) this process is by lazy consensus. If anyone sees a problem, please post a -1 to this thread to force a formal review and VOTE. Kevan will close this thread by posting a RESULT mail no earlier than Friday, December 2, 2011 at 12:00:00 UTC [1] (by my reckoning). If you can spare a few cycles, please take a look before then. Robert [1] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20111202T12 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: concerns about high overhead in Apache incubator releases
On 29 November 2011 12:18, Niclas Hedhman nic...@hedhman.org wrote: On Tue, Nov 29, 2011 at 4:05 PM, Ross Gardler rgard...@opendirective.com wrote: hopefully you will get the support you need on your dev list. However, please do not hesitate to come back to this list if you need clarity. It may take too many emails and you might need a thick skin, but we will help in our strange way. A tangent, Ross; What is the relationship between Incubator Community Development and Apache Community Development ?? When we set up ComDev we discussed this. The conclusion we came to was that the Incubator is about incubating community around specific projects coming into the ASF and helping that community understand how to get things done here, that is, signposting for projects coming to the ASF. ComeDev is about helping individuals get involved with our communities, this is signposting for individuals coming to the ASF. Ross Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/6a2pl4j I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Release Apache Accumulo 1.3.5-incubating (rc8)
This is the first incubator release for Apache Accumulo, with the artifacts versioned as 1.3.5-incubating. VOTE: http://www.mail-archive.com/accumulo-dev@incubator.apache.org/msg00939.html RESULT: http://www.mail-archive.com/accumulo-dev@incubator.apache.org/msg01038.html SVN source tag: http://svn.apache.org/viewvc/incubator/accumulo/tags/1.3.5rc8/ Release artifacts: http://people.apache.org/~ecn Vote closes in 72 hours.
[POLL] Suitable Name Search: Drop Or Retain?
There has been concerns expressed about accumulation of rules without pruning. In that spirit, I'd like to find out whether the community feels that dropping the rule would be better than revising it into something workable. The current check [1] is outdated (for example, www.nameprotect.com) and isn't coordinated with the brand team who now look after marks and names. I've been pushing through a revision of the existing rule [2][3] with (what seems to me to be) limited support from the community. I had assume that the community supported the rule but perhaps the community feels that it would be better just to remove the rule (and ask the board to handle names). This is a POLL. Anyone can vote and it's result isn't binding. It provides evidence about which approach is more likely to gain consensus. Robert [1] Make sure that the requested project name does not already exist and check www.nameprotect.com to be sure that the name is not already trademarked for an existing software product. [2] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH [3] http://incubator.apache.org/guides/names.html --8--- [ ] Drop Suitable Name Search [ ] Revise Suitable Name Search - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Accumulo 1.3.5-incubating (rc8)
+ On Tue, Nov 29, 2011 at 9:24 AM, Eric Newton eric.new...@gmail.com wrote: This is the first incubator release for Apache Accumulo, with the artifacts versioned as 1.3.5-incubating. VOTE: http://www.mail-archive.com/accumulo-dev@incubator.apache.org/msg00939.html RESULT: http://www.mail-archive.com/accumulo-dev@incubator.apache.org/msg01038.html SVN source tag: http://svn.apache.org/viewvc/incubator/accumulo/tags/1.3.5rc8/ Release artifacts: http://people.apache.org/~ecn Vote closes in 72 hours. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Accumulo 1.3.5-incubating (rc8)
+1 binding On Tue, Nov 29, 2011 at 9:24 AM, Eric Newton eric.new...@gmail.com wrote: This is the first incubator release for Apache Accumulo, with the artifacts versioned as 1.3.5-incubating. VOTE: http://www.mail-archive.com/accumulo-dev@incubator.apache.org/msg00939.html RESULT: http://www.mail-archive.com/accumulo-dev@incubator.apache.org/msg01038.html SVN source tag: http://svn.apache.org/viewvc/incubator/accumulo/tags/1.3.5rc8/ Release artifacts: http://people.apache.org/~ecn Vote closes in 72 hours. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Accumulo 1.3.5-incubating (rc8)
+1 (binding) Tommaso 2011/11/29 Eric Newton eric.new...@gmail.com This is the first incubator release for Apache Accumulo, with the artifacts versioned as 1.3.5-incubating. VOTE: http://www.mail-archive.com/accumulo-dev@incubator.apache.org/msg00939.html RESULT: http://www.mail-archive.com/accumulo-dev@incubator.apache.org/msg01038.html SVN source tag: http://svn.apache.org/viewvc/incubator/accumulo/tags/1.3.5rc8/ Release artifacts: http://people.apache.org/~ecn Vote closes in 72 hours.
Re: [policy] release vetoes?
On 28 November 2011 19:21, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 11/28/2011 1:00 PM, Neha Narkhede wrote: That is because, every single time, the RM agreed that the release was worth re-cutting. We have been assuming that it is the rule of Apache to cut another RC even if it gets a single -1 vote. And that isn't correct, as Joe was kind enough to point out. A majority of +1's over -1's is required, obviously :) Although this seems reasonable, do people on this list believe this to be true according to the Apache rulebook ? In other words, can the podling RM and committers question and contest a -1 vote ? Is there any possibility of vetoing that ? If yes, who can do that in what circumstances ? Yes - you may always try to persuade someone who voted -1 to reconsider, especially by providing more information. For a code veto, that could include the fact that they failed to make a technical argument. Once they have a technical basis, you can't dispute it even if you disagree with it, it remains a veto. But always try to negotiate towards mutually agreeable code! No - nobody can veto a release. But you also can't slip in a vetoed patch and say this is a release vote, its not subject to veto. Well, as I had hinted, the RM can withdraw a vote, which is sort of like a self-veto. http://httpd.apache.org/dev/release.html was just recently revised by Roy Fielding (ASF Director and founding officer) based on some nonsense back-channel complaints, and might be worth integrating into incubator docs. Would it not be better to integrate the clarifications into an ASF-wide document? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Kafka 0.7.0-incubating
On 28 November 2011 21:17, Alan D. Cabrera l...@toolazydogs.com wrote: On Nov 28, 2011, at 9:51 AM, Neha Narkhede wrote: Thanks for the feedback, I still have some questions. 1. Alan, this nunit license acknowledgement is missing from the NOTICE file since RC1 and RC1 had the nunit files. Since cutting RCs is a significant time investment, we'd appreciate if you could list all the concerns you have once. I do not hold back my concerns hand them out in piecemeal fashion. I overlooked the DLL in earlier release candidate reviews; I made a mistake. :) 2. Sebb, if you have feedback on what should be removed from the file, we'd appreciate the exact list of items that are OK to be removed from the NOTICE. It is still unclear to us on what should and should not be included. I think that Sebb has made some good suggestions. It is not a requirement that the NOTICE file be minimal. Let's worry about this for the 0.7.x or 0.8.0 release. I was told a long time ago that it was important that the NOTICE file only include items that apply. IIRC, the reasoning I was given was that the NOTICE file imposes requirements on downstream users. I don't unfortunately have the reference to hand. [At the time I was just starting to create a release and did not realise there was so much that was undocumented or partially documented] 3. Ant, thanks for the suggestion earlier. We'd like this discussion to conclude with the exact contents of the LICENSE and NOTICE files. Better yet, can all these Apache nitty gritty items be listed on some wiki that the incubator RMs can follow and depend on ? I understand that the incubator process depends on the mentors to give such feedback, but clearly that is insufficient. IIUC, all that really needs to be done is to add NUnit to the NOTICE and LICENSE files. We can perform all the other suggestions in a subsequent release. I invite those who are interested to join the kafka project at kafka-dev and submit patches. :) That's where I'm not sure. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: concerns about high overhead in Apache incubator releases
On 28 November 2011 19:22, Ross Gardler rgard...@opendirective.com wrote: Sent from my mobile device, please forgive errors and brevity. On Nov 28, 2011 7:01 PM, Neha Narkhede neha.narkh...@gmail.com wrote: That is because, every single time, the RM agreed that the release was worth re-cutting. We have been assuming that it is the rule of Apache to cut another RC even if it gets a single -1 vote. A majority of +1's over -1's is required, obviously :) Although this seems reasonable, do people on this list believe this to be true according to the Apache rulebook ? Yes. See http://www.apache.org/foundation/voting.html Which says: Votes on Package Releases Votes on whether a package is ready to be released follow a format similar to majority approval -- except that the decision is officially determined solely by whether at least three +1 votes were registered. This specifically says that a majority is NOT required. This does seem odd. In other words, can the podling RM and committers question and contest a -1 vote ? Is there any possibility of vetoing that ? If yes, who can do that in what circumstances ? If you have 3 binding +1s and a majority of +1s you can release. See above linked doc. According to my reading of the cited doc, a majority is *not* needed. Ross Thanks, Neha On Mon, Nov 28, 2011 at 10:56 AM, William A. Rowe Jr. wr...@rowe-clan.netwrote: On 11/27/2011 3:34 PM, Benson Margulies wrote: I think I've been leading a sheltered existence. In the TLPs of which I play a part, over the 5 years or so that I've been around, I've never seen a release proceed past a -1. Every single time, a -1 has led to recutting the release. That is because, every single time, the RM agreed that the release was worth re-cutting. The vote hadn't (necessarily) failed... it was withdrawn for a better tag. When you get into complex alpha/beta releases, many projects will proceed, noting a -1 for some broken platform or broken feature, in order to get to the -next- alpha or beta release with that defect corrected, in addition to community feedback on the rest of the platforms and features. A majority of +1's over -1's is required, obviously :) --**--**- To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.org general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.**org general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Heads up: ACE 0.8.1-incubator vote
As a heads up to the IPMC we wanted to announce that we just started a release vote[1] on the ace-dev mailing list about ACE 0.8.1-incubator. This release basically fixes a few issues that came up while running our community graduation vote [2]. As soon as the vote has been closed, we will call for an Incubator PMC vote. Greetings, Marcel [1] http://s.apache.org/6wn [2] http://s.apache.org/DgJ and http://s.apache.org/s4q - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: concerns about high overhead in Apache incubator releases
On Tue, Nov 29, 2011 at 5:14 PM, sebb seb...@gmail.com wrote: This specifically says that a majority is NOT required. This does seem odd. This does mean that a release (for example due to a security issue) cannot be held back by any entity or block of committers. Martijn - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
NOTICE file must be minimal (was: [VOTE] Release Kafka 0.7.0-incubating)
On Monday, November 28, 2011, Alan D. Cabrera wrote: ... It is not a requirement that the NOTICE file be minimal. Let's worry about this for the 0.7.x or 0.8.0 release It think it *is* a requirement, according to http://apache.org/legal/src-headers.html#notice which specifically refers to *required* third-party notices. I agree that a non-minimal NOTICE might not warrant rejecting a podling release, but the next release should fix that. -Bertrand
Re: concerns about high overhead in Apache incubator releases
On 29 November 2011 16:26, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Tue, Nov 29, 2011 at 5:14 PM, sebb seb...@gmail.com wrote: This specifically says that a majority is NOT required. This does seem odd. This does mean that a release (for example due to a security issue) cannot be held back by any entity or block of committers. OK, that makes sense - but why is in not documented? It would make the rules much easier to understand if such requirements were explicitly documented. AFAICT, the underlying requirements for most of the ASF rules are rarely made explicit. This makes them harder to understand, especially in edge cases. It also makes them harder to amend (even just a clarification), because in general it's not possible to verify if the proposed update still meets the requirements. Martijn - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: NOTICE file must be minimal (was: [VOTE] Release Kafka 0.7.0-incubating)
On 29 November 2011 16:37, Bertrand Delacretaz bdelacre...@apache.org wrote: On Monday, November 28, 2011, Alan D. Cabrera wrote: ... It is not a requirement that the NOTICE file be minimal. Let's worry about this for the 0.7.x or 0.8.0 release It think it *is* a requirement, according to http://apache.org/legal/src-headers.html#notice which specifically refers to *required* third-party notices. I agree that a non-minimal NOTICE might not warrant rejecting a podling release, but the next release should fix that. That surely depends on the reason why the NOTICE file must only contain required notices. Are there any consequences for downstream users if the file is incorrect? Are there any consequences for the ASF? -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: NOTICE file must be minimal (was: [VOTE] Release Kafka 0.7.0-incubating)
Hi, On Tue, Nov 29, 2011 at 5:37 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: I agree that a non-minimal NOTICE might not warrant rejecting a podling release, but the next release should fix that. Agreed. For some background: Keeping the NOTICE file as lean as possible (given constraints from upstream licenses) is a great service to any downstream project that redistributes our releases. The simpler the NOTICE file is, the easier it is to meet the requirements of section 4 of ALv2. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: NOTICE file must be minimal (was: [VOTE] Release Kafka 0.7.0-incubating)
On Tue, Nov 29, 2011 at 4:37 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Monday, November 28, 2011, Alan D. Cabrera wrote: ... It is not a requirement that the NOTICE file be minimal. Let's worry about this for the 0.7.x or 0.8.0 release It think it *is* a requirement, according to http://apache.org/legal/src-headers.html#notice which specifically refers to *required* third-party notices. Yes - but what's required is a complex subject I agree that a non-minimal NOTICE might not warrant rejecting a podling release, but the next release should fix that. This is one of those areas that's difficult and time consuming for the legal team to get right in enough detail to allow simple fixes. Unless more volunteers step up to help, rejecting a release for minimality is likely to mean a lengthy delay. In general, better to note points for improvement and have the team fix them in trunk. Robert - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: NOTICE file must be minimal (was: [VOTE] Release Kafka 0.7.0-incubating)
On Tue, Nov 29, 2011 at 4:52 PM, sebb seb...@gmail.com wrote: Are there any consequences for downstream users if the file is incorrect? Are there any consequences for the ASF? Depends but potentially in some cases, yes. Robert - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: NOTICE file must be minimal (was: [VOTE] Release Kafka 0.7.0-incubating)
Hi, On Tue, Nov 29, 2011 at 5:52 PM, sebb seb...@gmail.com wrote: Are there any consequences for downstream users if the file is incorrect? To users no, to redistributors yes. Section 4 of ALv2 makes the attribution notices contained within the NOTICE file mandatory for any downstream distribution. Interpreting the excluding those notices that do not pertain to any part of the Derivative Works provision quickly becomes tricky if the NOTICE file isn't well maintained. For example, see https://issues.apache.org/jira/browse/COMPRESS-72 for a case where I was having trouble tracking down whether certain attributions really were needed for a downstream redistribution I was working on. Are there any consequences for the ASF? Not that I know of, though IANAL. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: NOTICE file must be minimal (was: [VOTE] Release Kafka 0.7.0-incubating)
On 29 November 2011 16:59, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: On Tue, Nov 29, 2011 at 4:37 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Monday, November 28, 2011, Alan D. Cabrera wrote: ... It is not a requirement that the NOTICE file be minimal. Let's worry about this for the 0.7.x or 0.8.0 release It think it *is* a requirement, according to http://apache.org/legal/src-headers.html#notice which specifically refers to *required* third-party notices. Yes - but what's required is a complex subject I agree that a non-minimal NOTICE might not warrant rejecting a podling release, but the next release should fix that. This is one of those areas that's difficult and time consuming for the legal team to get right in enough detail to allow simple fixes. Unless more volunteers step up to help, rejecting a release for minimality is likely to mean a lengthy delay. In general, better to note points for improvement and have the team fix them in trunk. But if the team already agrees that the changes need to be made, why not do so and re-roll? Robert - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [policy] release vetoes?
On 11/29/2011 9:52 AM, sebb wrote: http://httpd.apache.org/dev/release.html was just recently revised by Roy Fielding (ASF Director and founding officer) based on some nonsense back-channel complaints, and might be worth integrating into incubator docs. Would it not be better to integrate the clarifications into an ASF-wide document? I'm certain it would, the bigger question being who has the cycles to do so? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: concerns about high overhead in Apache incubator releases
No committee can take action without a majority on that committee approving the action. The VP might take action by fiat (they are given that authority) - I can't imagine that would ever happen except in consultation with legal-private@ for a legal issue raised on private@ that impeded that release for the time being. So whomever wrote Votes on whether a package is ready to be released follow a format similar to majority approval -- except that the decision is officially determined solely by whether at least three +1 votes were registered. either meant Votes on whether a package is ready to be released follow a format similar to majority approval -- except that the decision requires a quorum of at least three affirmative (+1) votes. or was outright wrong. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: concerns about high overhead in Apache incubator releases
On 11/29/2011 10:26 AM, Martijn Dashorst wrote: On Tue, Nov 29, 2011 at 5:14 PM, sebbseb...@gmail.com wrote: This specifically says that a majority is NOT required. This does seem odd. This does mean that a release (for example due to a security issue) cannot be held back by any entity or block of committers. The majority can always block a release; this doc is wrong. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: NOTICE file must be minimal (was: [VOTE] Release Kafka 0.7.0-incubating)
On 11/29/2011 11:30 AM, sebb wrote: On 29 November 2011 16:59, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: On Tue, Nov 29, 2011 at 4:37 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: I agree that a non-minimal NOTICE might not warrant rejecting a podling release, but the next release should fix that. This is one of those areas that's difficult and time consuming for the legal team to get right in enough detail to allow simple fixes. Unless more volunteers step up to help, rejecting a release for minimality is likely to mean a lengthy delay. In general, better to note points for improvement and have the team fix them in trunk. But if the team already agrees that the changes need to be made, why not do so and re-roll? One shortcut that can be taken when a /single file/ must be changed (and as discussed on the list, that change already has consensus), would be to roll the next candidate on a shorter 24 approval clock, provided that everyone had full opportunity to review the candidate, and that rest of the package had already met with general approval. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: NOTICE file must be minimal (was: [VOTE] Release Kafka 0.7.0-incubating)
One shortcut that can be taken when a /single file/ must be changed (and as discussed on the list, that change already has consensus), would be to roll the next candidate on a shorter 24 approval clock, provided that everyone had full opportunity to review the candidate, and that rest of the package had already met with general approval. +1. Couldn't agree more. Thanks, Neha On Tue, Nov 29, 2011 at 10:38 AM, William A. Rowe Jr. wr...@rowe-clan.netwrote: On 11/29/2011 11:30 AM, sebb wrote: On 29 November 2011 16:59, Robert Burrell Donkin robertburrelldon...@gmail.com** wrote: On Tue, Nov 29, 2011 at 4:37 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: I agree that a non-minimal NOTICE might not warrant rejecting a podling release, but the next release should fix that. This is one of those areas that's difficult and time consuming for the legal team to get right in enough detail to allow simple fixes. Unless more volunteers step up to help, rejecting a release for minimality is likely to mean a lengthy delay. In general, better to note points for improvement and have the team fix them in trunk. But if the team already agrees that the changes need to be made, why not do so and re-roll? One shortcut that can be taken when a /single file/ must be changed (and as discussed on the list, that change already has consensus), would be to roll the next candidate on a shorter 24 approval clock, provided that everyone had full opportunity to review the candidate, and that rest of the package had already met with general approval. --**--**- To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.orggeneral-unsubscr...@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.**orggeneral-h...@incubator.apache.org
Re: NOTICE file must be minimal (was: [VOTE] Release Kafka 0.7.0-incubating)
On Tue, Nov 29, 2011 at 6:38 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 11/29/2011 11:30 AM, sebb wrote: On 29 November 2011 16:59, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: On Tue, Nov 29, 2011 at 4:37 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: I agree that a non-minimal NOTICE might not warrant rejecting a podling release, but the next release should fix that. This is one of those areas that's difficult and time consuming for the legal team to get right in enough detail to allow simple fixes. Unless more volunteers step up to help, rejecting a release for minimality is likely to mean a lengthy delay. In general, better to note points for improvement and have the team fix them in trunk. But if the team already agrees that the changes need to be made, why not do so and re-roll? +1 One shortcut that can be taken when a /single file/ must be changed (and as discussed on the list, that change already has consensus), would be to roll the next candidate on a shorter 24 approval clock, provided that everyone had full opportunity to review the candidate, and that rest of the package had already met with general approval. +1 Robert - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [policy] release vetoes?
On Tue, Nov 29, 2011 at 6:29 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 11/29/2011 9:52 AM, sebb wrote: http://httpd.apache.org/dev/release.html was just recently revised by Roy Fielding (ASF Director and founding officer) based on some nonsense back-channel complaints, and might be worth integrating into incubator docs. Would it not be better to integrate the clarifications into an ASF-wide document? I'm certain it would, the bigger question being who has the cycles to do so? I've been wondering whether F2F meetups (bootcamps) for the incubator might be a way forward Robert - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [policy] release vetoes?
On 11/29/2011 2:14 PM, Robert Burrell Donkin wrote: I've been wondering whether F2F meetups (bootcamps) for the incubator might be a way forward Every retreat I've attended - which translates to those in Wicklow - has included some level of incubator orientation, and some participation by a few incubating projects. Strongly encouraged, we should do more to get the word out on the eve of the next events. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Voting time period can be shortened ? (was: [VOTE] Release Kafka 0.7.0-incubating)
Hi, The context for this is the discussion here - http://markmail.org/message/rsxjgrrufc6khlqy?q=overhead+list:org.apache.incubator.general This was a long discussion with no clear answers. We would like to know if it is OK to either - 1. shorten the release VOTE for change to one non-code file 2. run 72 hour vote in parallel on the dev list as well as on general@ What we would like to know is if any member would -1 the vote if we choose to do either of the above ? Thanks, Neha
Re: [policy] release vetoes?
On Tue, Nov 29, 2011 at 9:04 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 11/29/2011 2:14 PM, Robert Burrell Donkin wrote: I've been wondering whether F2F meetups (bootcamps) for the incubator might be a way forward Every retreat I've attended - which translates to those in Wicklow - has included some level of incubator orientation, and some participation by a few incubating projects. Strongly encouraged, we should do more to get the word out on the eve of the next events. I was wondering whether we might do something more explicitly Incubator focused perhaps with some presentations and panels Robert - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: NOTICE file must be minimal (was: [VOTE] Release Kafka 0.7.0-incubating)
Hi, On Tue, Nov 29, 2011 at 6:30 PM, sebb seb...@gmail.com wrote: But if the team already agrees that the changes need to be made, why not do so and re-roll? I'd just leave that up to the release manager to decide. There's no such thing as a perfect release (all non-trivial software has errors), so unless the fix is already available and the RM willing to do the extra effort I wouldn't stress too much about getting such non-critical changes in until the next release. le mieux est l'ennemi du bien --Voltaire BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [policy] release vetoes?
Sent from my mobile device, please forgive errors and brevity. On Nov 29, 2011 10:10 PM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: On Tue, Nov 29, 2011 at 9:04 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 11/29/2011 2:14 PM, Robert Burrell Donkin wrote: I've been wondering whether F2F meetups (bootcamps) for the incubator might be a way forward Every retreat I've attended - which translates to those in Wicklow - has included some level of incubator orientation, and some participation by a few incubating projects. Strongly encouraged, we should do more to get the word out on the eve of the next events. I was wondering whether we might do something more explicitly Incubator focused perhaps with some presentations and panels It doesn't make sense a a solution to three lack of effective and clear mentoring for a few projects. Most incubator projects, by definition, have small communities based in a single geographic location. Thinking of my own podlings that would be: - Vancouver - Bristol - Indiana - Bolton - Boston All of these projects are at a different stagger of incubation. Where would this event take place to give effective coverage for my podlings? What type would be useful top all? What about the other 50? Every little helps and if you want to spend time setting this up then I applaud you (and will help if I can). It will have a positive effect on those present, but minimal effect on the incubator as a while. Ross Robert - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[PROPOSAL] Apache DeltaSpike - CDI-Extensions project
Hi! JBoss, The Apache MyFaces CODI team and CDISource would like to propose the Apache DeltaSpike project to the Incubator. We have added the initial proposal to the Wiki[1] and its content is also included below for convenience. There are already a few people who expressed interest in contributing additional CDI Extensions and would like to join this effort. Of course, we are thankful for every helping hand! We are looking forward to feedback and/or questions on the proposal. We already have five mentors, but would very much welcome additional volunteers to help steer Apache DeltaSpike through the incubation process. LieGrue, strub [1] http://wiki.apache.org/incubator/DeltaSpikeProposal Apache DeltaSpike Proposal == Abstract Apache DeltaSpike is a collection of JSR-299 (CDI) Extensions for building applications on the Java SE and EE platforms. Proposal Apache DeltaSpike will consist of a number of portable CDI extensions that provide useful features for Java application developers. The goal of Apache DeltaSpike is to create a de-facto standard of extensions that is developed and maintained by the Java community, and to act as an incubator for features that may eventually become part of the various Java SE and EE-related specifications. Background One of the most exciting inclusions of the Java EE6 specification is JSR-299, Contexts and Dependency Injection (CDI) for Java. CDI builds on other Java EE specifications by defining a contextual component model and typesafe dependency injection framework for managed beans. It also defines a SPI that allows developers to write portable “extensions” that can be used to modify the behaviour of the Java EE platform, by offering additional features not provided by the platform by default. Apache DeltaSpike builds on this portable extensions SPI by providing baseline utilities and CDI Extensions which form the base of almost all CDI applications. Rationale There presently exists a number of open source projects that provide extensions for CDI, such as Apache MyFaces CODI, JBoss Seam3 and CDISource. Apache DeltaSpike seeks to unify these efforts by creating an “industry standard” set of extensions, combining the best core features of these projects. The project also aims to provide a rich, JBoss Arquillian based (license: ALv2), test environment to ensure that DeltaSpike portably runs in all important CDI environments. Initial Goals The initial goals of the Apache DeltaSpike project are to: * Setup the governance structure of the project * Receive code donations from contributing members * Ensure all donated code is appropriately licensed under the Apache License * Merge and rename code to reflect new project name * Merge code where feature overlap exists * Merge or produce documentation for all modules * Provide simple examples demonstrating feature usage * Produce release/s based on a schedule created by the PMC * Attract contributions from the greater Java EE community and other Java EE development groups Current Status The initial codebase for Apache DeltaSpike will be populated with mature code donations from project members, including JBoss Seam3, Apache MyFaces CODI and CDISource. Meritocracy All contributors have a well established history in the open source community and are well aware of the meritocracy principles of the Apache Software Foundation. Currently the Seam3 project is fortunate to receive the majority of its code contributions from its large community of users. Many of the modules that are contained in the Seam project are led by volunteers from the community, who have both direct commit access, and discretion over the direction of their modules. Apache MyFaces CODI is a subproject of Apache MyFaces and thus all contributors are already familiar with the meritocracy principles. The CDISource project has adopted the principles of meritocracy by the founding developers having control of different modules depending on their contribution to those modules. Community The JBoss Seam, Apache MyFaces CODI and CDISource projects already have well established communities, consisting of many active users and contributors. One of the primary goals of the Apache DeltaSpike project is to unify this community, and by creating a project that is a “single source of truth” for CDI Extensions. By doing this, we hope to make the whole greater than the sum of its parts, i.e. to attract a much stronger community than that which currently exists across the separate projects. To this end, it is a goal of this project to attract contributors from the Java EE community in addition to those from the three projects already mentioned. Core Developers *
Re: concerns about high overhead in Apache incubator releases
On 29 November 2011 18:34, William A. Rowe Jr. wr...@rowe-clan.net wrote: No committee can take action without a majority on that committee approving the action. The VP might take action by fiat (they are given that authority) - I can't imagine that would ever happen except in consultation with legal-private@ for a legal issue raised on private@ that impeded that release for the time being. That definitely makes more sense, and agrees with the HTTPD page (recently updated by Roy): http://httpd.apache.org/dev/release.html Who can vote? which says: For the ASF to release the candidate tarball/archive, at least three project members must vote affirmatively for release, and there must be more positive than negative votes for the release. So whomever wrote Votes on whether a package is ready to be released follow a format similar to majority approval -- except that the decision is officially determined solely by whether at least three +1 votes were registered. either meant Votes on whether a package is ready to be released follow a format similar to majority approval -- except that the decision requires a quorum of at least three affirmative (+1) votes. or was outright wrong. No wonder podlings are confused ... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: NOTICE file must be minimal (was: [VOTE] Release Kafka 0.7.0-incubating)
On 29 November 2011 22:25, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Tue, Nov 29, 2011 at 6:30 PM, sebb seb...@gmail.com wrote: But if the team already agrees that the changes need to be made, why not do so and re-roll? I'd just leave that up to the release manager to decide. There's no such thing as a perfect release (all non-trivial software has errors), so unless the fix is already available and the RM willing to do the extra effort I wouldn't stress too much about getting such non-critical changes in until the next release. I would question whether these NL errors are non-critical. http://www.apache.org/dev/release.html#what-must-every-release-contain says Every ASF release *must* comply with ASF licensing policy. This requirement is of utmost importance and an audit should be performed before any full release is created. In particular, every artifact distributed must contain appropriate LICENSE and NOTICE files. I read this as meaning that the NL files are (one of) the most important part(s) of a release. le mieux est l'ennemi du bien --Voltaire BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Voting time period can be shortened ? (was: [VOTE] Release Kafka 0.7.0-incubating)
On Tue, Nov 29, 2011 at 2:00 PM, Neha Narkhede neha.narkh...@gmail.com wrote: Hi, The context for this is the discussion here - http://markmail.org/message/rsxjgrrufc6khlqy?q=overhead+list:org.apache.incubator.general This was a long discussion with no clear answers. We would like to know if it is OK to either - 1. shorten the release VOTE for change to one non-code file 2. run 72 hour vote in parallel on the dev list as well as on general@ What we would like to know is if any member would -1 the vote if we choose to do either of the above ? You can most definitely run the votes in parallel. I did this for almost all of the Libcloud releases while it was in incubator. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Voting time period can be shortened ?
On Tue, Nov 29, 2011 at 04:49:03PM -0800, Paul Querna wrote: We would like to know if it is OK to either - 1. shorten the release VOTE for change to one non-code file 2. run 72 hour vote in parallel on the dev list as well as on general@ What we would like to know is if any member would -1 the vote if we choose to do either of the above ? You can most definitely run the votes in parallel. I did this for almost all of the Libcloud releases while it was in incubator. In my view, it's appropriate to run the votes in parallel if the RM has good reason to believe that the vote will pass. It would certainly make sense when a freelance IPMC member has detected something in a previous general@ VOTE thread. However, I don't think it should be standard operating procedure to run votes in parallel, because I don't think it's to our benefit to clog the general@ list with busted vote threads about about broken builds, missing dependencies, failing tests and so on. Votes should come to general@ only after technical problems have been worked out. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Voting time period can be shortened ?
On Nov 29, 2011, at 20:04, Marvin Humphrey mar...@rectangular.com wrote: In my view, it's appropriate to run the votes in parallel if the RM has good reason to believe that the vote will pass. Presumably nobody would waste anybody's time calling for a vote when they have reason to believe it wouldn't pass, would they? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Voting time period can be shortened ? (was: [VOTE] Release Kafka 0.7.0-incubating)
On 11/29/2011 4:00 PM, Neha Narkhede wrote: We would like to know if it is OK to either - 1. shorten the release VOTE for change to one non-code file 2. run 72 hour vote in parallel on the dev list as well as on general@ I've never seen a point to 2) to running serial votes. You need only 3 +1's (more +1's than -1's)... usually three mentors are enough to finish amoung the dev@ list, but announcing the vote (and its conclusion) on the general@ list seems entirely appropriate. If folks at general@ would like to have more input on the release, the ppmc dev@ list is really the best place to get involved. It is important to always allow 72 full hours. The reason is simple, we have participants in nearly every timezone, people who are here only on their own time, and more people who are here almost exclusively on work hours. 72 hours is long enough to accommodate them all, if they care to participate. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Voting time period can be shortened ? (was: [VOTE] Release Kafka 0.7.0-incubating)
On 11/29/2011 7:27 PM, William A. Rowe Jr. wrote: On 11/29/2011 4:00 PM, Neha Narkhede wrote: We would like to know if it is OK to either - 1. shorten the release VOTE for change to one non-code file 2. run 72 hour vote in parallel on the dev list as well as on general@ I've never seen a point to 2) to running serial votes. You need only 3 +1's (more +1's than -1's)... usually three mentors are enough to finish amoung the dev@ list, but announcing the vote (and its conclusion) on the general@ list seems entirely appropriate. If folks at general@ would like to have more input on the release, the ppmc dev@ list is really the best place to get involved. It is important to always allow 72 full hours. The reason is simple, we have participants in nearly every timezone, people who are here only on their own time, and more people who are here almost exclusively on work hours. 72 hours is long enough to accommodate them all, if they care to participate. [... trackpad arguing with me over whether I was done ...] So as I previously pointed out; *if* the community is already familiar with the candidate, thoroughly reviewed it for that full 72 hours, then if the RM replied to this file is broken with I'll fast-track only that fix and roll a final candidate with a shortened 24 hour final vote should put everyone in the frame of mind to review the revised candidate. But you can't ever shorten the net review time below three days :) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Voting time period can be shortened ? (was: [VOTE] Release Kafka 0.7.0-incubating)
So, you are saying option 2 is a reasonable choice, given that only the NOTICE/LICENSE files have changed one line here and there ? Thanks, Neha On Tue, Nov 29, 2011 at 5:34 PM, William A. Rowe Jr. wr...@rowe-clan.netwrote: On 11/29/2011 7:27 PM, William A. Rowe Jr. wrote: On 11/29/2011 4:00 PM, Neha Narkhede wrote: We would like to know if it is OK to either - 1. shorten the release VOTE for change to one non-code file 2. run 72 hour vote in parallel on the dev list as well as on general@ I've never seen a point to 2) to running serial votes. You need only 3 +1's (more +1's than -1's)... usually three mentors are enough to finish amoung the dev@ list, but announcing the vote (and its conclusion) on the general@ list seems entirely appropriate. If folks at general@ would like to have more input on the release, the ppmc dev@ list is really the best place to get involved. It is important to always allow 72 full hours. The reason is simple, we have participants in nearly every timezone, people who are here only on their own time, and more people who are here almost exclusively on work hours. 72 hours is long enough to accommodate them all, if they care to participate. [... trackpad arguing with me over whether I was done ...] So as I previously pointed out; *if* the community is already familiar with the candidate, thoroughly reviewed it for that full 72 hours, then if the RM replied to this file is broken with I'll fast-track only that fix and roll a final candidate with a shortened 24 hour final vote should put everyone in the frame of mind to review the revised candidate. But you can't ever shorten the net review time below three days :) --**--**- To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.orggeneral-unsubscr...@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.**orggeneral-h...@incubator.apache.org
Re: Voting time period can be shortened ? (was: [VOTE] Release Kafka 0.7.0-incubating)
On 11/29/2011 7:50 PM, Neha Narkhede wrote: So, you are saying option 2 is a reasonable choice, given that only the NOTICE/LICENSE files have changed one line here and there ? Yes, if you let the 72 hour vote run through with a clear message that it will be rerolled with a short vote. If everyone says oh, it's a broken package and doesn't test further, then a 24 hour vote wouldn't be sufficient opportunity to review. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
