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 <cdoug...@apache.org> > 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 > <rgard...@opendirective.com> 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" <jun...@gmail.com> > wrote: >> >>> Dear Apache members, >>> >>> Over the past 2 months, the Kafka Apache incubator project has been > trying >>> to release its very first version in Apache. After 7 RCs, we are still > not >>> done. Part of this is because most of us are new to the Apache release >>> process and are learning things along the way. However, I think Apache > can >>> do a better job in the incubating process to make releases much less >>> painful. In the following, I will summarize some of problems that we >>> had experienced. This is not an accusation, nor is it personal. I just > hope >>> that we can all learn from our experience so that Kafka and other > incubator >>> projects can release more smoothly in the future. >>> >>> 1. There is no good example to follow. >>> As a new incubator project, the natural thing for us to do when it > comes to >>> releasing our code is to follow what other Apache projects do. However, >>> more than once, the feedback that we got is that those are not good >>> examples to follow. It seems that those "bad" examples are > not isolated >>> cases. >>> >>> 2. Different Apache members have different interpretations of the same >>> rule. >>> It seems that there is no consensus on some of the basic rules even > among >>> Apache members. For example, what constitutes a source distribution and >>> what should be put in the NOTICE file? Since all it takes is one > negative >>> vote to block a release, this increases the turnover rate of RCs. >>> >>> 3. Not enough constructive and comprehensive suggestions. >>> Some of the issues that are present in Kafka RC7 exist in RC1. Those > issues >>> could have been resolved much earlier had there been more constructive > and >>> comprehensive feedbacks from early on. Instead, often, the feedback > just >>> points out the violation of one or two issues that are enough to block > a >>> release. People like Ant Edler have made some constructive suggestions > and >>> we really appreciate that. We could use more suggestions like that. >>> >>> 4. Not enough flexibility in applying the rules. >>> Some of the rules don't make common sense. For example, if we > publish a new >>> RC that simply fixes a few lines in NOTICE/LICENSE. We are still > required >>> to go through a full 3-day vote in Kafka and another full 3-day vote in >>> Apache general. This, coupled with the high turnover rate of RCs, can > delay >>> the release for a significant long time. Both Chris Douglas and Ant > Edler >>> wanted to relax the rule slightly to help us speed things up. However, > not >>> every Apache member tolerates such flexibility. Again, all it takes is > just >>> one vote to kill a release. >>> >>> To summarize, our experience of releasing in Apache has not been very >>> pleasant so far. I am not sure if our experience is the exception or > the >>> norm among incubator projects. In any case, I sincerely hope that at > least >>> some of those concerns can be addressed in Apache to make the release >>> process more enjoyable, especially for new comers. >>> >>> Thanks, >>> >>> Jun >>> >> > > --------------------------------------------------------------------- > 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
