incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <>
Subject Re: concerns about high overhead in Apache incubator releases
Date Mon, 28 Nov 2011 08:44:08 GMT
On Mon, Nov 28, 2011 at 3:04 AM, Joe Schaefer <> wrote:
> I suggest we discuss documentation work right here. It will be a welcome
> change to discuss our work instead of simply our opinions.


I would like to suggest to adopt an existing release plan, change it
to fit to incubator expectations and create a wikipage for it.

This might serve as recommendation, which can be tweaked of course.
Guess this will help people better to get started than 10k philosophy.


> ----- Original Message -----
>> From: Chris Douglas <>
>> To:; Joe Schaefer <>
>> Cc: "" <>
>> 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:
>>>>  Cc:
>>>>  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 (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
>>>>  ---------------------------------------------------------------------
>>>>  To unsubscribe, e-mail:
>>>>  For additional commands, e-mail:
>>>  ---------------------------------------------------------------------
>>>  To unsubscribe, e-mail:
>>>  For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message