Re: Does Apache Have a 'Rule' Problem, or does the Incubator sometimes just make it look that way?
On Sat, Nov 26, 2011 at 11:14 AM, Robert Burrell Donkin wrote: > On Sat, Nov 26, 2011 at 10:10 AM, Christian Grobmeier > wrote: >> On Sat, Nov 26, 2011 at 10:38 AM, Robert Burrell Donkin >> wrote: +1 And while we are at it, reduce Roles and Rules to a minimum. >>> >>> Pruning is always useful but when the Incubator ran with fewer rules >>> and roles, the process ran much less smoothly which took much more >>> energy to supervise. I'm not sure that there's enough energy to >>> supervise so many projects without a smooth process. >> >> The process is not smooth, thats why more rules are currently in >> discussion. Supervising has already failed in some projects. Adding >> these new rules do not necessary mean that supervising is better; >> actually I doubt (and have said so). > > +1 > >> Have not seen a pruning recently. My feeling is we are adding more and >> more rules to a huge rule framework. And it feels always the same >> people are adding these rules and no one can stop them (not meant as >> an insult). > > It's easy to stop: just start a VOTE or -1 a documentation commit > > For example, the issue with the trademark check list item could be > dealt with either by an effort to provide detailed guidance or by > dropping the requirement from the check list by telling the board that > the Incubator expects the brand team to approve names for podlings. If > you have a strong opinion that we should just drop the requirement, > jump into the thread. > >> This is what frustrates me very much and will prevent me >> actually to waste more energy in rules/politics discussions. > > Then focus your energy on doing, not discussing. Find one example > which illustrates your criticism and prune it. > >> I have no suggestions how to do better at the moment. But adding more >> and more rules cannot be the solution. I mean this is no fun. We are >> acting like a company more and more. The time you need to understand, >> teach and develop this rules are not to underestimate. We even have a >> code of conduct. That all is no prime time stuff anymore and no fun. >> And in my world, Open Source is not only a business model, it is fun >> at first place. And this means, less but efficient rules. > > Rules based systems fail to scale > > > >> Cheers, >> Christian >> who is very frustrated at the recent developments on the ASF. > > Then jump in and get involved with improving stuff :-) > > Robert > Yeah I agree with Robert though I do acknowledge that it can be really hard to get some things changed and you may need a thick skin and lots of perseverance. But lets try to demonstrate its possible - Christian tell us three things you'd like changed and we'll pick one and try to fix it right here right now just to show it can be done. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Does Apache Have a 'Rule' Problem, or does the Incubator sometimes just make it look that way?
On Sun, Nov 27, 2011 at 9:38 AM, ant elder wrote: > I do acknowledge that it can be really > hard to get some things changed and you may need a thick skin and lots > of perseverance. But lets try to demonstrate its possible - Christian > tell us three things you'd like changed and we'll pick one and try to > fix it right here right now just to show it can be done. +1 Robert (wondering about an Incubator F2F meetup for rules stomping) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Fwd: [RESULT][VOTE] Graduation to TLP
FYI -- Forwarded message -- From: Mohammad Nour El-Din Date: Sun, Nov 27, 2011 at 2:25 PM Subject: [RESULT][VOTE] Graduation to TLP To: bval-...@incubator.apache.org Hi... I announce that, according to [1], this [VOTE] has passed successfully. Will send a [RESULT] e-mail to the general@ [1] - http://incubator.apache.org/guides/graduation.html On Fri, Nov 4, 2011 at 3:04 AM, Niall Pemberton wrote: > +1 > > Niall > > On Mon, Oct 31, 2011 at 8:15 AM, Mohammad Nour El-Din > wrote: > > Mentors, time is ticking :), I believe having more mentor votes is > better. > > > > Kevin correct me if I am wrong please, cause if we don't need any more > > mentor votes I will proceed with this. > > > > On Sun, Oct 30, 2011 at 12:09 PM, Mohammad Nour El-Din > > wrote: > >> Mentors... > >> > >> Do we need more mentors voting ? > >> > >> We only got Kevan's vote! > >> > >> On Sun, Oct 30, 2011 at 11:54 AM, Mohammad Nour El-Din > >> wrote: > >>> OK going to close that [VOTE], announce result and share it with > general@i.a.o. > >>> > >>> On Tue, Oct 25, 2011 at 6:30 PM, Mark Struberg > wrote: > Hoops, didn't notice that. Always thought you were. > > Imo we should fix this quickly as you almost did the most commits the > last year ;) > > > LieGrue, > strub > > > > - Original Message - > > From: Matt Benson > > To: bval-...@incubator.apache.org > > Cc: > > Sent: Tuesday, October 25, 2011 6:24 PM > > Subject: Re: [VOTE] Graduation to TLP > > > > Oh, note that not being a member of the PPMC, my vote is non-binding. > > But my vote IS binding with the IPMC. :D > > > > Matt > > > > On Mon, Oct 24, 2011 at 2:16 PM, Matt Benson > wrote: > >> Here's my +1. > >> > >> Matt > >> > >> On Mon, Oct 24, 2011 at 2:12 PM, Gerhard Petracek > > wrote: > >>> +1 > >>> > >>> regards, > >>> gerhard > >>> > >>> > >>> > >>> 2011/10/24 Mohammad Nour El-Din > >>> > Hi... > > There has been a community consensus [1], [2] and [3] about the > readiness of Bean Validation to graduate as a TLP Apache project. > Based on that and according to [4], I am starting this [VOTE] > > thread > for Bean Validation to be discussed at front next board meeting, > 16 > November 2011, to be graduated to an Apache TLP. > > The [VOTE] will be open for at least 72 hours. > > *NOTE*: The graduation process includes other steps which will be > taken over and discussed in other e-mails. > > [1] - http://markmail.org/message/xlaeckve2u7g7yms > [2] - http://markmail.org/message/zbj5e2lrje7hvoxy > [3] - http://markmail.org/message/plz6x3v3yyhcrnkc > [4] - http://incubator.apache.org/guides/graduation.html > > -- > Thanks > - Mohammad Nour > - LinkedIn: http://www.linkedin.com/in/mnour > - Blog: http://tadabborat.blogspot.com > > "Life is like riding a bicycle. To keep your balance you must > > keep moving" > - Albert Einstein > > >>> > >> > > > > >>> > >>> > >>> > >>> -- > >>> Thanks > >>> - Mohammad Nour > >>> > >>> "Life is like riding a bicycle. To keep your balance you must keep > moving" > >>> - Albert Einstein > >>> > >> > >> > >> > >> -- > >> Thanks > >> - Mohammad Nour > >> > >> "Life is like riding a bicycle. To keep your balance you must keep > moving" > >> - Albert Einstein > >> > > > > > > > > -- > > Thanks > > - Mohammad Nour > > > > "Life is like riding a bicycle. To keep your balance you must keep > moving" > > - Albert Einstein > > > -- Thanks - Mohammad Nour "Life is like riding a bicycle. To keep your balance you must keep moving" - Albert Einstein -- Thanks - Mohammad Nour Author of (WebSphere Application Server Community Edition 2.0 User Guide) http://www.redbooks.ibm.com/abstracts/sg247585.html - LinkedIn: http://www.linkedin.com/in/mnour - Blog: http://tadabborat.blogspot.com "Life is like riding a bicycle. To keep your balance you must keep moving" - Albert Einstein "Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best." - Clean Code: A Handbook of Agile Software Craftsmanship "Stay hungry, stay foolish." - Steve Jobs
Re: [RESULT][VOTE] Graduation to TLP
Apologies for not adding more details: This [VOTE] has passed with 11 +1(s), no 0(s) and no -1(s), details: Gerhard Petracek - gpetracek (*, +) Mark Struberg - struberg (*, #, +) Matt Benson - mbenson (#, +) David Jencks - djencks (#, +) Roman Stumm - romanstumm (*, +) Simone Tripodi - simonetripodi (*, +) Mohammad Nour El-Din - mnour (*, +, #) Albert Lee - allee8285 (+) Kevan Miller - kevan (*, +, @, #) Luciano Resende - lresende (*, +, @, #) Niall Pemberton - niallp (*, +, @, #) Where: -- * PPMC + Committer @ Mentor # IPMC On Sun, Nov 27, 2011 at 2:26 PM, Mohammad Nour El-Din wrote: > FYI > > -- Forwarded message -- > From: Mohammad Nour El-Din > Date: Sun, Nov 27, 2011 at 2:25 PM > Subject: [RESULT][VOTE] Graduation to TLP > To: bval-...@incubator.apache.org > > > Hi... > >I announce that, according to [1], this [VOTE] has passed successfully. > > Will send a [RESULT] e-mail to the general@ > > [1] - http://incubator.apache.org/guides/graduation.html > > > On Fri, Nov 4, 2011 at 3:04 AM, Niall Pemberton > wrote: > >> +1 >> >> Niall >> >> On Mon, Oct 31, 2011 at 8:15 AM, Mohammad Nour El-Din >> wrote: >> > Mentors, time is ticking :), I believe having more mentor votes is >> better. >> > >> > Kevin correct me if I am wrong please, cause if we don't need any more >> > mentor votes I will proceed with this. >> > >> > On Sun, Oct 30, 2011 at 12:09 PM, Mohammad Nour El-Din >> > wrote: >> >> Mentors... >> >> >> >> Do we need more mentors voting ? >> >> >> >> We only got Kevan's vote! >> >> >> >> On Sun, Oct 30, 2011 at 11:54 AM, Mohammad Nour El-Din >> >> wrote: >> >>> OK going to close that [VOTE], announce result and share it with >> general@i.a.o. >> >>> >> >>> On Tue, Oct 25, 2011 at 6:30 PM, Mark Struberg >> wrote: >> Hoops, didn't notice that. Always thought you were. >> >> Imo we should fix this quickly as you almost did the most commits >> the last year ;) >> >> >> LieGrue, >> strub >> >> >> >> - Original Message - >> > From: Matt Benson >> > To: bval-...@incubator.apache.org >> > Cc: >> > Sent: Tuesday, October 25, 2011 6:24 PM >> > Subject: Re: [VOTE] Graduation to TLP >> > >> > Oh, note that not being a member of the PPMC, my vote is >> non-binding. >> > But my vote IS binding with the IPMC. :D >> > >> > Matt >> > >> > On Mon, Oct 24, 2011 at 2:16 PM, Matt Benson >> wrote: >> >> Here's my +1. >> >> >> >> Matt >> >> >> >> On Mon, Oct 24, 2011 at 2:12 PM, Gerhard Petracek >> > wrote: >> >>> +1 >> >>> >> >>> regards, >> >>> gerhard >> >>> >> >>> >> >>> >> >>> 2011/10/24 Mohammad Nour El-Din >> >>> >> Hi... >> >> There has been a community consensus [1], [2] and [3] about >> the >> readiness of Bean Validation to graduate as a TLP Apache >> project. >> Based on that and according to [4], I am starting this [VOTE] >> > thread >> for Bean Validation to be discussed at front next board >> meeting, 16 >> November 2011, to be graduated to an Apache TLP. >> >> The [VOTE] will be open for at least 72 hours. >> >> *NOTE*: The graduation process includes other steps which will >> be >> taken over and discussed in other e-mails. >> >> [1] - http://markmail.org/message/xlaeckve2u7g7yms >> [2] - http://markmail.org/message/zbj5e2lrje7hvoxy >> [3] - http://markmail.org/message/plz6x3v3yyhcrnkc >> [4] - http://incubator.apache.org/guides/graduation.html >> >> -- >> Thanks >> - Mohammad Nour >> - LinkedIn: http://www.linkedin.com/in/mnour >> - Blog: http://tadabborat.blogspot.com >> >> "Life is like riding a bicycle. To keep your balance you must >> > keep moving" >> - Albert Einstein >> >> >>> >> >> >> > >> >> >>> >> >>> >> >>> >> >>> -- >> >>> Thanks >> >>> - Mohammad Nour >> >>> >> >>> "Life is like riding a bicycle. To keep your balance you must keep >> moving" >> >>> - Albert Einstein >> >>> >> >> >> >> >> >> >> >> -- >> >> Thanks >> >> - Mohammad Nour >> >> >> >> "Life is like riding a bicycle. To keep your balance you must keep >> moving" >> >> - Albert Einstein >> >> >> > >> > >> > >> > -- >> > Thanks >> > - Mohammad Nour >> > >> > "Life is like riding a bicycle. To keep your balance you must keep >> moving" >> > - Albert Einstein >> > >> > > > > -- > Thanks > - Mohammad Nour > > "Life is like riding a bicycle. To keep your balance you must keep moving" > - Albert Einstein > > > > > -- > Thanks > - Mohammad Nour > Author of (WebSphere Application Server Community Edition 2.0 User Guide) > http://www.redbooks.ibm.com/abstracts/sg247585.html > - LinkedIn: http://www.linkedin.co
concerns about high overhead in Apache incubator releases
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
Re: concerns about high overhead in Apache incubator releases
- Original Message - > From: Jun Rao > To: general@incubator.apache.org > Cc: kafka-...@incubator.apache.org > Sent: Sunday, November 27, 2011 2:13 PM > Subject: concerns about high overhead in Apache incubator releases > > Dear Apache members, [...] > 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. NO. The only time someone can claim to hold a veto over a release vote is when they are jibberjabbering about legal issues. NOTICE errors really don't risk a lawsuit from anyone, so those -1's are NOT vetoes. (Now that I've written that, it's possible/probable that someone will offer you a different opinion. What you should do as an incubating participant is challenge any such opinions with a reference to supporting website documentation.) Yes, I share your frustrations with the whole experience here in general. However, IME good and active mentors can mitigate a lot of the problems you face as a podling. Yes there will be times when we have to argue things out, but that aspect is one of the features of an org that tries to stay flexible and not overrely on an abundance of rules set a long time ago. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Does Apache Have a 'Rule' Problem, or does the Incubator sometimes just make it look that way?
On Sun, Nov 27, 2011 at 11:47 AM, Robert Burrell Donkin wrote: > > > On Sun, Nov 27, 2011 at 9:38 AM, ant elder wrote: >> I do acknowledge that it can be really >> hard to get some things changed and you may need a thick skin and lots >> of perseverance. But lets try to demonstrate its possible - Christian >> tell us three things you'd like changed and we'll pick one and try to >> fix it right here right now just to show it can be done. > > +1 > > Robert (wondering about an Incubator F2F meetup for rules stomping) Thanks to both to you for your kind words. Actually I feel a bit exhausted. I had several heavy discussions recently on the ASF and now I feel tired. Actually I can't say I have a thick skin. Speaking of the incubator changes, I have commented on the various threads about the new "Champion". Anyway, I actually think the Incubator needs a complete refactoring. So I can't speak of three items I would like to change, it is one big thing. I have not proposed it, because: no energy. Anyway... The Incubator has more than 100 IPMCs members. Constantly we are discussing about inactive mentors and overall lack of energy. Now the proposal is to extend the Champion term and to change the reporting to the board. I have asked: what do we expect to be on that reports? I even doubt, having an extended Champion role will cause people to be more active. We will still have missing reports and inactive mentors. Is it a surprise? No. We are 100. And we are not really a community. In fact, we are not even having a Meritocracy, as the other projects have. On other projects you need to earn merit and then you are elected as a committer and after earning more merit, you can become a PMC. At the incubator you earn merit somewhere, and once you are a Member, you can request membership on the IPMC. This is a huge exception to my knowledge. The incubator has many exceptions to standard procedures. That being said, we are a few active people here and many inactive. We are bloated and we cannot grow together as a group, because you can walk in and step out as you please. Question is, are we already unable to do incubators work? When there are not the mentioned, few active people on the projects, sometimes there is no mentoring at all. no actually we don't do a good job in my eyes (as said, a few exceptions of course). Or we don't have a clue if we do. I think we need to change our thinking and finally make up a community. Not only a list of loose coupled names. What if we would completely reboot the Incubator? Lets assume: 1) Every ASF committer on a non-podling project can serve as a mentor. The phrase "Search for a mentor" should be rephrased to: "search for an ASF committer who is willing to mentor your project". 2) Every ASF committer, who is mentoring a project and shows an interest in the Incubator, can be elected into the IPMC 3) A podling must have a Champion who helps to get the podling into the incubator. The champion can be every ASF committer. After the project has been accepted, the Champion is the one who needs to take care on reporting. The champion can be elected among ASF committers (which includes the podling committers). 4) Every podling must have an IPMC member reading the lists 5) Every mentor must sign the report. Mentors who do not sign the reports three times in a row are not to be considered active 6) Reporting schedule is at it is now. Podlings which fail to report three times in a row will be terminated, except they have good reasons 7) The IPMC makes up an report. As a community it is easier to report: who joined, who left, which podling was accepted, which one was not. 8) 3 IPMC votes are necessary to get a release out of the door. 3 Mentor votes are necessary. 9) New Podlings need to bring in their code within 3 months and CLAs/Grants, or incubation ends, except they good reasons. 10) Podlings in incubation for > 1 year need to be discussed quarterly by the IPMC. If there is no community, the IPMC might decide to terminate this podling, because: Community over Code. No Community, no Code. Now with just 10 rules we have a small IPMC taking care on the oversight. We do not need to let every mentor join the IPMC. In fact, we can get rid of the terms "Mentor" as this is the same as an ASF committer. The only exception is the "Champion", which in fact is serving as some kind of podling chair. We could even remove this term and call it "Podling Chair" which is more similar to what we have in other projects. How can we achieve this? Drop everybody from the IPMC list except our chair. Let him decide 5 people he knows who are active and they elect everybody else in who is active or has merit to join the IPMC. Probably there are some flaws in my thinking. But I think it is more efficient to make tabula rasa and try to be as near to a "standard apache project" as possible. Cheers, Christian - To unsubscribe, e-ma
Re: Does Apache Have a 'Rule' Problem, or does the Incubator sometimes just make it look that way?
Christian, Your proposals read to me as an elaboration and extension of some of the things I wrote. I think that Joe S's reaction to me, insofar as I understand it, makes some sense. Let's see if we can find a small group of members of the IPMC who are, in fact, willing to take seriously the task of supervision. If we can build such a group, it would be the logical nucleus of a reboot. If not, well, we've got other problems. --benson - 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 Nov 27, 2011, at 11:21 AM, Joe Schaefer wrote: > > > > > - Original Message - >> From: Jun Rao >> To: general@incubator.apache.org >> Cc: kafka-...@incubator.apache.org >> Sent: Sunday, November 27, 2011 2:13 PM >> Subject: concerns about high overhead in Apache incubator releases >> >> Dear Apache members, > > [...] > >> 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. > > NO. The only time someone can claim to hold a veto over a release vote is > when they are jibberjabbering about legal issues. NOTICE errors really > don't risk a lawsuit from anyone, so those -1's are NOT vetoes. If Joe didn't send this reply, I was about to myself. Here's 2 IPMC members that *do* agree on this: Joe is right, VETOs do *not* apply to releases of code. Hope that helps :-) Cheers, Chris ++ 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
Re:concerns about high overhead in Apache incubator releases
I sympathize with you're comments, however, I do want to point out that the problems are more to do with the Project committers and mentors than the process (although documentation can always be improved). As evidence I submit the Apache Rave poddling. This project made its first release within a couple of months of entering the incubator and has made a release every month since (I've not checked the dates, but I think this statement is accurate). Rave achieved this because Ate Douma (mentor) pointed to the appropriate docs. Matt Franklin read and understood the docs and did a release. Ate watched and advised throughout the process. The first trekker took a couple of cycles to get right. All sidewinder releases have been "simple". Please don't think I'm saying there is no value in your mail, there is. We can certainly improve in the support we provide. To address your specific points: 1. Your mentors are the example, if they are not guiding you ask if anyone here can help. 2. Different views of different people is difficult to resolve (see Roberts recent mail on the same topic). My advice is to understand the (admittedly confusing) documentation. If that doesn't help ask on the appropriate list (here if you don't know which list) 3. Clone or best mentors - sorry nothing better to suggest here 4. Get it right first time (mentors like Ate only let it go to a vote if it is ready, so 72 hours is called once only). Also know the rules with respect to release voting (see Joe's mail). Finally, and most importantly, help us improve the process (as you are doing with this mail). Given my responses above is there anything concrete you suggest we do to improve things (patches to docs seem like an obvious start - most of those docs are written by people who already do Apache releases). Ross Sent from my mobile device, please forgive errors and brevity. On Nov 27, 2011 7:13 PM, "Jun Rao" 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 >
Re: Does Apache Have a 'Rule' Problem, or does the Incubator sometimes just make it look that way?
On Sun, Nov 27, 2011 at 7:41 PM, Benson Margulies wrote: > Christian, > > Your proposals read to me as an elaboration and extension of some of > the things I wrote. I think that Joe S's reaction to me, insofar as I > understand it, makes some sense. > > Let's see if we can find a small group of members of the IPMC who are, > in fact, willing to take seriously the task of supervision. I have some personal understanding[1] of the level of individual commitment that would be required to supervise this many sub-projects. I recommend that anyone thinking about supporting this proposal subscribe to all the incubator lists and read every post for a month or two. > If we can build such a group, it would be the logical nucleus of a > reboot. If not, well, we've got other problems. Care to give some specifics? Robert [1] Back in Jakartaland - 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 Sun, Nov 27, 2011 at 7:21 PM, Joe Schaefer wrote: > > > > > - Original Message - >> From: Jun Rao >> To: general@incubator.apache.org >> Cc: kafka-...@incubator.apache.org >> Sent: Sunday, November 27, 2011 2:13 PM >> Subject: concerns about high overhead in Apache incubator releases >> >> Dear Apache members, > > [...] > >> 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. > > NO. The only time someone can claim to hold a veto over a release vote is > when they are jibberjabbering about legal issues. NOTICE errors really > don't risk a lawsuit from anyone, so those -1's are NOT vetoes. +1 > (Now that I've written that, it's possible/probable that someone will offer > you a different opinion. Sadly not today from me :-) > What you should do as an incubating participant > is challenge any such opinions with a reference to supporting website > documentation.) +1 Exceptional cases do turn up from time to time > Yes, I share your frustrations with the whole experience here in general. > However, IME good and active mentors can mitigate a lot of the problems > you face as a podling. Yes there will be times when we have to argue things > out, but that aspect is one of the features of an org that tries to stay > flexible and not overrely on an abundance of rules set a long time ago. +1 Robert - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Does Apache Have a 'Rule' Problem, or does the Incubator sometimes just make it look that way?
>> If we can build such a group, it would be the logical nucleus of a >> reboot. If not, well, we've got other problems. > > Care to give some specifics? > > Robert Robert, Between my posts at the top of this thread, and all the many messages on Joe's (I think) thread about the board wanting to delegate supervision, and my writing on members@ about the pathology of a large group self-organizing on a mailing list with no one acting as chair or moderator of the discussion, I think that there's plenty of fodder here, and no shortage of it from me. Is there really anything else to add? I wish that the IPMC chair had more time to devote to the working of this, but he apparently does not. One of our many ways of wasting time and energy around here is to have five threads on the same topic. - 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 Sun, Nov 27, 2011 at 8:09 PM, Mattmann, Chris A (388J) wrote: > On Nov 27, 2011, at 11:21 AM, Joe Schaefer wrote: > >> >> >> >> >> - Original Message - >>> From: Jun Rao >>> To: general@incubator.apache.org >>> Cc: kafka-...@incubator.apache.org >>> Sent: Sunday, November 27, 2011 2:13 PM >>> Subject: concerns about high overhead in Apache incubator releases >>> >>> Dear Apache members, >> >> [...] >> >>> 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. >> >> NO. The only time someone can claim to hold a veto over a release vote is >> when they are jibberjabbering about legal issues. NOTICE errors really >> don't risk a lawsuit from anyone, so those -1's are NOT vetoes. > > If Joe didn't send this reply, I was about to myself. Here's 2 IPMC members > that > *do* agree on this: Joe is right, VETOs do *not* apply to releases of code. Any legal issue serious enough to VETO a release would require code access to be blocked and all discussions taken private. Anything short of this isn't a VETO. Robert - 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
One piece of advice I've been kicking myself for not offering more aggressively is this: ask for review before you bother to put up a candidate for a vote. It's a lot less work. On Sun, Nov 27, 2011 at 3:47 PM, Robert Burrell Donkin wrote: > On Sun, Nov 27, 2011 at 7:21 PM, Joe Schaefer wrote: >> >> >> >> >> - Original Message - >>> From: Jun Rao >>> To: general@incubator.apache.org >>> Cc: kafka-...@incubator.apache.org >>> Sent: Sunday, November 27, 2011 2:13 PM >>> Subject: concerns about high overhead in Apache incubator releases >>> >>> Dear Apache members, >> >> [...] >> >>> 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. >> >> NO. The only time someone can claim to hold a veto over a release vote is >> when they are jibberjabbering about legal issues. NOTICE errors really >> don't risk a lawsuit from anyone, so those -1's are NOT vetoes. > > +1 > >> (Now that I've written that, it's possible/probable that someone will offer >> you > > a different opinion. > > Sadly not today from me :-) > >> What you should do as an incubating participant >> is challenge any such opinions with a reference to supporting website >> documentation.) > > +1 > > Exceptional cases do turn up from time to time > >> Yes, I share your frustrations with the whole experience here in general. >> However, IME good and active mentors can mitigate a lot of the problems >> you face as a podling. Yes there will be times when we have to argue things >> out, but that aspect is one of the features of an org that tries to stay >> flexible and not overrely on an abundance of rules set a long time ago. > > +1 > > 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: concerns about high overhead in Apache incubator releases
On Sun, Nov 27, 2011 at 7:13 PM, Jun Rao 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. (Thanks to Joe for setting the VETO issue straight) IMO The solution to the NOTICE and LICENSE is build automation with more complete rules covering the common licenses. This is do-able and we're working on it but we're short of resources (my recovery is progressing well and hopefully Jochen will get well soon). If anyone could spare a few cycles to help, that'd be great. Robert - 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
Sorry screaming kids prevented me from reviewing properly. one sentence was made incomprehensible by autocorrect... Sent from my mobile device, please forgive errors and brevity. On Nov 27, 2011 8:09 PM, "Ross Gardler" wrote: > > I sympathize with you're comments, however, I do want to point out that the problems are more to do with the Project committers and mentors than the process (although documentation can always be improved). > > As evidence I submit the Apache Rave poddling. This project made its first release within a couple of months of entering the incubator and has made a release every month since (I've not checked the dates, but I think this statement is accurate). > > Rave achieved this because Ate Douma (mentor) pointed to the appropriate docs. Matt Franklin read and understood the docs and did a release. Ate watched and advised throughout the process. The first trekker took a couple of cycles to get right. All sidewinder releases have been "simple". > The first release took a couple of cycles to get right. All subsequent releases have been "simple". > Please don't think I'm saying there is no value in your mail, there is. We can certainly improve in the support we provide. To address your specific points: > > 1. Your mentors are the example, if they are not guiding you ask if anyone here can help. > > 2. Different views of different people is difficult to resolve (see Roberts recent mail on the same topic). My advice is to understand the (admittedly confusing) documentation. If that doesn't help ask on the appropriate list (here if you don't know which list) > > 3. Clone or best mentors - sorry nothing better to suggest here > > 4. Get it right first time (mentors like Ate only let it go to a vote if it is ready, so 72 hours is called once only). Also know the rules with respect to release voting (see Joe's mail). > > Finally, and most importantly, help us improve the process (as you are doing with this mail). Given my responses above is there anything concrete you suggest we do to improve things (patches to docs seem like an obvious start - most of those docs are written by people who already do Apache releases). > > Ross > > Sent from my mobile device, please forgive errors and brevity. > > On Nov 27, 2011 7:13 PM, "Jun Rao" 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 experie
Re: concerns about high overhead in Apache incubator releases
On Nov 27, 2011, at 12:53 PM, Robert Burrell Donkin wrote: >>> >>> NO. The only time someone can claim to hold a veto over a release vote is >>> when they are jibberjabbering about legal issues. NOTICE errors really >>> don't risk a lawsuit from anyone, so those -1's are NOT vetoes. >> >> If Joe didn't send this reply, I was about to myself. Here's 2 IPMC members >> that >> *do* agree on this: Joe is right, VETOs do *not* apply to releases of code. > > Any legal issue serious enough to VETO a release would require code > access to be blocked and all discussions taken private. Anything short > of this isn't a VETO. Agreed! Uh-oh, that's *three* IPMC members that agree! Shocking! :-) Can we get 4? LOL. Cheers, Chris (Mr. In-a-great-mood-after-the-USC-game-last-night) ++ 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
Re: concerns about high overhead in Apache incubator releases
- Original Message - > From: Robert Burrell Donkin > To: general@incubator.apache.org > Cc: Joe Schaefer ; "kafka-...@incubator.apache.org" > > Sent: Sunday, November 27, 2011 3:53 PM > Subject: Re: concerns about high overhead in Apache incubator releases > > On Sun, Nov 27, 2011 at 8:09 PM, Mattmann, Chris A (388J) > wrote: >> On Nov 27, 2011, at 11:21 AM, Joe Schaefer wrote: >> >>> >>> >>> >>> >>> - Original Message - From: Jun Rao To: general@incubator.apache.org Cc: kafka-...@incubator.apache.org Sent: Sunday, November 27, 2011 2:13 PM Subject: concerns about high overhead in Apache incubator releases Dear Apache members, >>> >>> [...] >>> 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. >>> >>> NO. The only time someone can claim to hold a veto over a release vote > is >>> when they are jibberjabbering about legal issues. NOTICE errors really >>> don't risk a lawsuit from anyone, so those -1's are NOT vetoes. >> >> If Joe didn't send this reply, I was about to myself. Here's 2 IPMC > members that >> *do* agree on this: Joe is right, VETOs do *not* apply to releases of code. > > Any legal issue serious enough to VETO a release would require code > access to be blocked and all discussions taken private. Anything short > of this isn't a VETO. I wouldn't go that far. I mean if a podling is trying to ship GPL code or hasn't completed its IP checklist, it shouldn't be releasing software from the ASF yet. Those aren't issues that require privacy. - 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
I guess one of the sticking points in all this is the notion that a release MUST nominally comply with all Apache policies. Formally, that means it meets the standards set out in http://www.apache.org/dev/release.html as well as all of our adopted legal policies. That we tend to sometimes debate whether something meets the definition of ASF policy is problematic, but I don't see an easy soln to that other than to elevate the discussion to either legal-discuss@ (in the case of legal policy disputes) or to infrastructure@ or site-dev@ or even board@ if all else fails (in the caseof disputes about release policy). That we have recentlyjust gone down that route is indicative not of failure on the IPMC's part, but just the normal tide of reviewing and questioning what the published documentation actually says. That people with different experiences will read that documentation as meaning different things is only natural, and the search for clearer and more universal language is a welcome thing, but it's a lot harder than it looks ;-). - Original Message - > From: "Mattmann, Chris A (388J)" > To: "general@incubator.apache.org" > Cc: Joe Schaefer ; "kafka-...@incubator.apache.org" > > Sent: Sunday, November 27, 2011 4:04 PM > Subject: Re: concerns about high overhead in Apache incubator releases > > On Nov 27, 2011, at 12:53 PM, Robert Burrell Donkin wrote: NO. The only time someone can claim to hold a veto over a release > vote is when they are jibberjabbering about legal issues. NOTICE errors > really don't risk a lawsuit from anyone, so those -1's are NOT > vetoes. >>> >>> If Joe didn't send this reply, I was about to myself. Here's 2 > IPMC members that >>> *do* agree on this: Joe is right, VETOs do *not* apply to releases of > code. >> >> Any legal issue serious enough to VETO a release would require code >> access to be blocked and all discussions taken private. Anything short >> of this isn't a VETO. > > Agreed! Uh-oh, that's *three* IPMC members that agree! Shocking! :-) > > Can we get 4? LOL. > > Cheers, > Chris > (Mr. In-a-great-mood-after-the-USC-game-last-night) > > ++ > 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 > - 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 Sun, Nov 27, 2011 at 9:05 PM, Joe Schaefer wrote: >> From: Robert Burrell Donkin >> Any legal issue serious enough to VETO a release would require code >> access to be blocked and all discussions taken private. Anything short >> of this isn't a VETO. > > I wouldn't go that far. I mean if a podling is trying to ship GPL code or > hasn't > completed its IP checklist, it shouldn't be releasing software from the ASF > yet. Those aren't issues that require privacy. +1 in principle But in practice, this tends to be about managing legal risk to the foundation. In order to get time to allow our counsel to give legal advice, infra would probably be asked (by the legal VP or a group of 3 committee members) to block access whilst the internal legal and board decide how to sort out the mess. (Or at least that's the way it's worked in the past.) Quite a big stick, which makes VETO a tough call to make. For me, shipping GPL code or incomplete IP check would be -1 but not VETO issues. For me, examples of serious legal issues would be an email threatening legal action if a release goes ahead but even this is controversial. Robert - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Rebooting the Incubator? (was: Does Apache Have a 'Rule' Problem...)
On Sun, Nov 27, 2011 at 8:41 PM, Benson Margulies wrote: > ...Let's see if we can find a small group of members of the IPMC who are, > in fact, willing to take seriously the task of supervision There is such a group already - even though that might be a small percentage of the IPMC membership (because that PMC is big), there is a sizable group that does take supervision seriously. > > ...If we can build such a group, it would be the logical nucleus of a > reboot. If not, well, we've got other problems... I don't think a reboot is needed. Some specific points need improving (how to cope with missing reports and inactive mentors, more efficient reporting to the board, clarifying our docs) but that doesn't mean the incubator is broken. Working in small, concrete, reversible steps is usually the best way to get things done at the ASF - let's just do that. -Bertrand P.S. Sensationalistic bloggers: if you write about how broken our Incubator is, you owe me a beer for this subject line. Thanks. - 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
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. In some ways, I'd expect the incubator to be more conservative (since the IP is new) and in other ways less (we all know that a NOTICE blivet will never be a legal armegeddon). IPMC members vote -1 for even small details in policy (and, yes, for big ones two). Podlings and mentors sure appear to have been reading from the script in my first sentence. I'm not opposed to reminding people that only a VETO is a hard stop, but is there also room to remind people that not every misplaced comma deserves even a -1? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Rebooting the Incubator? (was: Does Apache Have a 'Rule' Problem...)
I guess I sent one email too many here. On the other thread, I was perfectly happy to join the nacent consensus that the willing should step up and supervise, as opposed to any sort of structural change. I'm back there now. And, anyway, all if this is a hijack. This thread started as 'how can we make it easier for podlings and even mentors to navigate.' That question has been answered: IMPROVE THE DOC. So could we please treat this thread as CLOSED? If you want to plan a palace coup, why not start a new thread? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Rebooting the Incubator? (was: Does Apache Have a 'Rule' Problem...)
On Sun, Nov 27, 2011 at 9:25 PM, Bertrand Delacretaz wrote: > On Sun, Nov 27, 2011 at 8:41 PM, Benson Margulies > wrote: >> ...Let's see if we can find a small group of members of the IPMC who are, >> in fact, willing to take seriously the task of supervision > > There is such a group already - even though that might be a small > percentage of the IPMC membership (because that PMC is big), there is > a sizable group that does take supervision seriously. +1 I worry that we now spend too little time working together. And that this means we're losing our sense of community. I wonder whether starting to meet F2F might be useful. >> ...If we can build such a group, it would be the logical nucleus of a >> reboot. If not, well, we've got other problems... > > I don't think a reboot is needed. Some specific points need improving > (how to cope with missing reports and inactive mentors, more efficient > reporting to the board, clarifying our docs) but that doesn't mean the > incubator is broken. +1 One lesson I've learned over the last few months is that to live, the Incubator needs to continue to grow and evolve. Only by working together to improve our imperfect do we feel like a community. We should be more open to new ideas and experiments: if they don't work out, we can always roll them back again. > Working in small, concrete, reversible steps is usually the best way > to get things done at the ASF - let's just do that. +1 > P.S. Sensationalistic bloggers: if you write about how broken our > Incubator is, you owe me a beer for this subject line. Thanks. :-) Robert - 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 wrote: > > On Nov 25, 2011, at 8:32 AM, ant elder wrote: > >> On Fri, Nov 25, 2011 at 4:16 PM, Benson Margulies >> 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
Re: concerns about high overhead in Apache incubator releases
Ross is 100% in identifying mentors as critical to a smooth release. More specifically, mentors familiar with what a project is likely to face in an Incubator vote. I'm sorry to say that I was an AWOL mentor for the first 5 RCs. I still wouldn't have anticipated the objections from the IPMC that- as Jun points out- were true of every release. By way of illustration, take the debate on source releases that spread outside of general@ and into other foundation lists. It took over three days to get a yes/no answer from *anyone*, and while hundreds of words on why the answer could be yes were written, the closest we got to a definitive answer on foundation policy was a link to something Roy said in 2009 on legal-discuss@. And none of that discussion is available to podlings! Even that didn't speak to our question. RC6 contained all the source and unit tests, but it also included artifacts of a successful build. The discussion was focused on minimum requirements, while RC6 was rejected (in part) for including too much. The incubator documentation on releases is over 10k words with at least 80 TODO items. So while I agree that mentors' familiarity with the process is critical to smooth releases, I reject the RTFM suggestion as trolling. Further, it's not policy when objections *not* in the documentation get added and cited ex post facto. In some of these threads, the Incubator is confused with an ASF project. This is incoherent given its size and composition. The Incubator is a curriculum, not a community. And if we're going to continue to use metaphors like "graduation" and "mentor", then the requirements for a release must 1) be stated crisply and succinctly 2) be separated from best practices, no matter how widely practiced and highly regarded some of those procedures may be. As examples from recent release votes: a particular sequence of transformations in subversion for composing a release is not a requirement. Small tarballs are not a requirement. Correctly composing the LICENSE, DISCLAIMER, and NOTICE files are requirements. If I've learned one thing from trying to advise on a release, it's that I know a lot less than I thought I did. I might be an acceptable teaching assistant, but of the 100+ IPMC members, there are only a handful of tenured members who can distinguish lore from canon. I (and others, no doubt) would happily furnish pints to IPMC members who can distill what already exists into a small set of rules, rather than augmenting the existing Leviadocs. -C On Sun, Nov 27, 2011 at 12:09 PM, Ross Gardler wrote: > I sympathize with you're comments, however, I do want to point out that the > problems are more to do with the Project committers and mentors than the > process (although documentation can always be improved). > > As evidence I submit the Apache Rave poddling. This project made its first > release within a couple of months of entering the incubator and has made a > release every month since (I've not checked the dates, but I think this > statement is accurate). > > Rave achieved this because Ate Douma (mentor) pointed to the appropriate > docs. Matt Franklin read and understood the docs and did a release. Ate > watched and advised throughout the process. The first trekker took a couple > of cycles to get right. All sidewinder releases have been "simple". > > Please don't think I'm saying there is no value in your mail, there is. We > can certainly improve in the support we provide. To address your specific > points: > > 1. Your mentors are the example, if they are not guiding you ask if anyone > here can help. > > 2. Different views of different people is difficult to resolve (see Roberts > recent mail on the same topic). My advice is to understand the (admittedly > confusing) documentation. If that doesn't help ask on the appropriate list > (here if you don't know which list) > > 3. Clone or best mentors - sorry nothing better to suggest here > > 4. Get it right first time (mentors like Ate only let it go to a vote if it > is ready, so 72 hours is called once only). Also know the rules with > respect to release voting (see Joe's mail). > > Finally, and most importantly, help us improve the process (as you are > doing with this mail). Given my responses above is there anything concrete > you suggest we do to improve things (patches to docs seem like an obvious > start - most of those docs are written by people who already do Apache > releases). > > Ross > > Sent from my mobile device, please forgive errors and brevity. > On Nov 27, 2011 7:13 PM, "Jun Rao" 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 th
Re: concerns about high overhead in Apache incubator releases
OK, I'm sorry, but leviadocs??!! I'll buy you a beer for that AWESOME word :-) BTW, I agree with all of your points below, dude. In fact, to add to them, I would suggest my approach is simply what i learned from Justin, Jukka, Joe S. and others -- teach the project how to build community, to learn how to identify "wants" from "requirements", to push back when necessary (as Joe S. mentioned), all the while shielding it from the wild west that's general@, and all the while trying to check items off the list towards graduation. It's really more of a navigation process more than a learning process, unfortunately in my experience. And no, the answer to me is not improving the docs. They've been there forever. They've had tons of work on them from many many members. Plus, software engineers and open source geeks like us don't really do well reading documentation. The answer to me is figuring out how to distill experience into action, without handing someone all 7 years of the Defence Against the Dark Arts books and asking them to brush up on them before casting any spells. I honestly find myself agreeing with some of the folks on the thread that have suggested an IPMC reboot. I would first start by identifying the roles or types of mentors that are present and required in the IPMC, perhaps as an initial list: 1. those that are good at release management 2. those that get the ALv2 license requirements 3. those that are good at encouraging the growth of community by adding new committers/PPMC members. 4. those that are good at filing board reports, or project reports. 5. those that are actually technical mentors, and who have an understanding of the code going on in the projects. 6. those that have been at the ASF for a LONG time, e.g., the "old guard", that can provide context and JFDI attitude to resolve disputes. I'm sure there's more types of mentors than this, but I'm just reeling off some of the types I've seen. And usually the roles are disjoint and not provided by a single person. Then, after identifying these role types, I'd get 3 mentors for each type, just so there are backups and folks who can do the work. So let's say I missed 5 roles, so that would be ~11 roles, times 3, ~33 members of the IPMC. Then I'd make sure that each IPMC mentor is on at least 3 Incubator projects, watching over them. We could initially start out with disjoint partitioning, but then ease up and allow the IPMC'ers to have overlapping projects they watch. I'd then do away with the podling specific reports as has been suggested earlier either on this thread, or on one of the related ones, and then simply have an IPMC report to the effect of: Project X hasn't made a release in > 9 months, mentor Y is prodding them on the dev list Project Z is being attic'd Project A has added a new PPMC member Project B presented at ApacheCon NA on Topic D I'd also watch out for IPMC members that are too overcommitted. I myself, am overcommitted, but I do try and make sure I at least contribute monthly to the several projects that I mentor by at least making contributions in one of those 6 mentor-type functions I listed above. So, anyways, while I agree in principle that Apache usually benefits from small, incremental change, in revertible steps, what these threads have shown me over the past few weeks is that the experience within the Incubator for folks is largely too inconsistent, too unwieldy, and filled with overhead that is causing folks to have a difficult time bringing their software to the ASF, and that perhaps grand change may be needed, beyond small revertible steps. That's a big concern for me, and I hope it is for the rest of the ASF members who want folks to keep bringing their projects here. Cheers, Chris On Nov 27, 2011, at 4:46 PM, Chris Douglas wrote: > Ross is 100% in identifying mentors as critical to a smooth release. > More specifically, mentors familiar with what a project is likely to > face in an Incubator vote. > > I'm sorry to say that I was an AWOL mentor for the first 5 RCs. I > still wouldn't have anticipated the objections from the IPMC that- as > Jun points out- were true of every release. By way of illustration, > take the debate on source releases that spread outside of general@ and > into other foundation lists. It took over three days to get a yes/no > answer from *anyone*, and while hundreds of words on why the answer > could be yes were written, the closest we got to a definitive answer > on foundation policy was a link to something Roy said in 2009 on > legal-discuss@. And none of that discussion is available to podlings! > > Even that didn't speak to our question. RC6 contained all the source > and unit tests, but it also included artifacts of a successful build. > The discussion was focused on minimum requirements, while RC6 was > rejected (in part) for including too much. > > The incubator documentation on releases is over 10k words with at > least 80
Re: concerns about high overhead in Apache incubator releases
I did not see anyone say RTFM, did you? As I have repeatedly said, the documentation is just as much to keep the IPMC in line as it is to keep our podlings. And yes we do need to distinguish between teaching podlings best practices, which can be done over time, and performing policy enforcement, which must be done asap. Yes it's long and painful prose written by many different authors, but simply complaining about it isn't going to get us anywhere. We've known about the problems for years now; what we need is for people to step up, in a whine-free way, and collaborate with each other. Are you game? - Original Message - > From: Chris Douglas > To: general@incubator.apache.org > Cc: kafka-...@incubator.apache.org > Sent: Sunday, November 27, 2011 7:46 PM > Subject: Re: concerns about high overhead in Apache incubator releases > > Ross is 100% in identifying mentors as critical to a smooth release. > More specifically, mentors familiar with what a project is likely to > face in an Incubator vote. > > I'm sorry to say that I was an AWOL mentor for the first 5 RCs. I > still wouldn't have anticipated the objections from the IPMC that- as > Jun points out- were true of every release. By way of illustration, > take the debate on source releases that spread outside of general@ and > into other foundation lists. It took over three days to get a yes/no > answer from *anyone*, and while hundreds of words on why the answer > could be yes were written, the closest we got to a definitive answer > on foundation policy was a link to something Roy said in 2009 on > legal-discuss@. And none of that discussion is available to podlings! > > Even that didn't speak to our question. RC6 contained all the source > and unit tests, but it also included artifacts of a successful build. > The discussion was focused on minimum requirements, while RC6 was > rejected (in part) for including too much. > > The incubator documentation on releases is over 10k words with at > least 80 TODO items. So while I agree that mentors' familiarity with > the process is critical to smooth releases, I reject the RTFM > suggestion as trolling. Further, it's not policy when objections *not* > in the documentation get added and cited ex post facto. > > In some of these threads, the Incubator is confused with an ASF > project. This is incoherent given its size and composition. The > Incubator is a curriculum, not a community. And if we're going to > continue to use metaphors like "graduation" and "mentor", > then the > requirements for a release must 1) be stated crisply and succinctly 2) > be separated from best practices, no matter how widely practiced and > highly regarded some of those procedures may be. > > As examples from recent release votes: a particular sequence of > transformations in subversion for composing a release is not a > requirement. Small tarballs are not a requirement. Correctly composing > the LICENSE, DISCLAIMER, and NOTICE files are requirements. > > If I've learned one thing from trying to advise on a release, it's > that I know a lot less than I thought I did. I might be an acceptable > teaching assistant, but of the 100+ IPMC members, there are only a > handful of tenured members who can distinguish lore from canon. I (and > others, no doubt) would happily furnish pints to IPMC members who can > distill what already exists into a small set of rules, rather than > augmenting the existing Leviadocs. -C > > On Sun, Nov 27, 2011 at 12:09 PM, Ross Gardler > wrote: >> I sympathize with you're comments, however, I do want to point out that > the >> problems are more to do with the Project committers and mentors than the >> process (although documentation can always be improved). >> >> As evidence I submit the Apache Rave poddling. This project made its first >> release within a couple of months of entering the incubator and has made a >> release every month since (I've not checked the dates, but I think this >> statement is accurate). >> >> Rave achieved this because Ate Douma (mentor) pointed to the appropriate >> docs. Matt Franklin read and understood the docs and did a release. Ate >> watched and advised throughout the process. The first trekker took a couple >> of cycles to get right. All sidewinder releases have been > "simple". >> >> Please don't think I'm saying there is no value in your mail, there > is. We >> can certainly improve in the support we provide. To address your specific >> points: >> >> 1. Your mentors are the example, if they are not guiding you ask if anyone >> here can help. >> >> 2. Different views of different people is difficult to resolve (see Roberts >> recent mail on the same topic). My advice is to understand the (admittedly >> confusing) documentation. If that doesn't help ask on the appropriate > list >> (here if you don't know which list) >> >> 3. Clone or best mentors - sorry nothing better to suggest here >> >> 4. Get it right first time (men
Re: concerns about high overhead in Apache incubator releases
On 28 November 2011 00:46, Chris Douglas wrote: > I reject the RTFM > suggestion as trolling. I never aid RTFM. I said the documentation in conjunction with mentors guidance. I also said the documentation needs work and asked for specific pointers as to where. Furthermore I supported Joe's comments with respect to knowing what the voting rules are. If a mentor allows a release to stop because of a minor tweak required here and there then it is a failing of the mentor not the process (and please don't take this personally, only a couple of weeks ago *exactly* this happened to a project I am mentoring and I allowed it to stop the release. I'm not pointing fingers, I'm simply stating how it is for all of us). > The > Incubator is a curriculum, not a community. This I can agree with. There are other threads underway right now addressing this very point. Do you think the proposals floating around right now will help address this and provide adequate support to mentors? Ross - 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 Sun, Nov 27, 2011 at 5:33 PM, Joe Schaefer wrote: > I did not see anyone say RTFM, did you? That's how I read Ross's account of the Rave project (mentor pointed to the docs, RM read them, monthly releases bloomed). I don't think that was an ungenerous reading, but characterizing it as RTFM may have misrepresented its tone. > Yes it's long and painful prose written by many different authors, > but simply complaining about it isn't going to get us anywhere. We've > known about the problems for years now; what we need is for people > to step up, in a whine-free way, and collaborate with each other. > > Are you game? Sure, I'll offer to help with drafting. Where is a good place to coordinate that? -C > - Original Message - >> From: Chris Douglas >> To: general@incubator.apache.org >> Cc: kafka-...@incubator.apache.org >> Sent: Sunday, November 27, 2011 7:46 PM >> Subject: Re: concerns about high overhead in Apache incubator releases >> >> Ross is 100% in identifying mentors as critical to a smooth release. >> More specifically, mentors familiar with what a project is likely to >> face in an Incubator vote. >> >> I'm sorry to say that I was an AWOL mentor for the first 5 RCs. I >> still wouldn't have anticipated the objections from the IPMC that- as >> Jun points out- were true of every release. By way of illustration, >> take the debate on source releases that spread outside of general@ and >> into other foundation lists. It took over three days to get a yes/no >> answer from *anyone*, and while hundreds of words on why the answer >> could be yes were written, the closest we got to a definitive answer >> on foundation policy was a link to something Roy said in 2009 on >> legal-discuss@. And none of that discussion is available to podlings! >> >> Even that didn't speak to our question. RC6 contained all the source >> and unit tests, but it also included artifacts of a successful build. >> The discussion was focused on minimum requirements, while RC6 was >> rejected (in part) for including too much. >> >> The incubator documentation on releases is over 10k words with at >> least 80 TODO items. So while I agree that mentors' familiarity with >> the process is critical to smooth releases, I reject the RTFM >> suggestion as trolling. Further, it's not policy when objections *not* >> in the documentation get added and cited ex post facto. >> >> In some of these threads, the Incubator is confused with an ASF >> project. This is incoherent given its size and composition. The >> Incubator is a curriculum, not a community. And if we're going to >> continue to use metaphors like "graduation" and "mentor", >> then the >> requirements for a release must 1) be stated crisply and succinctly 2) >> be separated from best practices, no matter how widely practiced and >> highly regarded some of those procedures may be. >> >> As examples from recent release votes: a particular sequence of >> transformations in subversion for composing a release is not a >> requirement. Small tarballs are not a requirement. Correctly composing >> the LICENSE, DISCLAIMER, and NOTICE files are requirements. >> >> If I've learned one thing from trying to advise on a release, it's >> that I know a lot less than I thought I did. I might be an acceptable >> teaching assistant, but of the 100+ IPMC members, there are only a >> handful of tenured members who can distinguish lore from canon. I (and >> others, no doubt) would happily furnish pints to IPMC members who can >> distill what already exists into a small set of rules, rather than >> augmenting the existing Leviadocs. -C >> >> On Sun, Nov 27, 2011 at 12:09 PM, Ross Gardler >> wrote: >>> I sympathize with you're comments, however, I do want to point out that >> the >>> problems are more to do with the Project committers and mentors than the >>> process (although documentation can always be improved). >>> >>> As evidence I submit the Apache Rave poddling. This project made its first >>> release within a couple of months of entering the incubator and has made a >>> release every month since (I've not checked the dates, but I think this >>> statement is accurate). >>> >>> Rave achieved this because Ate Douma (mentor) pointed to the appropriate >>> docs. Matt Franklin read and understood the docs and did a release. Ate >>> watched and advised throughout the process. The first trekker took a couple >>> of cycles to get right. All sidewinder releases have been >> "simple". >>> >>> Please don't think I'm saying there is no value in your mail, there >> is. We >>> can certainly improve in the support we provide. To address your specific >>> points: >>> >>> 1. Your mentors are the example, if they are not guiding you ask if anyone >>> here can help. >>> >>> 2. Different views of different people is difficult to resolve (see Roberts >>> recent mail on the same topic). My advice is to understand the (admittedly >>> confusing) documentation. If that doesn't help ask on the ap
Re: concerns about high overhead in Apache incubator releases
I suggest we discuss documentation work right here. It will be a welcome change to discuss our work instead of simply our opinions. - Original Message - > From: Chris Douglas > To: general@incubator.apache.org; Joe Schaefer > Cc: "kafka-...@incubator.apache.org" > Sent: Sunday, November 27, 2011 9:01 PM > Subject: Re: concerns about high overhead in Apache incubator releases > > On Sun, Nov 27, 2011 at 5:33 PM, Joe Schaefer > wrote: >> I did not see anyone say RTFM, did you? > > That's how I read Ross's account of the Rave project (mentor pointed > to the docs, RM read them, monthly releases bloomed). I don't think > that was an ungenerous reading, but characterizing it as RTFM may have > misrepresented its tone. > >> Yes it's long and painful prose written by many different authors, >> but simply complaining about it isn't going to get us anywhere. > We've >> known about the problems for years now; what we need is for people >> to step up, in a whine-free way, and collaborate with each other. >> >> Are you game? > > Sure, I'll offer to help with drafting. Where is a good place to > coordinate that? -C > >> - Original Message - >>> From: Chris Douglas >>> To: general@incubator.apache.org >>> Cc: kafka-...@incubator.apache.org >>> Sent: Sunday, November 27, 2011 7:46 PM >>> Subject: Re: concerns about high overhead in Apache incubator releases >>> >>> Ross is 100% in identifying mentors as critical to a smooth release. >>> More specifically, mentors familiar with what a project is likely to >>> face in an Incubator vote. >>> >>> I'm sorry to say that I was an AWOL mentor for the first 5 RCs. I >>> still wouldn't have anticipated the objections from the IPMC that- > as >>> Jun points out- were true of every release. By way of illustration, >>> take the debate on source releases that spread outside of general@ and >>> into other foundation lists. It took over three days to get a yes/no >>> answer from *anyone*, and while hundreds of words on why the answer >>> could be yes were written, the closest we got to a definitive answer >>> on foundation policy was a link to something Roy said in 2009 on >>> legal-discuss@. And none of that discussion is available to podlings! >>> >>> Even that didn't speak to our question. RC6 contained all the > source >>> and unit tests, but it also included artifacts of a successful build. >>> The discussion was focused on minimum requirements, while RC6 was >>> rejected (in part) for including too much. >>> >>> The incubator documentation on releases is over 10k words with at >>> least 80 TODO items. So while I agree that mentors' familiarity > with >>> the process is critical to smooth releases, I reject the RTFM >>> suggestion as trolling. Further, it's not policy when objections > *not* >>> in the documentation get added and cited ex post facto. >>> >>> In some of these threads, the Incubator is confused with an ASF >>> project. This is incoherent given its size and composition. The >>> Incubator is a curriculum, not a community. And if we're going to >>> continue to use metaphors like "graduation" and > "mentor", >>> then the >>> requirements for a release must 1) be stated crisply and succinctly 2) >>> be separated from best practices, no matter how widely practiced and >>> highly regarded some of those procedures may be. >>> >>> As examples from recent release votes: a particular sequence of >>> transformations in subversion for composing a release is not a >>> requirement. Small tarballs are not a requirement. Correctly composing >>> the LICENSE, DISCLAIMER, and NOTICE files are requirements. >>> >>> If I've learned one thing from trying to advise on a release, > it's >>> that I know a lot less than I thought I did. I might be an acceptable >>> teaching assistant, but of the 100+ IPMC members, there are only a >>> handful of tenured members who can distinguish lore from canon. I (and >>> others, no doubt) would happily furnish pints to IPMC members who can >>> distill what already exists into a small set of rules, rather than >>> augmenting the existing Leviadocs. -C >>> >>> On Sun, Nov 27, 2011 at 12:09 PM, Ross Gardler >>> wrote: I sympathize with you're comments, however, I do want to point > out that >>> the problems are more to do with the Project committers and mentors > than the process (although documentation can always be improved). As evidence I submit the Apache Rave poddling. This project made > its first release within a couple of months of entering the incubator and > has made a release every month since (I've not checked the dates, but I > think this statement is accurate). Rave achieved this because Ate Douma (mentor) pointed to the > appropriate docs. Matt Franklin read and understood the docs and did a > release. Ate watched and advised throughout the process. The fir
Re: concerns about high overhead in Apache incubator releases
On 28 November 2011 02:01, Chris Douglas wrote: > On Sun, Nov 27, 2011 at 5:33 PM, Joe Schaefer wrote: >> I did not see anyone say RTFM, did you? > > That's how I read Ross's account of the Rave project (mentor pointed > to the docs, RM read them, monthly releases bloomed). I don't think > that was an ungenerous reading, but characterizing it as RTFM may have > misrepresented its tone. I think you missed a very important part of what I said, let me quote the para you refer to: "Rave achieved this because Ate Douma (mentor) pointed to the appropriate docs. Matt Franklin read and understood the docs and did a release. Ate watched and advised throughout the process." Read the last sentence again "Ate watched and advised throughout the process". My point is we can't expect the mentors to type everything over and over again for every podling, that's why we have docs. We can (and should) expect mentors to answer questions and point out errors in the application of what is learned from the docs. Ross - 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 Sun, Nov 27, 2011 at 6:07 PM, Ross Gardler wrote: > I think you missed a very important part of what I said, let me quote > the para you refer to: [snip] > My point is we can't expect the mentors to type everything over and > over again for every podling, that's why we have docs. We can (and > should) expect mentors to answer questions and point out errors in the > application of what is learned from the docs. Fair point, though the prevailing IPMC consensus is difficult to identify and more relevant than the docs. Suffice to say that we'll update the latter. Doing it on general@ feels like repaving a potholed road without diverting traffic, but we can try it. > This I can agree with. There are other threads underway right now > addressing this very point. Do you think the proposals floating around > right now will help address this and provide adequate support to > mentors? I doubt I'm caught up on all the threads, but changing the "champion" role to be more accountable and enforcing pass/fail for projects in a sane timeframe sounds like a good start. Chris's idea of identifying IPMC members with particular specialties- for mentors and PPMC members to ask questions and get straight answers- would be a welcome service, also. So that the root of this thread is not lost: the Kafka podling is about to roll its 8th RC, after updating the LICENSE to include the NUnit requirement. If any IPMC member has other feedback for the last RC: http://s.apache.org/Vnr NOW is the time to provide it. -C - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Rebooting the Incubator? (was: Does Apache Have a 'Rule' Problem...)
On Sun, Nov 27, 2011 at 10:25 PM, Bertrand Delacretaz wrote: > On Sun, Nov 27, 2011 at 8:41 PM, Benson Margulies > wrote: >> ...Let's see if we can find a small group of members of the IPMC who are, >> in fact, willing to take seriously the task of supervision > > There is such a group already - even though that might be a small > percentage of the IPMC membership (because that PMC is big), there is > a sizable group that does take supervision seriously. Yes, I estimate 10 or maybe 15. There are more than 100 IPMC members subscribed. You could say we have an activity ratio of 10%, if my estimation is correct. >> ...If we can build such a group, it would be the logical nucleus of a >> reboot. If not, well, we've got other problems... > > I don't think a reboot is needed. Some specific points need improving > (how to cope with missing reports and inactive mentors, more efficient > reporting to the board, clarifying our docs) but that doesn't mean the > incubator is broken. > > Working in small, concrete, reversible steps is usually the best way > to get things done at the ASF - let's just do that. Some of them easily reversible, some not so easy to reverse. But all concrete: http://markmail.org/thread/5ozneudwrww3nq5x But all uncommented. Cheers Christian > > -Bertrand > > P.S. Sensationalistic bloggers: if you write about how broken our > Incubator is, you owe me a beer for this subject line. Thanks. > > - > 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: Rebooting the Incubator? (was: Does Apache Have a 'Rule' Problem...)
On Sunday, November 27, 2011 4:37 PM, "Benson Margulies" wrote: > So could we please treat this thread as CLOSED? If you want to plan a > palace coup, why not start a new thread? The subject line /was/ changed. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
