> 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 <cdouglas@apache.org>
>> To: general@incubator.apache.org; Joe Schaefer <joe_schaefer@yahoo.com>
>> Cc: "kafka-dev@incubator.apache.org" <kafka-dev@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_schaefer@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 <cdouglas@apache.org>
>>>> To: general@incubator.apache.org
>>>> Cc: kafka-dev@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
>>>> <rgardler@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"
>> <junrao@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-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
No comments:
Post a Comment