RE: Anticipating my reign of terror -- new idea for December
I don't know what it takes to become and IPMC member, but I kind of like the idea of having roles that don't require such formality (I may think too highly of the process and role), but still can be recognized as providing guidance and knowledge to those going through the process. Date: Thu, 8 Nov 2012 22:54:53 -0500 Subject: Re: Anticipating my reign of terror -- new idea for December From: gst...@gmail.com To: general@incubator.apache.org Empirically, Model 1 did not work. That's been tried over the past ten years. *shrug* ... whatever you want to do. I just wanted to speak up that you appeared to be conflating the mentor and shepherd roles (as they had been defined over the past couple months). If you *intend* to combine them (Model 1), then fine. Cheers, -g On Wed, Nov 7, 2012 at 6:52 AM, Benson Margulies bimargul...@gmail.com wrote: 2. We need the shepherds to compensate for mentor shortages in addition to discovering those. I disagree. In short, you are conflating mentors with IPMC Members. They serve *very* different roles. Greg, let me start by writing that I am not in some hurry to turn shepherds into pie. If they turn out to be a part of the long-term landcape, no worries here. On the other hand, let me try to refine my idea of why they should wither away. Model 1: The IPMC members supervise the podlings. This is delegated/scaled/divided-and-conquered by the mentors, who are IPMC members. Mentors supervise in addition coaching and guiding. If they do this job correctly, we would not need shepherds. In support of this model, I'll point out that we require mentors to be IPMC members. Why do we do this, if mentoring is not part of the supervisory process? Model 2: The mentors are the good cops, exercising a light touch, so we need some other IPMC members to perform supervision. Thus, shepherds. Greg, if I'm messed up your logic here, please excuse me. When I serve on a non-I-PMC, I read every message on dev, user, and private, and I try to pay some attention to commits. We don't ask shepherds to do anything like that. I've always thought that we asked mentors to do that. So, it seems to me, if we prefer model (2), we not only need shepherds, we need to ask more of them. If we prefer model (1), we need to continue to work to achieve a situation where every podling has a sufficiency of active, supervising mentors -- and identifying people in the podlings who have earned that role is one way to do it. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [VOTE] Apache OpenOffice Community Graduation Vote
I'm sorry, I'm playing catch-up and I'm a bit unclear on the argument - Marvin said: If the podling believes that ASF-endorsed binaries are a hard requirement, then it seems to me that the ASF is not yet ready for AOO and will not be until suitable infrastructure and legal institutions to support binary releases (sterile build machines, artifact signing, etc) have been created and a policy has been endorsed by the Board. Is AOO not able to determine that for them a binary is a hard requirement for their releases (along with source code)? I would think that ASF puts a minimum requirement on what an official release is, not a limit. Why is there a requirement for special infrustructure? (perhaps that is due to the size of AOO?) Speaking just from the Lucene.Net persective, I would consider our binaries (and nuget packages) as official - even if ASF does not specifically allow for official releases or officially endourced binaries - what else would they be? They were built and put up by the same guys releasing the source code. I apologize if I misunderstand or mischaracterized anything ~P Date: Mon, 20 Aug 2012 22:33:43 -0400 Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote From: gst...@gmail.com To: general@incubator.apache.org On Aug 20, 2012 8:33 PM, Rob Weir robw...@apache.org wrote: On Mon, Aug 20, 2012 at 8:11 PM, Greg Stein gst...@gmail.com wrote: ... I would also state that continuing to argue is symptomatic of a failure to understand and integrate with the Foundation's thoughts on the matter. Or to at least politely discuss the situation on legal-discuss. I would say the lack of understanding could be in both directions, and some greater tolerance would be mutually beneficial. I *am* being tolerant (you should see my intolerant emails). And what makes you believe that I don't understand? I get to offer my thoughts, and you do not get to say that I have a lack of understanding simply because you disagree. Remember, OpenOffice is unlike anything else previously at Apache. Duh. Don't be so patronizing. Again: I suggest the discussion about making authorized/authenticated binaries be moved to legal-discuss. Not here. Infrastructure may need to provide some input, too. I might also point you to Sam's recommendation to avoid over-posting to a thread as a way to dominate / get your way. How many emails are you up to so far? -g
RE: [VOTE] Apache OpenOffice Community Graduation Vote
Simple enough - thanks. Date: Mon, 20 Aug 2012 23:05:00 -0400 Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote From: gst...@gmail.com To: general@incubator.apache.org On Mon, Aug 20, 2012 at 10:55 PM, Prescott Nasser geobmx...@hotmail.com wrote: I'm sorry, I'm playing catch-up and I'm a bit unclear on the argument - Marvin said: If the podling believes that ASF-endorsed binaries are a hard requirement, then it seems to me that the ASF is not yet ready for AOO and will not be until suitable infrastructure and legal institutions to support binary releases (sterile build machines, artifact signing, etc) have been created and a policy has been endorsed by the Board. Is AOO not able to determine that for them a binary is a hard requirement for their releases (along with source code)? I would think that ASF puts a minimum requirement on what an official release is, not a limit. Why is there a requirement for special infrustructure? (perhaps that is due to the size of AOO?) Speaking just from the Lucene.Net persective, I would consider our binaries (and nuget packages) as official - even if ASF does not specifically allow for official releases or officially endourced binaries - what else would they be? They were built and put up by the same guys releasing the source code. The simplest response is that source releases can be audited by (P)PMC members. Binary releases cannot. If they cannot be audited, then how can the ASF stand behind those releases? How can they state that the releases are free of viruses/trojans/etc, and that the binary precisely matches the compiled/built output of the audited source release? That is the first and hardest issue about having the ASF provide authenticated binaries. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [VOTE] Apache OpenOffice Community Graduation Vote
Actually one more question - so we can release binaries, but we can't call them official? Do we have wording for this? Official source code release with accompanying binaries for convenience or some such? From: geobmx...@hotmail.com To: general@incubator.apache.org Subject: RE: [VOTE] Apache OpenOffice Community Graduation Vote Date: Mon, 20 Aug 2012 20:11:23 -0700 Simple enough - thanks. Date: Mon, 20 Aug 2012 23:05:00 -0400 Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote From: gst...@gmail.com To: general@incubator.apache.org On Mon, Aug 20, 2012 at 10:55 PM, Prescott Nasser geobmx...@hotmail.com wrote: I'm sorry, I'm playing catch-up and I'm a bit unclear on the argument - Marvin said: If the podling believes that ASF-endorsed binaries are a hard requirement, then it seems to me that the ASF is not yet ready for AOO and will not be until suitable infrastructure and legal institutions to support binary releases (sterile build machines, artifact signing, etc) have been created and a policy has been endorsed by the Board. Is AOO not able to determine that for them a binary is a hard requirement for their releases (along with source code)? I would think that ASF puts a minimum requirement on what an official release is, not a limit. Why is there a requirement for special infrustructure? (perhaps that is due to the size of AOO?) Speaking just from the Lucene.Net persective, I would consider our binaries (and nuget packages) as official - even if ASF does not specifically allow for official releases or officially endourced binaries - what else would they be? They were built and put up by the same guys releasing the source code. The simplest response is that source releases can be audited by (P)PMC members. Binary releases cannot. If they cannot be audited, then how can the ASF stand behind those releases? How can they state that the releases are free of viruses/trojans/etc, and that the binary precisely matches the compiled/built output of the audited source release? That is the first and hardest issue about having the ASF provide authenticated binaries. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [VOTE] Graduate Apache Any23 from the Apache Incubator
+1 From: Mattmann, Chris A (388J) Sent: 8/16/2012 6:42 AM To: general@incubator.apache.org Cc: any23-...@incubator.apache.org Subject: [VOTE] Graduate Apache Any23 from the Apache Incubator Hi Folks, We have already called and completed a community VOTE with the Any23 community and the Tika PMC and they have positively recommended Any23's graduation from the Incubator. VOTE: http://s.apache.org/fU RESULT: http://s.apache.org/VAl I am now calling for a VOTE with the Incubator PMC to graduate Any23 from the Incubator. I'll leave the VOTE open for at least the next 72 hours. [ ] +1 Graduate Any23 from the Apache Incubator. [ ] +0 Don't care. [ ] -1 Don't graduate Any23 from the Apache Incubator because... The Any23 draft board resolution is pasted for your consideration below. Thank you! Cheers, Chris Mattmann Any23 Champion P.S. Here's my +1! - X. Establish the Apache Any23 Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software, for distribution at no charge to the public, related to the automatic crawling, parsing and analyzing of data to produce RDF. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Any23 Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Any23 Project be and hereby is responsible for the creation and maintenance of software related to the automatic crawling, parsing and analyzing of data to produce RDF and be it further RESOLVED, that the office of Vice President, Apache Any23 be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Any23 Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Any23 Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Any23 Project: * Lewis John McGibbney lewi...@apache.org * Paul Ramirezprami...@apache.org * Simone Tripodi simonetrip...@apache.org * Tommaso Teofili tomm...@apache.org * Davide Palmisano dpalmis...@apache.org * Giovanni Tummarello giova...@apache.org * Michele Mostardamosta...@apache.org * Reto Bachmann-Gmürr...@apache.org * Szymon Danielczyk szy...@apache.org * Andy Seabornea...@apache.org * Peter Ansell Unlisted CLA on file; awaiting Apache ID requested ans...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Michele Mostarda be appointed to the office of Vice President, Apache Any23 to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache Any23 Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Any23 podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Any23 podling encumbered upon the Apache Incubator Project are hereafter discharged. ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULTS] [VOTE] Apache Lucene.Net graduation from the incubator
The vote passes with the following +1's (these of course are in addition to the 40+ lucene.Net community +1s): Stefan Bodewig Jukka Zitting Benson Margulies Gianugo Rabellion Troy Howard We'll now be submitting our resolution to the Board, Thanks all, ~Prescott - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Apache Lucene.Net graduation from the incubator
Hey all, The Lucene.Net community feels ready to graudate. Our internal vote was a success (~40 +1's and a bit of a mess because we had a number of mailing lists which spread our vote out - sorry about that spam). We had some concerns regarding the size and activity of our community, however, with addition of two new committers just recently we feel that we are still growing as a community and that graduating will only help us build our community further. Dev Mailing List: http://s.apache.org/FQF User Mailing List: http://s.apache.org/P6f Our [Proposal] Resolution thread in general (http://s.apache.org/Qv6) didn't garner many comments, but we take silence as your proposal looks good Once again our resolution is located: https://cwiki.apache.org/confluence/display/LUCENENET/Graduation+-+Resolution+Template I'll leave this vote open for at least 72 hours: [+1] We need some time apart to appreciate each other [-1] We'd like you to stay because... Thanks all, ~Prescott - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[PROPOSAL] Lucene.Net Graduation Resolution
Hey all, I think we're ready to move along in the graduation process. If you would please review our graduation resolution and provide any feedback the Lucene.Net team would greatly appreciate it: https://cwiki.apache.org/confluence/display/LUCENENET/Graduation+-+Resolution+Template Thanks,~Prescott - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Apache Lucene.Net ready for graduation?
Hey All, This is the first step for graduation for the Apache Lucene.Net project (incubating of course..). We're taking a vote for the Lucene.Net community to see if the community is ready to govern itself as a top level project. Here is a short list of our accomplishments which I believe make us ready for graduation: - Released 2.9.4 - Released 2.9.4g (Generics version) - created a new website, with a new logo (a 99designs contest gracious supported by stackoverflow) - Added two new committers bringing our total to 9. - Preparing for 3.0.3 Release within the next couple of weeks - Started work on 3.5 release. This is the process we will follow: - Community vote (this email). All votes count, there is no non-binding / binding status for this - We will propose a resolution for review (https://cwiki.apache.org/confluence/display/LUCENENET/Graduation+-+Resolution+Template) - We will call a vote on the resolution in general @ incubator - A Board resolution will be submitted. As a community, if you would please vote: [1] Ready for graduation [-1] Not ready because... I know I speak for all the developers on this project, we appreciate (and will continue to appreciate) everyone's contributions via the mailing list and jira. ~Prescott - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Lucene.NET status
It's a good idea - we're going to discuss this and see what we can do. I definitely would like to bring in some new committers. I know that the committers we do have are extremely busy with other parts of their lives - it would be great to bring in some new people who can help out. We'll do what we can. ~P From: jukka.zitt...@gmail.com Date: Thu, 10 May 2012 15:55:50 +0200 Subject: Re: Lucene.NET status To: general@incubator.apache.org Hi, On Thu, May 10, 2012 at 9:37 AM, Stefan Bodewig bode...@apache.org wrote: On 2012-05-10, Jukka Zitting wrote: However, the one thing I am a bit worried about is that I couldn't tell when was the last time you added a new committer to the team. Never. OK. Your contribution report [1] shows some people who've contributed lots of patches but aren't committers yet. What's up with that? [1] https://issues.apache.org/jira/secure/ConfigureReport.jspa?versionId=-1issueStatus=allselectedProjectId=12310290reportKey=com.sourcelabs.jira.plugin.report.contributions%3AcontributionreportNext=Next Many of those contributions happened before Lucene.NET re-entered incubation, the people have been let down back then and never came back when Lucene.NET came back to life. That's a good reminder of the importance of bringing in new committers when you can. Without a constant stream of new people a project will eventually lose steam as existing committers lose interest or become otherwise occupied for whatever other reason. Is there a way to get a contribution report for the last year only or something similar? Filtering by version likely won't cut it. AFAICT it's not possible by default, though someone with enough Jira skills would likely be able to create such a report. Of the top ten people some already are committers (Digy and Prescott) and only two other names ring a bell (I haven't been involved with Lucene.NET prior to becoming a mentor). Many contributions to Lucene.NET are one-off contributions and so far almost all contributors have been content with discussing their issues in JIRA. Unfortunately. OK, thanks for the background. I've been involved with quite a few podlings with similar problems in attracting longer-term contributors. In my experience the best way to solve that problem is to change your mindset of expecting most such people to be just one-off contributors. If you instead treat them as your next new committers and engage with them as peers, many (though of course not all) will respond in kind and actually become more involved. Many developers, especially from commercial backgrounds, tend to treat such contributors as just users reporting a problem. A typical interaction goes like What's the problem? Do you have a test case? OK, let me fix it (when I get around to it). A better approach is something like What's the problem? OK, here are some pointers to the relevant bits in code. How do you think this should be fixed? BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
including external code under apache 2.0
Hey all, We've had a community member port a library for Lucene.Net that we'd like to include in our contrib packages. The package is under the apache 2.0 license, so we think we are in the clear to include the code into our contrib package - but we weren't sure and just wanted to double check. The contrib project is located here: https://github.com/synhershko/Spatial4n Thanks for your guidance~Prescott
RE: including external code under apache 2.0
Thanks Troy! From: thowar...@gmail.com Date: Fri, 27 Apr 2012 15:11:39 -0700 Subject: Re: including external code under apache 2.0 To: lucene-net-...@lucene.apache.org CC: general@incubator.apache.org My understanding is that we can include the code as long as we have a ICLA from Itamar. This was discussed at length in January for another contribution that the same contributor wanted to donate. Stephan (Bodewig, our Incubation mentor) laid out what needed to be done really clearly in that context. Here's the link to the final message on that thread where Stephan recaps the relevant points: http://s.apache.org/HZa I don't know if Itamar ever followed up after that and filed a ICLA. If he did, we're good and just need to commit the code.. Otherwise, we'll need him to do the ICLA first. Thanks, Troy On Fri, Apr 27, 2012 at 2:30 PM, Prescott Nasser geobmx...@hotmail.com wrote: Hey all, We've had a community member port a library for Lucene.Net that we'd like to include in our contrib packages. The package is under the apache 2.0 license, so we think we are in the clear to include the code into our contrib package - but we weren't sure and just wanted to double check. The contrib project is located here: https://github.com/synhershko/Spatial4n Thanks for your guidance~Prescott
RE: Fwd: mentoring individuals as well as projects
+1 From: Marvin Humphrey Sent: 2/1/2012 8:06 AM To: general@incubator.apache.org Subject: Re: Fwd: mentoring individuals as well as projects On Wed, Feb 01, 2012 at 01:54:18PM +, Ross Gardler wrote: My point is that when we help guide individuals who demonstrate a willingness to contribute those individuals often grow in capacity. There was a memorable post on another ASF list a few months ago which compared Apache's decentralized leadership model to that of military organizations and contrasted it with the stiff hierarchical model common in the corporate world. It linked to an article which studied the question of why military service -- particularly service in the crucible of combat -- is exceptionally effective at developing leaders.[1] The article author's answer, in part: Secondly, military leaders tend to hold high levels of responsibility and authority at low levels of our organizations. Top level PMCs at Apache are largely autonomous, but when it comes to binding votes on releases, podlings are wholly dependent on IPMC members whose attentions often wander. Our future PMC members do not hold high levels of responsibility and authority at low levels of our organization -- instead, projects have a boolean graduated/not-graduated property whereby podlings move from having no autonomy and mandatory supervision to having near-total autonomy and scant supervision after graduation. I believe that we would develop better future PMC members if PPMC members were encouraged to earn partial autonomy for their podlings by earning a binding vote for themselves. Serving alongside Mentors encourages podling contributors to think like Mentors, exercising servant leadership and devolving responsibility within their own projects. Presently, we do not often take advantage of this opportunity to expand the capacity of these individuals who demonstrate a willingness to contribute within the crucible of incubation -- to our podlings' detriment and our own. Marvin Humphrey [1] http://blogs.hbr.org/frontline-leadership/2009/02/why-the-military-produces-grea.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [VOTE Result] Release Apache Lucene.Net 2.9.4g incubating
This vote passes with the required 3 +1's from Sebb, Ant, and Stefan. Thank you guys for taking the time to review and approve this release, ~Prescott Date: Fri, 27 Jan 2012 09:19:57 + Subject: Re: [VOTE] Release Apache Lucene.Net 2.9.4g incubating From: ant.el...@gmail.com To: general@incubator.apache.org On Thu, Jan 26, 2012 at 1:29 PM, Stefan Bodewig bode...@apache.org wrote: On 2012-01-23, Prescott Nasser wrote: Lucene.Net 2.9.4g is ready for release. This is very similar to our release at the end of November, however we have used generics where appropriate to give it a better feel for .Net developers. SVN Tag: https://svn.apache.org/repos/asf/incubator/lucene.net/tags/Lucene.Net_2_9_4g_RC1/ Artifacts: http://people.apache.org/~pnasser/Lucene.Net/2.9.4g-incubating-RC1/ Repeating my vote from the dev list +1 With Benson's vote we have two IPMC +1s and still need a third one. Stefan +1 ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [VOTE Result] Release Apache Lucene.Net 2.9.4g incubating
You're absolutely right, I was looking at a bunch of your emails and your name slipped in. I should have said Benson. My apologies to both of you. Sent from my Windows Phone From: sebb Sent: 1/28/2012 1:56 PM To: general@incubator.apache.org Subject: Re: [VOTE Result] Release Apache Lucene.Net 2.9.4g incubating On 28 January 2012 20:53, Prescott Nasser geobmx...@hotmail.com wrote: This vote passes with the required 3 +1's from Sebb, Ant, and Stefan. Thank you guys for taking the time to review and approve this release, ~Prescott Date: I did not vote +1. I did not vote at all. Fri, 27 Jan 2012 09:19:57 + Subject: Re: [VOTE] Release Apache Lucene.Net 2.9.4g incubating From: ant.el...@gmail.com To: general@incubator.apache.org On Thu, Jan 26, 2012 at 1:29 PM, Stefan Bodewig bode...@apache.org wrote: On 2012-01-23, Prescott Nasser wrote: Lucene.Net 2.9.4g is ready for release. This is very similar to our release at the end of November, however we have used generics where appropriate to give it a better feel for .Net developers. SVN Tag: https://svn.apache.org/repos/asf/incubator/lucene.net/tags/Lucene.Net_2_9_4g_RC1/ Artifacts: http://people.apache.org/~pnasser/Lucene.Net/2.9.4g-incubating-RC1/ Repeating my vote from the dev list +1 With Benson's vote we have two IPMC +1s and still need a third one. Stefan +1 ...ant - 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 Apache Lucene.Net 2.9.4g incubating
In our last release we were dinged for having too much in the notice, we agreed to move them to an acknowledgements file. There was also that lengthy discussion in general regarding what belongs in a notice file (I don't wish to start that again :) ). So we should have additional things in the notice? I'm just unclear on the guidance here. I will make a note of the excessively long lines in the DISCLAIMER and make sure those are updated for future release, hopefully they aren't a deal breaker for this release? I appreciate your feedback, ~P Date: Wed, 25 Jan 2012 01:30:29 + Subject: Re: [VOTE] Release Apache Lucene.Net 2.9.4g incubating From: seb...@gmail.com To: general@incubator.apache.org On 23 January 2012 06:20, Prescott Nasser geobmx...@hotmail.com wrote: Hi all, Lucene.Net 2.9.4g is ready for release. This is very similar to our release at the end of November, however we have used generics where appropriate to give it a better feel for .Net developers. SVN Tag: https://svn.apache.org/repos/asf/incubator/lucene.net/tags/Lucene.Net_2_9_4g_RC1/ Various stemmers are mentioned in the LICENSE file; their license appears to require a notice in the NOTICE file. The DISCLAIMER text file has excessively long lines in it. Artifacts: http://people.apache.org/~pnasser/Lucene.Net/2.9.4g-incubating-RC1/ The vote is open for 72 hours, or until we get the needed number of votes. [ ] +1 Release this package as Apache Lucene.Net 2.9.4g-incubating [ ] -1 Do not release this package because... Thank you for your time reviewing this release, ~Prescott - 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
[VOTE] Release Apache Lucene.Net 2.9.4g incubating
Hi all, Lucene.Net 2.9.4g is ready for release. This is very similar to our release at the end of November, however we have used generics where appropriate to give it a better feel for .Net developers. SVN Tag: https://svn.apache.org/repos/asf/incubator/lucene.net/tags/Lucene.Net_2_9_4g_RC1/ Artifacts: http://people.apache.org/~pnasser/Lucene.Net/2.9.4g-incubating-RC1/ The vote is open for 72 hours, or until we get the needed number of votes. [ ] +1 Release this package as Apache Lucene.Net 2.9.4g-incubating [ ] -1 Do not release this package because... Thank you for your time reviewing this release, ~Prescott - 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?
Completely agree , if there is a rule list I dont think this needs to be on it, this is more a best practice imo Sent from my Windows Phone From: Robert Burrell Donkin Sent: 12/1/2011 4:20 AM To: general@incubator.apache.org Subject: Re: [POLL] Suitable Name Search: Drop Or Retain? On Wed, Nov 30, 2011 at 2:15 PM, Prescott Nasser geobmx...@hotmail.com wrote: 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? This seems likely to me But this is a POLL. Each option has advantages and disadvantages. 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. This seems likely to me This is how Incubator rules accumulate. Podlings needs help, so guidance is documented. Over time these conventions harden into rules. If the Incubator community wants to preserve quality with fewer rules, it need to do less. 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?
This is perhaps an area where the incubator needs more caution before best practice turns into a rule. You can call it guidance rather than best practices, but I think you'll just say that's the same thing. I do agree with your statements though Sent from my Windows Phone From: Robert Burrell Donkin Sent: 12/1/2011 10:00 AM To: general@incubator.apache.org Subject: Re: [POLL] Suitable Name Search: Drop Or Retain? On Thu, Dec 1, 2011 at 5:32 PM, Prescott Nasser geobmx...@hotmail.com wrote: Completely agree , if there is a rule list I dont think this needs to be on it, this is more a best practice imo Best practices tend to become the rule Robert - 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: [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: [VOTE RESULT] Release of Lucene.Net 2.9.4-incubating-RC3
Thanks Ant - our dev list agrees that we should be adding some information about what is being updated - we will include this in future releases. With that, we have 3 votes we need, we appreciate your guy's time in revewing our release. ~Prescott Date: Mon, 28 Nov 2011 09:12:29 + Subject: Re: [VOTE] Release of Lucene.Net 2.9.4-incubating-RC3 From: ant.el...@gmail.com To: general@incubator.apache.org Looks ok to me. In future releases it might be good to consider including a release notes type file that mentions whats been updated in the release +1 ...ant On Sun, Nov 27, 2011 at 10:29 PM, Prescott Nasser geobmx...@hotmail.com wrote: Hi all, We could use another vote or two, Thanks! -P Sent from my Windows Phone From: Benson Margulies Sent: 11/25/2011 11:56 AM To: general@incubator.apache.org Subject: Re: [VOTE] Release of Lucene.Net 2.9.4-incubating-RC3 Well, fine, I am happy to +1. On Fri, Nov 25, 2011 at 1:53 PM, Alan D. Cabrera l...@toolazydogs.com wrote: On Nov 25, 2011, at 8:32 AM, ant elder wrote: On Fri, Nov 25, 2011 at 4:16 PM, Benson Margulies bimargul...@gmail.com wrote: I hate to have to say this, but I have concerns about the NOTICE file based on recent traffic here. LOL Unfortunately, that conversation left me with a giant headache and no clear idea. The issue is that there's a misc acknowledgement in there which is not a relocated IP notice. Are those OK, or not? (@Leo, help!) Not including something in the NOTICE that must be required might be a blocking problem but including just a little more than is necessary isn't IMHO. If it was a podling release with so much unnecessary stuff that it showed they didn't really understand the requirements maybe thats worth voting against so they go and sort it out but for something like this i think its ok to say sort it out later I am of the same opinion here. I think that some votes on this list are overly critical, often laden with personal opinions and not real Foundation requirements. This leads to a very frustrating experience to new podling members who are unable to tell the difference. 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 - 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 of Lucene.Net 2.9.4-incubating-RC3
Hi all, We could use another vote or two, Thanks! -P Sent from my Windows Phone From: Benson Margulies Sent: 11/25/2011 11:56 AM To: general@incubator.apache.org Subject: Re: [VOTE] Release of Lucene.Net 2.9.4-incubating-RC3 Well, fine, I am happy to +1. On Fri, Nov 25, 2011 at 1:53 PM, Alan D. Cabrera l...@toolazydogs.com wrote: On Nov 25, 2011, at 8:32 AM, ant elder wrote: On Fri, Nov 25, 2011 at 4:16 PM, Benson Margulies bimargul...@gmail.com wrote: I hate to have to say this, but I have concerns about the NOTICE file based on recent traffic here. LOL Unfortunately, that conversation left me with a giant headache and no clear idea. The issue is that there's a misc acknowledgement in there which is not a relocated IP notice. Are those OK, or not? (@Leo, help!) Not including something in the NOTICE that must be required might be a blocking problem but including just a little more than is necessary isn't IMHO. If it was a podling release with so much unnecessary stuff that it showed they didn't really understand the requirements maybe thats worth voting against so they go and sort it out but for something like this i think its ok to say sort it out later I am of the same opinion here. I think that some votes on this list are overly critical, often laden with personal opinions and not real Foundation requirements. This leads to a very frustrating experience to new podling members who are unable to tell the difference. 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
[VOTE] Release of Lucene.Net 2.9.4-incubating-RC3
All, I'm happy to announce that Lucene.Net 2.9.4-incubating-RC3 is available and ready for your testing and voting. Release candidate artifacts: http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC3/ SVN tag revision: https://svn.apache.org/repos/asf/incubator/lucene.net/tags/Lucene.Net_2_9_4_RC3/ The vote is open for 72 hours (we can extend this if people feel the US Thanksgiving holiday will impact the vote) Thanks to the Lucene contributors and committers for their hard work, and special thanks to Stefan for helping me get this release ready to roll out the door. Thanks, ~Prescott - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
