Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=vWWLy7WN8/PNPD9OCSZSKBoZZXXBEDr5cewYXjmu7zdiAsP1KksKomU56o2FfYJXucrsRmbP8px4PERakWrU0OwPfsafUvRcEObrqk0qiBCEqCE0OeR4vX3gcEkZpu+IiFUzbs2owbZjMrAGGwAN1nIevciW5gZkwSEsrPykHHM=;
References: 
 <CAKQbXgARZDNXxCE6bqcspax80gkn0ccFDvSGZq=hcDryFbvofw@mail.gmail.com>
 <CACO5Y4yWBx-Gf+P0mdRCKHSCYeXKH_bKeqOk8RnwrSAQbA19pQ@mail.gmail.com>
Message-ID: <1322444006.12858.YahooMailNeo@web160915.mail.bf1.yahoo.com>
Date: Sun, 27 Nov 2011 17:33:26 -0800 (PST)
From: Joe Schaefer <joe_schaefer@yahoo.com>
Reply-To: Joe Schaefer <joe_schaefer@yahoo.com>
Subject: Re: concerns about high overhead in Apache incubator releases
To: "general@incubator.apache.org" <general@incubator.apache.org>
Cc: "kafka-dev@incubator.apache.org" <kafka-dev@incubator.apache.org>
In-Reply-To: 
 <CACO5Y4yWBx-Gf+P0mdRCKHSCYeXKH_bKeqOk8RnwrSAQbA19pQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I did not see anyone say RTFM, did you?=A0 As I have repeatedly said,=0Athe=
 documentation is just as much to keep the IPMC in line as it is=0Ato keep =
our podlings.=A0 And yes we do need to distinguish between=0Ateaching podli=
ngs best practices, which can be done over time,=0Aand performing policy en=
forcement, which must be done asap.=0A=0AYes it's long and painful prose wr=
itten by many different authors,=0Abut simply complaining about it isn't go=
ing to get us anywhere. We've=0Aknown about the problems for years now; wha=
t we need is for people=0Ato step up, in a whine-free way, and collaborate =
with each other.=0A=0AAre you game?=0A=0A=0A----- Original Message -----=0A=
> From: Chris Douglas <cdouglas@apache.org>=0A> To: general@incubator.apach=
e.org=0A> Cc: kafka-dev@incubator.apache.org=0A> Sent: Sunday, November 27,=
 2011 7:46 PM=0A> Subject: Re: concerns about high overhead in Apache incub=
ator releases=0A> =0A> Ross is 100% in identifying mentors as critical to a=
 smooth release.=0A> More specifically, mentors familiar with what a projec=
t is likely to=0A> face in an Incubator vote.=0A> =0A> I'm sorry to say tha=
t I was an AWOL mentor for the first 5 RCs. I=0A> still wouldn't have antic=
ipated the objections from the IPMC that- as=0A> Jun points out- were true =
of every release. By way of illustration,=0A> take the debate on source rel=
eases that spread outside of general@ and=0A> into other foundation lists. =
It took over three days to get a yes/no=0A> answer from *anyone*, and while=
 hundreds of words on why the answer=0A> could be yes were written, the clo=
sest we got to a definitive answer=0A> on foundation policy was a link to s=
omething Roy said in 2009 on=0A> legal-discuss@. And none of that discussio=
n is available to podlings!=0A> =0A> Even that didn't speak to our question=
. RC6 contained all the source=0A> and unit tests, but it also included art=
ifacts of a successful build.=0A> The discussion was focused on minimum req=
uirements, while RC6 was=0A> rejected (in part) for including too much.=0A>=
 =0A> The incubator documentation on releases is over 10k words with at=0A>=
 least 80 TODO items. So while I agree that mentors' familiarity with=0A> t=
he process is critical to smooth releases, I reject the RTFM=0A> suggestion=
 as trolling. Further, it's not policy when objections *not*=0A> in the doc=
