incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Douglas <cdoug...@apache.org>
Subject Re: concerns about high overhead in Apache incubator releases
Date Mon, 28 Nov 2011 00:46:42 GMT
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


Mime
View raw message