On Mon, Nov 28, 2011 at 3:04 AM, Joe Schaefer <joe_schae...@yahoo.com> wrote: > I suggest we discuss documentation work right here. It will be a welcome > change to discuss our work instead of simply our opinions.
+1 I would like to suggest to adopt an existing release plan, change it to fit to incubator expectations and create a wikipage for it. Like: http://wiki.apache.org/logging-log4php/ReleaseProcedure This might serve as recommendation, which can be tweaked of course. Guess this will help people better to get started than 10k philosophy. Cheers > > > > ----- Original Message ----- >> From: Chris Douglas <cdoug...@apache.org> >> To: general@incubator.apache.org; Joe Schaefer <joe_schae...@yahoo.com> >> Cc: "kafka-...@incubator.apache.org" <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 <joe_schae...@yahoo.com> >> 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 <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 >>> >>> >> > > --------------------------------------------------------------------- > 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