umentation get added and cited ex post facto.=0A> =0A> In some of these thr=
eads, the Incubator is confused with an ASF=0A> project. This is incoherent=
 given its size and composition. The=0A> Incubator is a curriculum, not a c=
ommunity. And if we're going to=0A> continue to use metaphors like "graduat=
ion" and "mentor", =0A> then the=0A> requirements for a release must 1) be =
stated crisply and succinctly 2)=0A> be separated from best practices, no m=
atter how widely practiced and=0A> highly regarded some of those procedures=
 may be.=0A> =0A> As examples from recent release votes: a particular seque=
nce of=0A> transformations in subversion for composing a release is not a=
=0A> requirement. Small tarballs are not a requirement. Correctly composing=
=0A> the LICENSE, DISCLAIMER, and NOTICE files are requirements.=0A> =0A> I=
f I've learned one thing from trying to advise on a release, it's=0A> that =
I know a lot less than I thought I did. I might be an acceptable=0A> teachi=
ng assistant, but of the 100+ IPMC members, there are only a=0A> handful of=
 tenured members who can distinguish lore from canon. I (and=0A> others, no=
 doubt) would happily furnish pints to IPMC members who can=0A> distill wha=
t already exists into a small set of rules, rather than=0A> augmenting the =
existing Leviadocs. -C=0A> =0A> On Sun, Nov 27, 2011 at 12:09 PM, Ross Gard=
ler=0A> <rgardler@opendirective.com> wrote:=0A>>  I sympathize with you're =
comments, however, I do want to point out that =0A> the=0A>>  problems are =
more to do with the Project committers and mentors than the=0A>>  process (=
although documentation can always be improved).=0A>> =0A>>  As evidence I s=
ubmit the Apache Rave poddling. This project made its first=0A>>  release w=
ithin a couple of months of entering the incubator and has made a=0A>>  rel=
ease every month since (I've not checked the dates, but I think this=0A>>  =
statement is accurate).=0A>> =0A>>  Rave achieved this because Ate Douma (m=
entor) pointed to the appropriate=0A>>  docs. Matt Franklin read and unders=
tood the docs and did a release. Ate=0A>>  watched and advised throughout t=
he process. The first trekker took a couple=0A>>  of cycles to get right. A=
ll sidewinder releases have been =0A> "simple".=0A>> =0A>>  Please don't th=
ink I'm saying there is no value in your mail, there =0A> is. We=0A>>  can =
certainly improve in the support we provide. To address your specific=0A>> =
 points:=0A>> =0A>>  1. Your mentors are the example, if they are not guidi=
