Re: NOTICE file must be minimal (was: [VOTE] Release Kafka 0.7.0-incubating)
On Wed, Nov 30, 2011 at 12:34 AM, sebb seb...@gmail.com wrote: 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. I agree they're important and we need to teach poddlings how to do them correctly and they must not be missing things that are included in the release, but i still say that having some unnecessary content in the LICENSE or NOTICE is not necessarily a blocker. No one is going to sue the ASF if a release includes a license or notice that it actually doesn't need, so its down to the poddling to decide if they want to respin to remove it. ...ant - 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 10: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 The voting policy only says: Votes should generally be permitted to run for at least 72 hours to provide an opportunity for all concerned persons to participate regardless of their geographic locations. - http://www.apache.org/foundation/voting.html So nothing there says 72 hours is an absolute minimum. I've seen TLPs do releases in less than 72 hours, usually to fix something like a very serious issue in a previous release. And this was discussed on this list a year or so ago and consensus was that that was ok. That should be fine for poddlings too but I'd expect you'd need a very good reason to convince three Incubator PMC members to vote for a release like that. 2. run 72 hour vote in parallel on the dev list as well as on general@ Thats totally fine and happens often, as Paul pointed out Libcloud did that for most of its releases and many other poddlings have too. If a poddling keeps sending low quality releases to votes on general@ people might stop bothering to review and vote on them so poddlings probably only want to do this once they're a bit confident with their releases. What we would like to know is if any member would -1 the vote if we choose to do either of the above ? Even if they did a -1 on a release vote is not a veto. Thanks, Neha - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache DeltaSpike - CDI-Extensions project
Wow, exciting proposal. Curious if infra is already accepting git for this podling. Have your reached out to them already? On Wed, Nov 30, 2011 at 12:40 AM, Mark Struberg strub...@yahoo.de wrote: 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
Re: [POLL] Suitable Name Search: Drop Or Retain?
+1 On Tue, Nov 29, 2011 at 3:25 PM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: 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 -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache DeltaSpike - CDI-Extensions project
Yes, we reached out to them quite a while ago (informally). Board was also involved. Also please note that almost all of the involved contributors are long time GIT users already! I also have personally reserved quite a few days to help out Infra with setting up the environment. LieGrue, strub - Original Message - From: Christian Grobmeier grobme...@gmail.com To: general@incubator.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Wednesday, November 30, 2011 10:02 AM Subject: Re: [PROPOSAL] Apache DeltaSpike - CDI-Extensions project Wow, exciting proposal. Curious if infra is already accepting git for this podling. Have your reached out to them already? On Wed, Nov 30, 2011 at 12:40 AM, Mark Struberg strub...@yahoo.de wrote: 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
Re: [POLL] Suitable Name Search: Drop Or Retain?
On Wed, Nov 30, 2011 at 9:10 AM, Christian Grobmeier grobme...@gmail.com wrote: +1 (Oops, I didn't explain very well) With a POLL, you need to pick one of the option. Robert - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [POLL] Suitable Name Search: Drop Or Retain?
I am sorry, didn't see the poll options. Thought it was just a heads up if this needs to be changed. [X] Drop Suitable Name Search Cheers On Wed, Nov 30, 2011 at 12:21 PM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: On Wed, Nov 30, 2011 at 9:10 AM, Christian Grobmeier grobme...@gmail.com wrote: +1 (Oops, I didn't explain very well) With a POLL, you need to pick one of the option. Robert - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RFC] Proposed voting description edits
I've done a short trawl of the pages that relate to release voting. There are two pages that I think need updating - please read on. The Httpd release description [1] 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. The glossary entry for Majority Approval [2] says: Refers to a vote (sense 1) which has completed with at least three binding +1 votes and more +1 votes than -1 votes. ( I.e. , a simple majority with a minimum quorum of three positive votes.) These agree with each other, and are both correct, as far as I am aware. OK so far? == Now the Apache Voting Process/Package Releases page [3] disagrees with [1], as it says: Votes on whether a package is ready to be released follow a format similar to majority approval [2] -- except that the decision is officially determined solely by whether at least three +1 votes were registered I hope we are all agreed that this is misleading/wrong, and in fact release votes are governed by Majority Approval as defined by the glossary [2] I propose to change this to: Votes on whether a package is ready to be released use Majority Approval [2] -- i.e.at least three PMC members must vote affirmatively for release, and there must be more positive than negative votes for the release. [Note: capitalisation of Majority Approval is necessary to distinguish it from simple majority approval, which does not have the +1 x 3 quorum requirement. It is also the section heading in [2].] OK? == The Release FAQ section on approving a release [4] says: All releases must be voted[5] on by the project and must receive at least three +1 votes from PMC members. This is correct, but incomplete. In this case, I suggest the same as before, i.e. Votes on whether a package is ready to be released use Majority Approval [2] -- i.e.at least three PMC members must vote affirmatively for release, and there must be more positive than negative votes for the release. OK? == [1] http://httpd.apache.org/dev/release.html - section Who can vote? [2] http://www.apache.org/foundation/glossary.html#MajorityApproval [3] http://www.apache.org/foundation/voting.html#ReleaseVotes [4] http://www.apache.org/dev/release.html#approving-a-release [5] http://www.apache.org/foundation/voting.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache DeltaSpike - CDI-Extensions project
+1 (binding) PS: Updated the proposal to re-add myself as Mentor... On Nov 29, 2011, at 6:40 PM, Mark Struberg wrote: 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. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [RFC] Proposed voting description edits
+1 From: sebb Sent: 11/30/2011 3:53 AM To: general@incubator.apache.org Subject: [RFC] Proposed voting description edits I've done a short trawl of the pages that relate to release voting. There are two pages that I think need updating - please read on. The Httpd release description [1] 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. The glossary entry for Majority Approval [2] says: Refers to a vote (sense 1) which has completed with at least three binding +1 votes and more +1 votes than -1 votes. ( I.e. , a simple majority with a minimum quorum of three positive votes.) These agree with each other, and are both correct, as far as I am aware. OK so far? == Now the Apache Voting Process/Package Releases page [3] disagrees with [1], as it says: Votes on whether a package is ready to be released follow a format similar to majority approval [2] -- except that the decision is officially determined solely by whether at least three +1 votes were registered I hope we are all agreed that this is misleading/wrong, and in fact release votes are governed by Majority Approval as defined by the glossary [2] I propose to change this to: Votes on whether a package is ready to be released use Majority Approval [2] -- i.e.at least three PMC members must vote affirmatively for release, and there must be more positive than negative votes for the release. [Note: capitalisation of Majority Approval is necessary to distinguish it from simple majority approval, which does not have the +1 x 3 quorum requirement. It is also the section heading in [2].] OK? == The Release FAQ section on approving a release [4] says: All releases must be voted[5] on by the project and must receive at least three +1 votes from PMC members. This is correct, but incomplete. In this case, I suggest the same as before, i.e. Votes on whether a package is ready to be released use Majority Approval [2] -- i.e.at least three PMC members must vote affirmatively for release, and there must be more positive than negative votes for the release. OK? == [1] http://httpd.apache.org/dev/release.html - section Who can vote? [2] http://www.apache.org/foundation/glossary.html#MajorityApproval [3] http://www.apache.org/foundation/voting.html#ReleaseVotes [4] http://www.apache.org/dev/release.html#approving-a-release [5] http://www.apache.org/foundation/voting.html - 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)
Yupyup. I thought I'd add a little background rant here, that I wrote for the jena podling a bit ago. Purely optional reading but maybe illuminating for some. cheerio, - Leo On Tue, Nov 8, 2011 at 9:44 PM, Leo Simons m...@leosimons.com wrote: On Fri, Nov 4, 2011 at 3:54 PM, Benson Margulies bimargul...@gmail.com wrote: snip/ Release votes are about universally 72 hours. Benson is of course right, but I like pointing out reasons behind such conventions, so I'm going to give you a belated, long answer anyway, reading it is optional :-) I'm always a little annoyed when I see people say something like sorry your vote doesn't count it was too late, or you can't do that yet you have to wait 3 more hours someone might still vote -1 :-) The underlying point is to make sure to give everyone a reasonable chance to make up their minds and then vote (in the broadest everyone sense, and even if they may not have a binding vote). Religiously sticking to numbers is silly. Use your judgement. The duty of PMC members in the end is to act in the best interests of the apache foundation (which acts in the best interest of the general public), not to follow (or force onto others) particular rules. Some examples to illustrate, probably unneeded, but... If you consider people might be a day behind on their e-mail, and they might be on the other side of the globe, that's 36 hours absolute worst-case. If you add a weekend in the middle from friday 5pm to monday 9pm that's a total of 36 + 7 + 9 + 48 = 100 hours. If you consider that it may take a day, say, to verify a release and regression test it (say across your, err, 1000 node hadoop cluster, whatever), that's 124 hours. So you could have a long argument that 72 hours is not enough, and decide as a project you will use a 124 hour minimum. You're allowed to do that, if that's what you think is best for your community. On the one extreme you can imagine a project with all the people on the mailing list being on UTC time or close to it where a vote is almost pro forma since consensus was clear anyway, where you start the vote at 9am in the morning and everyone subscribed to the mailing list has voted by 11am. Do you then want to wait 122 additional hours because that's a rule? Not really. On the other extreme, for something like here's a proposal to bring geronimo / harmony / openoffice into apache that impacts loads and loads of people and might cause corporations to move mountains, it's considered normal to allow reasonable amounts of time for discussion, where reasonable could be over a month. 72 hours turns out from experience to be a nice standard number for release votes and other such important milestones, because it gives a very reasonable amount of time allowing for the broadest possible participation, without becoming a super-annoying super-long wait. It avoids people holding a project hostage and stalling, yet also avoids the temptation to rush through contentious changes when the majority (but not all) people are co-located at a hackathon, etc. But, use your own judgement. If one of the companies one of you works at would really really like an extra day to regression test a new version of jena at a large customer deployment, and that is delayed a bit because someone tied up all the jenkins instances with their hadoop stuff, it'll probably be a good idea to wait for the results rather than push through with a vote, since that means the general public gets to benefit from a better-tested release. This kind of balancing thing is, incidentally, why the how to do apache stuff docs don't have that many hard rules. Stubborn people like me keep editing them out :) cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [POLL] Suitable Name Search: Drop Or Retain?
Hey Robert, its not clear to me why a suitable name search should be dropped - is that because the brand team will do this search on a projects behalf? I see nameprotect is outdated, but a quick search by project members to see if there are conflicts is still probably a good thing. It just might not have to be as thorough if brand is ultimately going to do their own search. From: Christian Grobmeier Sent: 11/30/2011 3:35 AM To: general@incubator.apache.org Subject: Re: [POLL] Suitable Name Search: Drop Or Retain? I am sorry, didn't see the poll options. Thought it was just a heads up if this needs to be changed. [X] Drop Suitable Name Search Cheers On Wed, Nov 30, 2011 at 12:21 PM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: On Wed, Nov 30, 2011 at 9:10 AM, Christian Grobmeier grobme...@gmail.com wrote: +1 (Oops, I didn't explain very well) With a POLL, you need to pick one of the option. Robert - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - 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 30 November 2011 14:11, Leo Simons m...@leosimons.com wrote: Yupyup. I thought I'd add a little background rant here, that I wrote for the jena podling a bit ago. Purely optional reading but maybe illuminating for some. cheerio, - Leo On Tue, Nov 8, 2011 at 9:44 PM, Leo Simons m...@leosimons.com wrote: On Fri, Nov 4, 2011 at 3:54 PM, Benson Margulies bimargul...@gmail.com wrote: snip/ Release votes are about universally 72 hours. Benson is of course right, but I like pointing out reasons behind such conventions, so I'm going to give you a belated, long answer anyway, reading it is optional :-) I'm always a little annoyed when I see people say something like sorry your vote doesn't count it was too late, or you can't do that yet you have to wait 3 more hours someone might still vote -1 :-) The underlying point is to make sure to give everyone a reasonable chance to make up their minds and then vote (in the broadest everyone sense, and even if they may not have a binding vote). Religiously sticking to numbers is silly. Use your judgement. The duty of PMC members in the end is to act in the best interests of the apache foundation (which acts in the best interest of the general public), not to follow (or force onto others) particular rules. Some examples to illustrate, probably unneeded, but... If you consider people might be a day behind on their e-mail, and they might be on the other side of the globe, that's 36 hours absolute worst-case. If you add a weekend in the middle from friday 5pm to monday 9pm that's a total of 36 + 7 + 9 + 48 = 100 hours. If you consider that it may take a day, say, to verify a release and regression test it (say across your, err, 1000 node hadoop cluster, whatever), that's 124 hours. So you could have a long argument that 72 hours is not enough, and decide as a project you will use a 124 hour minimum. You're allowed to do that, if that's what you think is best for your community. On the one extreme you can imagine a project with all the people on the mailing list being on UTC time or close to it where a vote is almost pro forma since consensus was clear anyway, where you start the vote at 9am in the morning and everyone subscribed to the mailing list has voted by 11am. Do you then want to wait 122 additional hours because that's a rule? Not really. On the other extreme, for something like here's a proposal to bring geronimo / harmony / openoffice into apache that impacts loads and loads of people and might cause corporations to move mountains, it's considered normal to allow reasonable amounts of time for discussion, where reasonable could be over a month. 72 hours turns out from experience to be a nice standard number for release votes and other such important milestones, because it gives a very reasonable amount of time allowing for the broadest possible participation, without becoming a super-annoying super-long wait. It avoids people holding a project hostage and stalling, yet also avoids the temptation to rush through contentious changes when the majority (but not all) people are co-located at a hackathon, etc. But, use your own judgement. If one of the companies one of you works at would really really like an extra day to regression test a new version of jena at a large customer deployment, and that is delayed a bit because someone tied up all the jenkins instances with their hadoop stuff, it'll probably be a good idea to wait for the results rather than push through with a vote, since that means the general public gets to benefit from a better-tested release. This kind of balancing thing is, incidentally, why the how to do apache stuff docs don't have that many hard rules. Stubborn people like me keep editing them out :) Which is fine if the reason why the rule is soft is made explicit. Otherwise one cannot tell if the document is complete. I keep saying this: IMO documenting the reasons behind the rules is vital to understand them. cheers, Leo - 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: [PROPOSAL] Apache DeltaSpike - CDI-Extensions project
+1 (binding) -Matthias On Wed, Nov 30, 2011 at 1:24 PM, Jim Jagielski j...@jagunet.com wrote: +1 (binding) PS: Updated the proposal to re-add myself as Mentor... On Nov 29, 2011, at 6:40 PM, Mark Struberg wrote: 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. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache DeltaSpike - CDI-Extensions project
Mmm, shouldn't voting be carried out in a separate [VOTE] Accept DeltaSpike... thread? Matt On Wed, Nov 30, 2011 at 10:21 AM, Matthias Wessendorf mat...@apache.org wrote: +1 (binding) -Matthias On Wed, Nov 30, 2011 at 1:24 PM, Jim Jagielski j...@jagunet.com wrote: +1 (binding) PS: Updated the proposal to re-add myself as Mentor... On Nov 29, 2011, at 6:40 PM, Mark Struberg wrote: 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. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - 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: [PROPOSAL] Apache DeltaSpike - CDI-Extensions project
yup the [VOTE] mail is currently planed for next monday. I will interpret any +1 as a frenetic 'wooohooo ye' until then ;) LieGrue, strub - Original Message - From: Matt Benson gudnabr...@gmail.com To: general@incubator.apache.org Cc: Sent: Wednesday, November 30, 2011 5:28 PM Subject: Re: [PROPOSAL] Apache DeltaSpike - CDI-Extensions project Mmm, shouldn't voting be carried out in a separate [VOTE] Accept DeltaSpike... thread? Matt On Wed, Nov 30, 2011 at 10:21 AM, Matthias Wessendorf mat...@apache.org wrote: +1 (binding) -Matthias On Wed, Nov 30, 2011 at 1:24 PM, Jim Jagielski j...@jagunet.com wrote: +1 (binding) PS: Updated the proposal to re-add myself as Mentor... On Nov 29, 2011, at 6:40 PM, Mark Struberg wrote: 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. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Change in Due Dates for Board reports
Hi, On 16 November 2011 20:47, Noel J. Bergman n...@devtech.com wrote: PLEASE NOTE! From the ASF Board: For now on, all reports to the board for review/inclusion at the board meetings will now be due 1 WEEK before the meeting. Reports submitted late will be declined and you'll need to resubmit the next month. This means that Incubator reports really need to be finished by the end of the FIRST week of the month. We need to update http://apache.org/foundation/board/reporting and http://community.apache.org/boardreport.html to reflect this change and to be consistent with each other. The pages currently disagree on when reporting should happen: projects due to report need to have their reports ready no later than the second Wednesday of that month well before the relevant board meeting (at least 48 hours before the meeting begins) Sam suggests reports should actually be due on 1st of each month, but in further discussion this got a bit fuzzy. From Ross, I also hear: Podling reports at the start of the month (remember mentors need to have time to sign off on them); TLP reports the friday before the meeting; Podling reports are earlier because the IPMC needs time to review them. -- but I haven't tracked down the thread with that decision yet. So which should it be? Andrew. -- asav...@apache.org / cont...@andrewsavory.com http://www.andrewsavory.com/
Re: [PROPOSAL] Apache DeltaSpike - CDI-Extensions project
On Wed, Nov 30, 2011 at 5:55 PM, Mark Struberg strub...@yahoo.de wrote: yup the [VOTE] mail is currently planed for next monday. I will interpret any +1 as a frenetic 'wooohooo ye' until then ;) +1 :) LieGrue, strub - Original Message - From: Matt Benson gudnabr...@gmail.com To: general@incubator.apache.org Cc: Sent: Wednesday, November 30, 2011 5:28 PM Subject: Re: [PROPOSAL] Apache DeltaSpike - CDI-Extensions project Mmm, shouldn't voting be carried out in a separate [VOTE] Accept DeltaSpike... thread? Matt On Wed, Nov 30, 2011 at 10:21 AM, Matthias Wessendorf mat...@apache.org wrote: +1 (binding) -Matthias On Wed, Nov 30, 2011 at 1:24 PM, Jim Jagielski j...@jagunet.com wrote: +1 (binding) PS: Updated the proposal to re-add myself as Mentor... On Nov 29, 2011, at 6:40 PM, Mark Struberg wrote: 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. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Missing reports (was: Re: Incubator Board Report November 2011)
On 2011-11-16 21:53, Dennis Lundberg wrote: Hi I am one of the mentors for NPanday. We did not provide a report this month. We apologize for this. Like Stefan I cannot seem to find the handy reminder e-mail that usually comes on the first day of the reporting month. Neither in my inbox nor the dev-list archive. Do you want us to report next month instead? I never got an answer to this. Anyone? If so, I guess I'll need to update this wiki page right? http://wiki.apache.org/incubator/ReportingSchedule On 2011-11-16 11:57, Christian Grobmeier wrote: This time were 7 reports missed (leaving out S4): On Wed, Nov 16, 2011 at 5:41 AM, Noel J. Bergman n...@devtech.com wrote: Amber HISE Kalumet Lucene.NET NPanday Zeta Components Stonehenge SHOULD BE RETIRED. I am a Mentor of Zeta. This time I have not had the time to push the report. A pity, nobody else felt responsible. I have asked at the developers list about the activity of the podling. Can we hear from the mentors of the other projects what is going on in their podlings? A mentors response is what we should get when report is missed by default. In addition I think we should notify Stonehenge about retiring them and afterward start a vote here finally. Thoughts? Cheers Christian - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Feedback on updated NOTICE and LICENSE files (was: [VOTE] Release Kafka 0.7.0-incubating)
Hi, The Kafka community is hoping to get some feedback on the updated NOTICE and LICENSE files for Kafka, before we post a new vote for it. http://people.apache.org/~nehanarkhede/NOTICE http://people.apache.org/~nehanarkhede/LICENSE The previous vote thread or release artifacts are here - http://apache.markmail.org/message/hntuhwkbazwlfdoe?q=Kafka+list:org.apache.incubator.general We would appreciate it if you can please take the time to review this now, since we would like to ensure a smoother vote this time around. Thanks, Neha
Re: Feedback on updated NOTICE and LICENSE files (was: [VOTE] Release Kafka 0.7.0-incubating)
Also, we haven't ignored the fact that the NOTICE file must ideally be as short as possible. To track this issue, we've filed a bug - https://issues.apache.org/jira/browse/KAFKA-219 and will be fixing it for the next release. Thanks, Neha On Wed, Nov 30, 2011 at 6:29 PM, Neha Narkhede neha.narkh...@gmail.comwrote: Hi, The Kafka community is hoping to get some feedback on the updated NOTICE and LICENSE files for Kafka, before we post a new vote for it. http://people.apache.org/~nehanarkhede/NOTICE http://people.apache.org/~nehanarkhede/LICENSE The previous vote thread or release artifacts are here - http://apache.markmail.org/message/hntuhwkbazwlfdoe?q=Kafka+list:org.apache.incubator.general We would appreciate it if you can please take the time to review this now, since we would like to ensure a smoother vote this time around. Thanks, Neha
RE: Feedback on updated NOTICE and LICENSE files (was: [VOTE] Release Kafka 0.7.0-incubating)
I notice that the NOTICE has this incomplete statement: This product includes the scala runtime and compiler (www.scala-lang.org) developed by EPFL, which includes the following license: There is not any following license. I also notice that the LICENSE file has copyright notices. - Dennis -Original Message- From: Neha Narkhede [mailto:neha.narkh...@gmail.com] Sent: Wednesday, November 30, 2011 18:30 To: general@incubator.apache.org Cc: kafka-us...@incubator.apache.org Subject: Feedback on updated NOTICE and LICENSE files (was: [VOTE] Release Kafka 0.7.0-incubating) Hi, The Kafka community is hoping to get some feedback on the updated NOTICE and LICENSE files for Kafka, before we post a new vote for it. http://people.apache.org/~nehanarkhede/NOTICE http://people.apache.org/~nehanarkhede/LICENSE The previous vote thread or release artifacts are here - http://apache.markmail.org/message/hntuhwkbazwlfdoe?q=Kafka+list:org.apache.incubator.general We would appreciate it if you can please take the time to review this now, since we would like to ensure a smoother vote this time around. Thanks, Neha smime.p7s Description: S/MIME cryptographic signature
Re: Missing reports (was: Re: Incubator Board Report November 2011)
On Wednesday, November 30, 2011, Dennis Lundberg wrote: On 2011-11-16 21:53, Dennis Lundberg wrote: ...I am one of the mentors for NPanday. We did not provide a report this month. We apologize for this... Do you want us to report next month instead? I'd say yes, report at the next opportunity. ...If so, I guess I'll need to update this wiki page right? http://wiki.apache.org/incubator/ReportingSchedule I don't think so, just go back to your normal schedule after the shifted report. -Bertrand