ng you ask if anyone=0A>>  here can help.=0A>> =0A>>  2. Different views of=
 different people is difficult to resolve (see Roberts=0A>>  recent mail on=
 the same topic). My advice is to understand the (admittedly=0A>>  confusin=
g) documentation. If that doesn't help ask on the appropriate =0A> list=0A>=
>  (here if you don't know which list)=0A>> =0A>>  3. Clone or best mentors=
 - sorry nothing better to suggest here=0A>> =0A>>  4. Get it right first t=
ime (mentors like Ate only let it go to a vote if it=0A>>  is ready, so 72 =
hours is called once only). Also know the rules with=0A>>  respect to relea=
se voting (see Joe's mail).=0A>> =0A>>  Finally, and most importantly, help=
 us improve the process (as you are=0A>>  doing with this mail). Given my r=
esponses above is there anything concrete=0A>>  you suggest we do to improv=
e things (patches to docs seem like an obvious=0A>>  start - most of those =
docs are written by people who already do Apache=0A>>  releases).=0A>> =0A>=
>  Ross=0A>> =0A>>  Sent from my mobile device, please forgive errors and b=
revity.=0A>>  On Nov 27, 2011 7:13 PM, "Jun Rao" <junrao@gmail.com> =0A> wr=
ote:=0A>> =0A>>>  Dear Apache members,=0A>>> =0A>>>  Over the past 2 months=
, the Kafka Apache incubator project has been =0A> trying=0A>>>  to release=
 its very first version in Apache. After 7 RCs, we are still =0A> not=0A>>>=
  done. Part of this is because most of us are new to the Apache release=0A=
>>>  process and are learning things along the way. However, I think Apache=
 =0A> can=0A>>>  do a better job in the incubating process to make releases=
 much less=0A>>>  painful. In the following, I will summarize some of probl=
ems that we=0A>>>  had experienced. This is not an accusation, nor is it pe=
rsonal. I just =0A> hope=0A>>>  that we can all learn from our experience s=
o that Kafka and other =0A> incubator=0A>>>  projects can release more smoo=
thly in the future.=0A>>> =0A>>>  1. There is no good example to follow.=0A=
>>>  As a new incubator project, the natural thing for us to do when it =0A=
> comes to=0A>>>  releasing our code is to follow what other Apache project=
s do. However,=0A>>>  more than once, the feedback that we got is that thos=
e are not good=0A>>>  examples to follow. It seems that those "bad" example=
s are =0A> not isolated=0A>>>  cases.=0A>>> =0A>>>  2. Different Apache mem=
bers have different interpretations of the same=0A>>>  rule.=0A>>>  It seem=
s that there is no consensus on some of the basic rules even =0A> among=0A>=
>>  Apache members. For example, what constitutes a source distribution and=
=0A>>>  what should be put in the NOTICE file? Since all it takes is one =
=0A> negative=0A>>>  vote to block a release, this increases the turnover r=
ate of RCs.=0A>>> =0A>>>  3. Not enough constructive and comprehensive sugg=
estions.=0A>>>  Some of the issues that are present in Kafka RC7 exist in R=
C1. Those =0A> issues=0A>>>  could have been resolved much earlier had ther=
e been more constructive =0A> and=0A>>>  comprehensive feedbacks from early=
 on. Instead, often, the feedback =0A> just=0A>>>  points out the violation=
 of one or two issues that are enough to block =0A> a=0A>>>  release. Peopl=
e like Ant Edler have made some constructive suggestions =0A> and=0A>>>  we=
 really appreciate that. We could use more suggestions like that.=0A>>> =0A=
>>>  4. Not enough flexibility in applying the rules.=0A>>>  Some of the ru=
les don't make common sense. For example, if we =0A> publish a new=0A>>>  R=
C that simply fixes a few lines in NOTICE/LICENSE. We are still =0A> requir=
ed=0A>>>  to go through a full 3-day vote in Kafka and another full 3-day v=
ote in=0A>>>  Apache general. This, coupled with the high turnover rate of =
RCs, can =0A> delay=0A>>>  the release for a significant long time. Both Ch=
ris Douglas and Ant =0A> Edler=0A>>>  wanted to relax the rule slightly to =
help us speed things up. However, =0A> not=0A>>>  every Apache member toler=
ates such flexibility. Again, all it takes is =0A> just=0A>>>  one vote to =
kill a release.=0A>>> =0A>>>  To summarize, our experience of releasing in =
Apache has not been very=0A>>>  pleasant so far. I am not sure if our exper=
ience is the exception or =0A> the=0A>>>  norm among incubator projects. In=
 any case, I sincerely hope that at =0A> least=0A>>>  some of those concern=
s can be addressed in Apache to make the release=0A>>>  process more enjoya=
ble, especially for new comers.=0A>>> =0A>>>  Thanks,=0A>>> =0A>>>  Jun=0A>=
>> =0A>> =0A> =0A> --------------------------------------------------------=
-------------=0A> To unsubscribe, e-mail: general-unsubscribe@incubator.apa=
che.org=0A> For additional commands, e-mail: general-help@incubator.apache.=
org=0A> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org