You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Jun Rao <ju...@gmail.com> on 2011/11/27 20:13:02 UTC
concerns about high overhead in Apache incubator releases
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
Re: concerns about high overhead in Apache incubator releases
Posted by Joe Schaefer <jo...@yahoo.com>.
I guess one of the sticking points in all this is the notion
that a release MUST nominally comply with all Apache policies.
Formally, that means it meets the standards set out in
http://www.apache.org/dev/release.html
as well as all of our adopted legal policies. That we tend
to sometimes debate whether something meets the definition
of ASF policy is problematic, but I don't see an easy soln
to that other than to elevate the discussion to either
legal-discuss@ (in the case of legal policy disputes) or
to infrastructure@ or site-dev@ or even board@ if all else
fails (in the caseof disputes about release policy). That
we have recentlyjust gone down that route is indicative not
of failure on the IPMC's part, but just the normal tide of
reviewing and questioning what the published documentation
actually says. That people with different experiences will
read that documentation as meaning different things is only
natural, and the search for clearer and more universal language
is a welcome thing, but it's a lot harder than it looks ;-).
----- Original Message -----
> From: "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>
> To: "general@incubator.apache.org" <ge...@incubator.apache.org>
> Cc: Joe Schaefer <jo...@yahoo.com>; "kafka-dev@incubator.apache.org" <ka...@incubator.apache.org>
> Sent: Sunday, November 27, 2011 4:04 PM
> Subject: Re: concerns about high overhead in Apache incubator releases
>
> On Nov 27, 2011, at 12:53 PM, Robert Burrell Donkin wrote:
>>>>
>>>> NO. The only time someone can claim to hold a veto over a release
> vote is
>>>> when they are jibberjabbering about legal issues. NOTICE errors
> really
>>>> don't risk a lawsuit from anyone, so those -1's are NOT
> vetoes.
>>>
>>> If Joe didn't send this reply, I was about to myself. Here's 2
> IPMC members that
>>> *do* agree on this: Joe is right, VETOs do *not* apply to releases of
> code.
>>
>> Any legal issue serious enough to VETO a release would require code
>> access to be blocked and all discussions taken private. Anything short
>> of this isn't a VETO.
>
> Agreed! Uh-oh, that's *three* IPMC members that agree! Shocking! :-)
>
> Can we get 4? LOL.
>
> Cheers,
> Chris
> (Mr. In-a-great-mood-after-the-USC-game-last-night)
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattmann@nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Re: concerns about high overhead in Apache incubator releases
Posted by Joe Schaefer <jo...@yahoo.com>.
I guess one of the sticking points in all this is the notion
that a release MUST nominally comply with all Apache policies.
Formally, that means it meets the standards set out in
http://www.apache.org/dev/release.html
as well as all of our adopted legal policies. That we tend
to sometimes debate whether something meets the definition
of ASF policy is problematic, but I don't see an easy soln
to that other than to elevate the discussion to either
legal-discuss@ (in the case of legal policy disputes) or
to infrastructure@ or site-dev@ or even board@ if all else
fails (in the caseof disputes about release policy). That
we have recentlyjust gone down that route is indicative not
of failure on the IPMC's part, but just the normal tide of
reviewing and questioning what the published documentation
actually says. That people with different experiences will
read that documentation as meaning different things is only
natural, and the search for clearer and more universal language
is a welcome thing, but it's a lot harder than it looks ;-).
----- Original Message -----
> From: "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>
> To: "general@incubator.apache.org" <ge...@incubator.apache.org>
> Cc: Joe Schaefer <jo...@yahoo.com>; "kafka-dev@incubator.apache.org" <ka...@incubator.apache.org>
> Sent: Sunday, November 27, 2011 4:04 PM
> Subject: Re: concerns about high overhead in Apache incubator releases
>
> On Nov 27, 2011, at 12:53 PM, Robert Burrell Donkin wrote:
>>>>
>>>> NO. The only time someone can claim to hold a veto over a release
> vote is
>>>> when they are jibberjabbering about legal issues. NOTICE errors
> really
>>>> don't risk a lawsuit from anyone, so those -1's are NOT
> vetoes.
>>>
>>> If Joe didn't send this reply, I was about to myself. Here's 2
> IPMC members that
>>> *do* agree on this: Joe is right, VETOs do *not* apply to releases of
> code.
>>
>> Any legal issue serious enough to VETO a release would require code
>> access to be blocked and all discussions taken private. Anything short
>> of this isn't a VETO.
>
> Agreed! Uh-oh, that's *three* IPMC members that agree! Shocking! :-)
>
> Can we get 4? LOL.
>
> Cheers,
> Chris
> (Mr. In-a-great-mood-after-the-USC-game-last-night)
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattmann@nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
> ---------------------------------------------------------------------
> 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
Re: concerns about high overhead in Apache incubator releases
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
On Nov 27, 2011, at 12:53 PM, Robert Burrell Donkin wrote:
>>>
>>> NO. The only time someone can claim to hold a veto over a release vote is
>>> when they are jibberjabbering about legal issues. NOTICE errors really
>>> don't risk a lawsuit from anyone, so those -1's are NOT vetoes.
>>
>> If Joe didn't send this reply, I was about to myself. Here's 2 IPMC members that
>> *do* agree on this: Joe is right, VETOs do *not* apply to releases of code.
>
> Any legal issue serious enough to VETO a release would require code
> access to be blocked and all discussions taken private. Anything short
> of this isn't a VETO.
Agreed! Uh-oh, that's *three* IPMC members that agree! Shocking! :-)
Can we get 4? LOL.
Cheers,
Chris
(Mr. In-a-great-mood-after-the-USC-game-last-night)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: concerns about high overhead in Apache incubator releases
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Nov 28, 2011 at 12:56:59PM -0600, William A. Rowe Jr. wrote:
> A majority of +1's over -1's is required, obviously :)
That would be sane, but that's not how I read this passage:
http://www.apache.org/foundation/voting.html#ReleaseVotes
Votes on whether a package is ready to be released follow a format similar
to majority approval -- except that the decision is officially determined
solely by whether at least three +1 votes were registered.
This is probably an academic point, as it's hard to imagine an RM going
forward with a release if there are more -1 votes than +1 votes -- but it
might be nice to update that language if it is misleading.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] release vetoes?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 11/28/2011 3:19 PM, Alan D. Cabrera wrote:
>
> On Nov 28, 2011, at 11:21 AM, William A. Rowe Jr. wrote:
>
>> No - nobody can veto a release. But you also can't slip in a vetoed patch
>> and say "this is a release vote, its not subject to veto". Well, as I had
>> hinted, the RM can withdraw a vote, which is sort of like a self-veto.
>
> A finer, maybe obvious, point to this statement, there are minimum requirements that must be adhered to.
That gets a bit confusing though. You can't release a work under
the GPL or BSD license from the ASF, that would be a board policy.
But then there are conventions, which if the majority of the project
don't feel are applicable [anymore] to this [particular] project, are
subject to change through a release vote.
For example, at httpd project, you cannot "retag", if we burn a release
rev number, we simply move on. Other projects are perfectly happy with
spinning RC numbers until they arrive at the perfect sequential .0, .1
.2 releases.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] release vetoes?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Nov 28, 2011, at 11:21 AM, William A. Rowe Jr. wrote:
> On 11/28/2011 1:00 PM, Neha Narkhede wrote:
>>>> That is because, every single time, the RM agreed that the release
>>>> was worth re-cutting.
>>
>> We have been assuming that it is the rule of Apache to cut another RC even
>> if it gets a single -1 vote.
>
> And that isn't correct, as Joe was kind enough to point out.
>
>>>> A majority of +1's over -1's is required, obviously :)
>>
>> Although this seems reasonable, do people on this list believe this to be
>> true according to the Apache rulebook ?
>>
>> In other words, can the podling RM and committers question and contest a -1
>> vote ? Is there any possibility of vetoing that ? If yes, who can do that
>> in what circumstances ?
>
> Yes - you may always try to persuade someone who voted -1 to reconsider,
> especially by providing more information. For a code veto, that could
> include the fact that they failed to make a technical argument. Once they
> have a technical basis, you can't "dispute" it even if you disagree with
> it, it remains a veto. But always try to negotiate towards mutually
> agreeable code!
>
> No - nobody can veto a release. But you also can't slip in a vetoed patch
> and say "this is a release vote, its not subject to veto". Well, as I had
> hinted, the RM can withdraw a vote, which is sort of like a self-veto.
A finer, maybe obvious, point to this statement, there are minimum requirements that must be adhered to.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] release vetoes?
Posted by David Crossley <cr...@apache.org>.
William A. Rowe Jr. wrote:
> sebb wrote:
> >>
> >>http://httpd.apache.org/dev/release.html was just recently revised by
> >>Roy Fielding (ASF Director and founding officer) based on some nonsense
> >>back-channel complaints, and might be worth integrating into incubator
> >>docs.
> >
> >Would it not be better to integrate the clarifications into an
> >ASF-wide document?
>
> I'm certain it would, the bigger question being who has the cycles
> to do so?
While searching the mail archives i found this useful past thread.
It is not only about release and veto, but also about some
principles with releases, PMCs, and chairs.
Subject: release voting
Date: 2006-12-11
http://s.apache.org/xdR
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] release vetoes?
Posted by Ross Gardler <rg...@opendirective.com>.
Sent from my mobile device, please forgive errors and brevity.
On Nov 29, 2011 10:10 PM, "Robert Burrell Donkin" <
robertburrelldonkin@gmail.com> wrote:
>
> On Tue, Nov 29, 2011 at 9:04 PM, William A. Rowe Jr.
> <wr...@rowe-clan.net> wrote:
> > On 11/29/2011 2:14 PM, Robert Burrell Donkin wrote:
> >>
> >>
> >> I've been wondering whether F2F meetups (bootcamps) for the incubator
> >> might be a way forward
> >
> >
> > Every retreat I've attended - which translates to those in Wicklow -
> > has included some level of incubator orientation, and some participation
> > by a few incubating projects. Strongly encouraged, we should do more to
> > get the word out on the eve of the next events.
>
> I was wondering whether we might do something more explicitly
> Incubator focused perhaps with some presentations and panels
It doesn't make sense a a solution to three lack of effective and clear
mentoring for a few projects.
Most incubator projects, by definition, have small communities based in a
single geographic location. Thinking of my own podlings that would be:
- Vancouver
- Bristol
- Indiana
- Bolton
- Boston
All of these projects are at a different stagger of incubation.
Where would this event take place to give effective coverage for my
podlings? What type would be useful top all? What about the other 50?
Every little helps and if you want to spend time setting this up then I
applaud you (and will help if I can). It will have a positive effect on
those present, but minimal effect on the incubator as a while.
Ross
>
> Robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Re: [policy] release vetoes?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Nov 29, 2011 at 9:04 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 11/29/2011 2:14 PM, Robert Burrell Donkin wrote:
>>
>>
>> I've been wondering whether F2F meetups (bootcamps) for the incubator
>> might be a way forward
>
>
> Every retreat I've attended - which translates to those in Wicklow -
> has included some level of incubator orientation, and some participation
> by a few incubating projects. Strongly encouraged, we should do more to
> get the word out on the eve of the next events.
I was wondering whether we might do something more explicitly
Incubator focused perhaps with some presentations and panels
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] release vetoes?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 11/29/2011 2:14 PM, Robert Burrell Donkin wrote:
>
> I've been wondering whether F2F meetups (bootcamps) for the incubator
> might be a way forward
Every retreat I've attended - which translates to those in Wicklow -
has included some level of incubator orientation, and some participation
by a few incubating projects. Strongly encouraged, we should do more to
get the word out on the eve of the next events.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] release vetoes?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Nov 29, 2011 at 6:29 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 11/29/2011 9:52 AM, sebb wrote:
>>>
>>>
>>> http://httpd.apache.org/dev/release.html was just recently revised by
>>> Roy Fielding (ASF Director and founding officer) based on some nonsense
>>> back-channel complaints, and might be worth integrating into incubator
>>> docs.
>>
>>
>> Would it not be better to integrate the clarifications into an
>> ASF-wide document?
>
>
> I'm certain it would, the bigger question being who has the cycles
> to do so?
I've been wondering whether F2F meetups (bootcamps) for the incubator
might be a way forward
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] release vetoes?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 11/29/2011 9:52 AM, sebb wrote:
>>
>> http://httpd.apache.org/dev/release.html was just recently revised by
>> Roy Fielding (ASF Director and founding officer) based on some nonsense
>> back-channel complaints, and might be worth integrating into incubator
>> docs.
>
> Would it not be better to integrate the clarifications into an
> ASF-wide document?
I'm certain it would, the bigger question being who has the cycles
to do so?
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] release vetoes?
Posted by sebb <se...@gmail.com>.
On 28 November 2011 19:21, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> On 11/28/2011 1:00 PM, Neha Narkhede wrote:
>>>>
>>>> That is because, every single time, the RM agreed that the release
>>>> was worth re-cutting.
>>
>>
>> We have been assuming that it is the rule of Apache to cut another RC even
>> if it gets a single -1 vote.
>
>
> And that isn't correct, as Joe was kind enough to point out.
>
>>>> A majority of +1's over -1's is required, obviously :)
>>
>>
>> Although this seems reasonable, do people on this list believe this to be
>> true according to the Apache rulebook ?
>>
>> In other words, can the podling RM and committers question and contest a
>> -1
>> vote ? Is there any possibility of vetoing that ? If yes, who can do that
>> in what circumstances ?
>
>
> Yes - you may always try to persuade someone who voted -1 to reconsider,
> especially by providing more information. For a code veto, that could
> include the fact that they failed to make a technical argument. Once they
> have a technical basis, you can't "dispute" it even if you disagree with
> it, it remains a veto. But always try to negotiate towards mutually
> agreeable code!
>
> No - nobody can veto a release. But you also can't slip in a vetoed patch
> and say "this is a release vote, its not subject to veto". Well, as I had
> hinted, the RM can withdraw a vote, which is sort of like a self-veto.
>
> http://httpd.apache.org/dev/release.html was just recently revised by
> Roy Fielding (ASF Director and founding officer) based on some nonsense
> back-channel complaints, and might be worth integrating into incubator
> docs.
Would it not be better to integrate the clarifications into an
ASF-wide document?
>
>
> ---------------------------------------------------------------------
> 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
[policy] release vetoes?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 11/28/2011 1:00 PM, Neha Narkhede wrote:
>>> That is because, every single time, the RM agreed that the release
>>> was worth re-cutting.
>
> We have been assuming that it is the rule of Apache to cut another RC even
> if it gets a single -1 vote.
And that isn't correct, as Joe was kind enough to point out.
>>> A majority of +1's over -1's is required, obviously :)
>
> Although this seems reasonable, do people on this list believe this to be
> true according to the Apache rulebook ?
>
> In other words, can the podling RM and committers question and contest a -1
> vote ? Is there any possibility of vetoing that ? If yes, who can do that
> in what circumstances ?
Yes - you may always try to persuade someone who voted -1 to reconsider,
especially by providing more information. For a code veto, that could
include the fact that they failed to make a technical argument. Once they
have a technical basis, you can't "dispute" it even if you disagree with
it, it remains a veto. But always try to negotiate towards mutually
agreeable code!
No - nobody can veto a release. But you also can't slip in a vetoed patch
and say "this is a release vote, its not subject to veto". Well, as I had
hinted, the RM can withdraw a vote, which is sort of like a self-veto.
http://httpd.apache.org/dev/release.html was just recently revised by
Roy Fielding (ASF Director and founding officer) based on some nonsense
back-channel complaints, and might be worth integrating into incubator
docs.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: concerns about high overhead in Apache incubator releases
Posted by Neha Narkhede <ne...@gmail.com>.
>> That is because, every single time, the RM agreed that the release
was worth re-cutting.
We have been assuming that it is the rule of Apache to cut another RC even
if it gets a single -1 vote.
>> A majority of +1's over -1's is required, obviously :)
Although this seems reasonable, do people on this list believe this to be
true according to the Apache rulebook ?
In other words, can the podling RM and committers question and contest a -1
vote ? Is there any possibility of vetoing that ? If yes, who can do that
in what circumstances ?
Thanks,
Neha
On Mon, Nov 28, 2011 at 10:56 AM, William A. Rowe Jr.
<wr...@rowe-clan.net>wrote:
> On 11/27/2011 3:34 PM, Benson Margulies wrote:
>
>> I think I've been leading a sheltered existence. In the TLPs of which
>> I play a part, over the 5 years or so that I've been around, I've
>> never seen a release proceed past a -1. Every single time, a -1 has
>> led to recutting the release.
>>
>
> That is because, every single time, the RM agreed that the release
> was worth re-cutting. The vote hadn't (necessarily) failed... it was
> withdrawn for a better tag.
>
> When you get into complex alpha/beta releases, many projects will
> proceed, noting a -1 for some broken platform or broken feature,
> in order to get to the -next- alpha or beta release with that defect
> corrected, in addition to community feedback on the rest of the
> platforms and features.
>
> A majority of +1's over -1's is required, obviously :)
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.org<ge...@incubator.apache.org>
> For additional commands, e-mail: general-help@incubator.apache.**org<ge...@incubator.apache.org>
>
>
Re: concerns about high overhead in Apache incubator releases
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 11/27/2011 3:34 PM, Benson Margulies wrote:
> I think I've been leading a sheltered existence. In the TLPs of which
> I play a part, over the 5 years or so that I've been around, I've
> never seen a release proceed past a -1. Every single time, a -1 has
> led to recutting the release.
That is because, every single time, the RM agreed that the release
was worth re-cutting. The vote hadn't (necessarily) failed... it was
withdrawn for a better tag.
When you get into complex alpha/beta releases, many projects will
proceed, noting a -1 for some broken platform or broken feature,
in order to get to the -next- alpha or beta release with that defect
corrected, in addition to community feedback on the rest of the
platforms and features.
A majority of +1's over -1's is required, obviously :)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: concerns about high overhead in Apache incubator releases
Posted by Benson Margulies <bi...@gmail.com>.
I think I've been leading a sheltered existence. In the TLPs of which
I play a part, over the 5 years or so that I've been around, I've
never seen a release proceed past a -1. Every single time, a -1 has
led to recutting the release.
In some ways, I'd expect the incubator to be more conservative (since
the IP is new) and in other ways less (we all know that a NOTICE
blivet will never be a legal armegeddon).
IPMC members vote -1 for even small details in policy (and, yes, for
big ones two). Podlings and mentors sure appear to have been reading
from the script in my first sentence.
I'm not opposed to reminding people that only a VETO is a hard stop,
but is there also room to remind people that not every misplaced comma
deserves even a -1?
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: concerns about high overhead in Apache incubator releases
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Nov 27, 2011 at 9:05 PM, Joe Schaefer <jo...@yahoo.com> wrote:
>> From: Robert Burrell Donkin <ro...@gmail.com>
<snip>
>> Any legal issue serious enough to VETO a release would require code
>> access to be blocked and all discussions taken private. Anything short
>> of this isn't a VETO.
>
> I wouldn't go that far. I mean if a podling is trying to ship GPL code or hasn't
> completed its IP checklist, it shouldn't be releasing software from the ASF
> yet. Those aren't issues that require privacy.
+1 in principle
But in practice, this tends to be about managing legal risk to the
foundation. In order to get time to allow our counsel to give legal
advice, infra would probably be asked (by the legal VP or a group of 3
committee members) to block access whilst the internal legal and board
decide how to sort out the mess. (Or at least that's the way it's
worked in the past.) Quite a big stick, which makes VETO a tough call
to make.
For me, shipping GPL code or incomplete IP check would be -1 but not
VETO issues. For me, examples of serious legal issues would be an
email threatening legal action if a release goes ahead but even this
is controversial.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: concerns about high overhead in Apache incubator releases
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message -----
> From: Robert Burrell Donkin <ro...@gmail.com>
> To: general@incubator.apache.org
> Cc: Joe Schaefer <jo...@yahoo.com>; "kafka-dev@incubator.apache.org" <ka...@incubator.apache.org>
> Sent: Sunday, November 27, 2011 3:53 PM
> Subject: Re: concerns about high overhead in Apache incubator releases
>
> On Sun, Nov 27, 2011 at 8:09 PM, Mattmann, Chris A (388J)
> <ch...@jpl.nasa.gov> wrote:
>> On Nov 27, 2011, at 11:21 AM, Joe Schaefer wrote:
>>
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: Jun Rao <ju...@gmail.com>
>>>> To: general@incubator.apache.org
>>>> Cc: kafka-dev@incubator.apache.org
>>>> Sent: Sunday, November 27, 2011 2:13 PM
>>>> Subject: concerns about high overhead in Apache incubator releases
>>>>
>>>> Dear Apache members,
>>>
>>> [...]
>>>
>>>> 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.
>>>
>>> NO. The only time someone can claim to hold a veto over a release vote
> is
>>> when they are jibberjabbering about legal issues. NOTICE errors really
>>> don't risk a lawsuit from anyone, so those -1's are NOT vetoes.
>>
>> If Joe didn't send this reply, I was about to myself. Here's 2 IPMC
> members that
>> *do* agree on this: Joe is right, VETOs do *not* apply to releases of code.
>
> Any legal issue serious enough to VETO a release would require code
> access to be blocked and all discussions taken private. Anything short
> of this isn't a VETO.
I wouldn't go that far. I mean if a podling is trying to ship GPL code or hasn't
completed its IP checklist, it shouldn't be releasing software from the ASF
yet. Those aren't issues that require privacy.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: concerns about high overhead in Apache incubator releases
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message -----
> From: Robert Burrell Donkin <ro...@gmail.com>
> To: general@incubator.apache.org
> Cc: Joe Schaefer <jo...@yahoo.com>; "kafka-dev@incubator.apache.org" <ka...@incubator.apache.org>
> Sent: Sunday, November 27, 2011 3:53 PM
> Subject: Re: concerns about high overhead in Apache incubator releases
>
> On Sun, Nov 27, 2011 at 8:09 PM, Mattmann, Chris A (388J)
> <ch...@jpl.nasa.gov> wrote:
>> On Nov 27, 2011, at 11:21 AM, Joe Schaefer wrote:
>>
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: Jun Rao <ju...@gmail.com>
>>>> To: general@incubator.apache.org
>>>> Cc: kafka-dev@incubator.apache.org
>>>> Sent: Sunday, November 27, 2011 2:13 PM
>>>> Subject: concerns about high overhead in Apache incubator releases
>>>>
>>>> Dear Apache members,
>>>
>>> [...]
>>>
>>>> 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.
>>>
>>> NO. The only time someone can claim to hold a veto over a release vote
> is
>>> when they are jibberjabbering about legal issues. NOTICE errors really
>>> don't risk a lawsuit from anyone, so those -1's are NOT vetoes.
>>
>> If Joe didn't send this reply, I was about to myself. Here's 2 IPMC
> members that
>> *do* agree on this: Joe is right, VETOs do *not* apply to releases of code.
>
> Any legal issue serious enough to VETO a release would require code
> access to be blocked and all discussions taken private. Anything short
> of this isn't a VETO.
I wouldn't go that far. I mean if a podling is trying to ship GPL code or hasn't
completed its IP checklist, it shouldn't be releasing software from the ASF
yet. Those aren't issues that require privacy.
Re: concerns about high overhead in Apache incubator releases
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
On Nov 27, 2011, at 12:53 PM, Robert Burrell Donkin wrote:
>>>
>>> NO. The only time someone can claim to hold a veto over a release vote is
>>> when they are jibberjabbering about legal issues. NOTICE errors really
>>> don't risk a lawsuit from anyone, so those -1's are NOT vetoes.
>>
>> If Joe didn't send this reply, I was about to myself. Here's 2 IPMC members that
>> *do* agree on this: Joe is right, VETOs do *not* apply to releases of code.
>
> Any legal issue serious enough to VETO a release would require code
> access to be blocked and all discussions taken private. Anything short
> of this isn't a VETO.
Agreed! Uh-oh, that's *three* IPMC members that agree! Shocking! :-)
Can we get 4? LOL.
Cheers,
Chris
(Mr. In-a-great-mood-after-the-USC-game-last-night)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: concerns about high overhead in Apache incubator releases
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Nov 27, 2011 at 8:09 PM, Mattmann, Chris A (388J)
<ch...@jpl.nasa.gov> wrote:
> On Nov 27, 2011, at 11:21 AM, Joe Schaefer wrote:
>
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Jun Rao <ju...@gmail.com>
>>> To: general@incubator.apache.org
>>> Cc: kafka-dev@incubator.apache.org
>>> Sent: Sunday, November 27, 2011 2:13 PM
>>> Subject: concerns about high overhead in Apache incubator releases
>>>
>>> Dear Apache members,
>>
>> [...]
>>
>>> 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.
>>
>> NO. The only time someone can claim to hold a veto over a release vote is
>> when they are jibberjabbering about legal issues. NOTICE errors really
>> don't risk a lawsuit from anyone, so those -1's are NOT vetoes.
>
> If Joe didn't send this reply, I was about to myself. Here's 2 IPMC members that
> *do* agree on this: Joe is right, VETOs do *not* apply to releases of code.
Any legal issue serious enough to VETO a release would require code
access to be blocked and all discussions taken private. Anything short
of this isn't a VETO.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: concerns about high overhead in Apache incubator releases
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Nov 27, 2011 at 8:09 PM, Mattmann, Chris A (388J)
<ch...@jpl.nasa.gov> wrote:
> On Nov 27, 2011, at 11:21 AM, Joe Schaefer wrote:
>
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Jun Rao <ju...@gmail.com>
>>> To: general@incubator.apache.org
>>> Cc: kafka-dev@incubator.apache.org
>>> Sent: Sunday, November 27, 2011 2:13 PM
>>> Subject: concerns about high overhead in Apache incubator releases
>>>
>>> Dear Apache members,
>>
>> [...]
>>
>>> 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.
>>
>> NO. The only time someone can claim to hold a veto over a release vote is
>> when they are jibberjabbering about legal issues. NOTICE errors really
>> don't risk a lawsuit from anyone, so those -1's are NOT vetoes.
>
> If Joe didn't send this reply, I was about to myself. Here's 2 IPMC members that
> *do* agree on this: Joe is right, VETOs do *not* apply to releases of code.
Any legal issue serious enough to VETO a release would require code
access to be blocked and all discussions taken private. Anything short
of this isn't a VETO.
Robert
Re: concerns about high overhead in Apache incubator releases
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
On Nov 27, 2011, at 11:21 AM, Joe Schaefer wrote:
>
>
>
>
> ----- Original Message -----
>> From: Jun Rao <ju...@gmail.com>
>> To: general@incubator.apache.org
>> Cc: kafka-dev@incubator.apache.org
>> Sent: Sunday, November 27, 2011 2:13 PM
>> Subject: concerns about high overhead in Apache incubator releases
>>
>> Dear Apache members,
>
> [...]
>
>> 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.
>
> NO. The only time someone can claim to hold a veto over a release vote is
> when they are jibberjabbering about legal issues. NOTICE errors really
> don't risk a lawsuit from anyone, so those -1's are NOT vetoes.
If Joe didn't send this reply, I was about to myself. Here's 2 IPMC members that
*do* agree on this: Joe is right, VETOs do *not* apply to releases of code.
Hope that helps :-)
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: concerns about high overhead in Apache incubator releases
Posted by Benson Margulies <bi...@gmail.com>.
One piece of advice I've been kicking myself for not offering more
aggressively is this: ask for review before you bother to put up a
candidate for a vote. It's a lot less work.
On Sun, Nov 27, 2011 at 3:47 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Sun, Nov 27, 2011 at 7:21 PM, Joe Schaefer <jo...@yahoo.com> wrote:
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Jun Rao <ju...@gmail.com>
>>> To: general@incubator.apache.org
>>> Cc: kafka-dev@incubator.apache.org
>>> Sent: Sunday, November 27, 2011 2:13 PM
>>> Subject: concerns about high overhead in Apache incubator releases
>>>
>>> Dear Apache members,
>>
>> [...]
>>
>>> 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.
>>
>> NO. The only time someone can claim to hold a veto over a release vote is
>> when they are jibberjabbering about legal issues. NOTICE errors really
>> don't risk a lawsuit from anyone, so those -1's are NOT vetoes.
>
> +1
>
>> (Now that I've written that, it's possible/probable that someone will offer
>> you
>
> a different opinion.
>
> Sadly not today from me :-)
>
>> What you should do as an incubating participant
>> is challenge any such opinions with a reference to supporting website
>> documentation.)
>
> +1
>
> Exceptional cases do turn up from time to time
>
>> Yes, I share your frustrations with the whole experience here in general.
>> However, IME good and active mentors can mitigate a lot of the problems
>> you face as a podling. Yes there will be times when we have to argue things
>> out, but that aspect is one of the features of an org that tries to stay
>> flexible and not overrely on an abundance of rules set a long time ago.
>
> +1
>
> Robert
>
> ---------------------------------------------------------------------
> 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
Re: concerns about high overhead in Apache incubator releases
Posted by Benson Margulies <bi...@gmail.com>.
One piece of advice I've been kicking myself for not offering more
aggressively is this: ask for review before you bother to put up a
candidate for a vote. It's a lot less work.
On Sun, Nov 27, 2011 at 3:47 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Sun, Nov 27, 2011 at 7:21 PM, Joe Schaefer <jo...@yahoo.com> wrote:
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Jun Rao <ju...@gmail.com>
>>> To: general@incubator.apache.org
>>> Cc: kafka-dev@incubator.apache.org
>>> Sent: Sunday, November 27, 2011 2:13 PM
>>> Subject: concerns about high overhead in Apache incubator releases
>>>
>>> Dear Apache members,
>>
>> [...]
>>
>>> 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.
>>
>> NO. The only time someone can claim to hold a veto over a release vote is
>> when they are jibberjabbering about legal issues. NOTICE errors really
>> don't risk a lawsuit from anyone, so those -1's are NOT vetoes.
>
> +1
>
>> (Now that I've written that, it's possible/probable that someone will offer
>> you
>
> a different opinion.
>
> Sadly not today from me :-)
>
>> What you should do as an incubating participant
>> is challenge any such opinions with a reference to supporting website
>> documentation.)
>
> +1
>
> Exceptional cases do turn up from time to time
>
>> Yes, I share your frustrations with the whole experience here in general.
>> However, IME good and active mentors can mitigate a lot of the problems
>> you face as a podling. Yes there will be times when we have to argue things
>> out, but that aspect is one of the features of an org that tries to stay
>> flexible and not overrely on an abundance of rules set a long time ago.
>
> +1
>
> Robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: concerns about high overhead in Apache incubator releases
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Nov 27, 2011 at 7:21 PM, Joe Schaefer <jo...@yahoo.com> wrote:
>
>
>
>
> ----- Original Message -----
>> From: Jun Rao <ju...@gmail.com>
>> To: general@incubator.apache.org
>> Cc: kafka-dev@incubator.apache.org
>> Sent: Sunday, November 27, 2011 2:13 PM
>> Subject: concerns about high overhead in Apache incubator releases
>>
>> Dear Apache members,
>
> [...]
>
>> 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.
>
> NO. The only time someone can claim to hold a veto over a release vote is
> when they are jibberjabbering about legal issues. NOTICE errors really
> don't risk a lawsuit from anyone, so those -1's are NOT vetoes.
+1
> (Now that I've written that, it's possible/probable that someone will offer
> you
a different opinion.
Sadly not today from me :-)
> What you should do as an incubating participant
> is challenge any such opinions with a reference to supporting website
> documentation.)
+1
Exceptional cases do turn up from time to time
> Yes, I share your frustrations with the whole experience here in general.
> However, IME good and active mentors can mitigate a lot of the problems
> you face as a podling. Yes there will be times when we have to argue things
> out, but that aspect is one of the features of an org that tries to stay
> flexible and not overrely on an abundance of rules set a long time ago.
+1
Robert
Re: concerns about high overhead in Apache incubator releases
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Nov 27, 2011 at 7:21 PM, Joe Schaefer <jo...@yahoo.com> wrote:
>
>
>
>
> ----- Original Message -----
>> From: Jun Rao <ju...@gmail.com>
>> To: general@incubator.apache.org
>> Cc: kafka-dev@incubator.apache.org
>> Sent: Sunday, November 27, 2011 2:13 PM
>> Subject: concerns about high overhead in Apache incubator releases
>>
>> Dear Apache members,
>
> [...]
>
>> 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.
>
> NO. The only time someone can claim to hold a veto over a release vote is
> when they are jibberjabbering about legal issues. NOTICE errors really
> don't risk a lawsuit from anyone, so those -1's are NOT vetoes.
+1
> (Now that I've written that, it's possible/probable that someone will offer
> you
a different opinion.
Sadly not today from me :-)
> What you should do as an incubating participant
> is challenge any such opinions with a reference to supporting website
> documentation.)
+1
Exceptional cases do turn up from time to time
> Yes, I share your frustrations with the whole experience here in general.
> However, IME good and active mentors can mitigate a lot of the problems
> you face as a podling. Yes there will be times when we have to argue things
> out, but that aspect is one of the features of an org that tries to stay
> flexible and not overrely on an abundance of rules set a long time ago.
+1
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: concerns about high overhead in Apache incubator releases
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
On Nov 27, 2011, at 11:21 AM, Joe Schaefer wrote:
>
>
>
>
> ----- Original Message -----
>> From: Jun Rao <ju...@gmail.com>
>> To: general@incubator.apache.org
>> Cc: kafka-dev@incubator.apache.org
>> Sent: Sunday, November 27, 2011 2:13 PM
>> Subject: concerns about high overhead in Apache incubator releases
>>
>> Dear Apache members,
>
> [...]
>
>> 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.
>
> NO. The only time someone can claim to hold a veto over a release vote is
> when they are jibberjabbering about legal issues. NOTICE errors really
> don't risk a lawsuit from anyone, so those -1's are NOT vetoes.
If Joe didn't send this reply, I was about to myself. Here's 2 IPMC members that
*do* agree on this: Joe is right, VETOs do *not* apply to releases of code.
Hope that helps :-)
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: concerns about high overhead in Apache incubator releases
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message -----
> From: Jun Rao <ju...@gmail.com>
> To: general@incubator.apache.org
> Cc: kafka-dev@incubator.apache.org
> Sent: Sunday, November 27, 2011 2:13 PM
> Subject: concerns about high overhead in Apache incubator releases
>
> Dear Apache members,
[...]
> 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.
NO. The only time someone can claim to hold a veto over a release vote is
when they are jibberjabbering about legal issues. NOTICE errors really
don't risk a lawsuit from anyone, so those -1's are NOT vetoes.
(Now that I've written that, it's possible/probable that someone will offer
you a different opinion. What you should do as an incubating participant
is challenge any such opinions with a reference to supporting website
documentation.)
Yes, I share your frustrations with the whole experience here in general.
However, IME good and active mentors can mitigate a lot of the problems
you face as a podling. Yes there will be times when we have to argue things
out, but that aspect is one of the features of an org that tries to stay
flexible and not overrely on an abundance of rules set a long time ago.
Re: concerns about high overhead in Apache incubator releases
Posted by Chris Douglas <cd...@apache.org>.
On Mon, Nov 28, 2011 at 4:12 PM, David Crossley <cr...@apache.org> wrote:
> I cannot understand why people are confused on those points.
Empathy is hard when you've forgotten what it was like to learn the
topic. There is a lot of documentation, but it is not curated. To
apprehend the topic, one has to read the foundation bylaws, the
incubator guides, follow links to old mailing list threads, read the
httpd docs, community docs, and- as recommended earlier in this
thread- learn when to ignore people.
> Not everything was written in docs, and still not.
> Not everything needs to be, as lots is common sense.
> The email archives are "documents".
Whatever. This "back in the day" back-slapping helps nobody. The
incubator is supposed to be a curriculum for building a community at
Apache. This program is the equivalent of pointing students at
Wikipedia and berating them for failing tests.
> Once one understands the principles of why the ASF as a foundation
> needs to do certain things, then the so-called rules are obvious
> consequences.
Enumerate these principles and demonstrate the logical entailment of
source releases.
> Do not get hung up on so-called rules and so-called bureaucracy.
> Rather they are processes to enable smooth running
> of a Corporation.
Good advice for the IPMC. -C
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: concerns about high overhead in Apache incubator releases
Posted by Ross Gardler <rg...@opendirective.com>.
On 29 November 2011 00:12, David Crossley <cr...@apache.org> wrote:
> When Apache Forrest became a TLP, just prior to the Incubator starting,
> there were no mentors to tell me stuff.
HeHe - and that's exactly where I learned it - although I was lucky
enough to have mentors within the project. That's one reason why I say
documentation + mentors should be enough.
> Do not get hung up on so-called rules and so-called bureaucracy.
> Rather they are processes to enable smooth running
> of a Corporation.
+1000
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: concerns about high overhead in Apache incubator releases
Posted by David Crossley <cr...@apache.org>.
Search for the two words: release veto
A top hit is http://www.apache.org/foundation/voting.html#ReleaseVotes
It has been that way for a long time.
It is the Release Manager who decides whether to halt a release.
They are guided by +1/-1 votes.
I cannot understand why people are confused on those points.
When Apache Forrest became a TLP, just prior to the Incubator starting,
there were no mentors to tell me stuff.
One of the first jobs was to establish our project guidelines, then
work out our own release process.
I used a combination of net search and wandering around some of the
well-established projects to read their documented release and
voting processes and guidelines. For example, Http Server as they
started the whole shebang, and Ant as Stefan had written one of
the original how-to-mirror guides.
Not everything was written in docs, and still not.
Not everything needs to be, as lots is common sense.
The email archives are "documents".
Once one understands the principles of why the ASF as a foundation
needs to do certain things, then the so-called rules are obvious
consequences.
I reckon that every Release Manager needs to spend time
researching and understanding, as they need to herd their
project team.
It is useful to document your own release process guidelines
with links to relevant documentation/email;
refine for each release;
other people can oversee that doc and remedy mis-understandings;
rest of your team can follow each step in the release process;
transfer and evolve your knowledge.
Do not get hung up on so-called rules and so-called bureaucracy.
Rather they are processes to enable smooth running
of a Corporation.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Fwd: concerns about high overhead in Apache incubator releases
Posted by Jun Rao <ju...@gmail.com>.
Forgot to cc kafka-dev.
Jun
---------- Forwarded message ----------
From: Jun Rao <ju...@gmail.com>
Date: Mon, Nov 28, 2011 at 8:46 PM
Subject: Re: concerns about high overhead in Apache incubator releases
To: general@incubator.apache.org, antelder@apache.org
Thanks everyone for the feedback. This is very constructive and helpful. We
will try to roll out a new RC accordingly.
We are grateful for all the help that we got from Apache members and are
proud to be part of Apache.
Jun
On Mon, Nov 28, 2011 at 1:05 PM, ant elder <an...@gmail.com> wrote:
> On Sun, Nov 27, 2011 at 7:13 PM, Jun Rao <ju...@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
> >
>
> I'd like to apologize on behalf of the Incubator for this less than
> excellent experience with your first release. Releases can be hard and
> they are one of the top things poddlings need to learn how to do but
> we should have been a bit better at teaching this and not let this
> release become such a long drawn out and painful process.
>
> As others have also commented in this email thread releases can't be
> veto'ed so just because you have a -1 or negative comment doesn't mean
> you need to respin right away. It does mean though that others might
> be put off from voting +1 so if that happens get your mentors to sort
> out it if its an issue or not, and don't be shy about emailing them
> directly if they are not participating already.
>
> Your email also mentions "rules" in several places - there aren't that
> many rules so before assuming something really is a rule try to find
> where its document that it is, and if no one can find that doc then
> its not a rule. Also, rules are only defined on policy pages so just
> because some "guide" type page says something doesn't make it true.
> For example, the comment about needing to vote once on kafka-dev for
> 72 hours and then again on general@ for another 72 hours - nothing
> says that must happen, if you like start right off here on general@,
> or, keep it just on kafka-dev and persuade three Incubator PMC members
> to vote over there (though you should probably notify general@ thats
> happening just so we know). In fact, even the minimum of 72 hours
> isn't a rule - the voting page people have been pointing you to only
> says "Votes should generally be permitted to run for at least 72
> hours..." so there is flexibility there.
>
> However those comments aside you do still need to try to make your
> release artifacts reasonably correct. Once you've got this done in the
> first release it becomes less of a pain later because it likely wont
> change that much in subsequent releases. A problem with doing this for
> Kafka is that it has quite a lot of dependencies, 54 jars by a quick
> count, so its a big job tracking down what all the licensing
> conditions are. Additionally, what is there now in the LICENSE and
> NOTICE files doesn't have any comments on why its there or what it
> applies to so it makes it difficult to work out if it should be there
> or not. For example, the LICENSE file presently includes things like
> the MIT license but I don't know why, if you had a comment at the top
> of each license saying its there because xyz.jar uses it then it would
> be much clearer and easier to work out if its required or not.
>
> To move this along I think you should now go ask your three mentors to
> help you get the current release artifacts sorted out and all the
> LICENSE and NOTICE files updated correctly based on all the RC review
> comments, thats what the signed up to help with, email them directly
> to ask and if they don't answer quickly ask for someone else here to
> help. Ping general@ when its almost done so we can do a quick review
> and only then call a new vote.
>
> ...ant
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: concerns about high overhead in Apache incubator releases
Posted by Jun Rao <ju...@gmail.com>.
Thanks everyone for the feedback. This is very constructive and helpful. We
will try to roll out a new RC accordingly.
We are grateful for all the help that we got from Apache members and are
proud to be part of Apache.
Jun
On Mon, Nov 28, 2011 at 1:05 PM, ant elder <an...@gmail.com> wrote:
> On Sun, Nov 27, 2011 at 7:13 PM, Jun Rao <ju...@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
> >
>
> I'd like to apologize on behalf of the Incubator for this less than
> excellent experience with your first release. Releases can be hard and
> they are one of the top things poddlings need to learn how to do but
> we should have been a bit better at teaching this and not let this
> release become such a long drawn out and painful process.
>
> As others have also commented in this email thread releases can't be
> veto'ed so just because you have a -1 or negative comment doesn't mean
> you need to respin right away. It does mean though that others might
> be put off from voting +1 so if that happens get your mentors to sort
> out it if its an issue or not, and don't be shy about emailing them
> directly if they are not participating already.
>
> Your email also mentions "rules" in several places - there aren't that
> many rules so before assuming something really is a rule try to find
> where its document that it is, and if no one can find that doc then
> its not a rule. Also, rules are only defined on policy pages so just
> because some "guide" type page says something doesn't make it true.
> For example, the comment about needing to vote once on kafka-dev for
> 72 hours and then again on general@ for another 72 hours - nothing
> says that must happen, if you like start right off here on general@,
> or, keep it just on kafka-dev and persuade three Incubator PMC members
> to vote over there (though you should probably notify general@ thats
> happening just so we know). In fact, even the minimum of 72 hours
> isn't a rule - the voting page people have been pointing you to only
> says "Votes should generally be permitted to run for at least 72
> hours..." so there is flexibility there.
>
> However those comments aside you do still need to try to make your
> release artifacts reasonably correct. Once you've got this done in the
> first release it becomes less of a pain later because it likely wont
> change that much in subsequent releases. A problem with doing this for
> Kafka is that it has quite a lot of dependencies, 54 jars by a quick
> count, so its a big job tracking down what all the licensing
> conditions are. Additionally, what is there now in the LICENSE and
> NOTICE files doesn't have any comments on why its there or what it
> applies to so it makes it difficult to work out if it should be there
> or not. For example, the LICENSE file presently includes things like
> the MIT license but I don't know why, if you had a comment at the top
> of each license saying its there because xyz.jar uses it then it would
> be much clearer and easier to work out if its required or not.
>
> To move this along I think you should now go ask your three mentors to
> help you get the current release artifacts sorted out and all the
> LICENSE and NOTICE files updated correctly based on all the RC review
> comments, thats what the signed up to help with, email them directly
> to ask and if they don't answer quickly ask for someone else here to
> help. Ping general@ when its almost done so we can do a quick review
> and only then call a new vote.
>
> ...ant
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: concerns about high overhead in Apache incubator releases
Posted by ant elder <an...@gmail.com>.
On Sun, Nov 27, 2011 at 7:13 PM, Jun Rao <ju...@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
>
I'd like to apologize on behalf of the Incubator for this less than
excellent experience with your first release. Releases can be hard and
they are one of the top things poddlings need to learn how to do but
we should have been a bit better at teaching this and not let this
release become such a long drawn out and painful process.
As others have also commented in this email thread releases can't be
veto'ed so just because you have a -1 or negative comment doesn't mean
you need to respin right away. It does mean though that others might
be put off from voting +1 so if that happens get your mentors to sort
out it if its an issue or not, and don't be shy about emailing them
directly if they are not participating already.
Your email also mentions "rules" in several places - there aren't that
many rules so before assuming something really is a rule try to find
where its document that it is, and if no one can find that doc then
its not a rule. Also, rules are only defined on policy pages so just
because some "guide" type page says something doesn't make it true.
For example, the comment about needing to vote once on kafka-dev for
72 hours and then again on general@ for another 72 hours - nothing
says that must happen, if you like start right off here on general@,
or, keep it just on kafka-dev and persuade three Incubator PMC members
to vote over there (though you should probably notify general@ thats
happening just so we know). In fact, even the minimum of 72 hours
isn't a rule - the voting page people have been pointing you to only
says "Votes should generally be permitted to run for at least 72
hours..." so there is flexibility there.
However those comments aside you do still need to try to make your
release artifacts reasonably correct. Once you've got this done in the
first release it becomes less of a pain later because it likely wont
change that much in subsequent releases. A problem with doing this for
Kafka is that it has quite a lot of dependencies, 54 jars by a quick
count, so its a big job tracking down what all the licensing
conditions are. Additionally, what is there now in the LICENSE and
NOTICE files doesn't have any comments on why its there or what it
applies to so it makes it difficult to work out if it should be there
or not. For example, the LICENSE file presently includes things like
the MIT license but I don't know why, if you had a comment at the top
of each license saying its there because xyz.jar uses it then it would
be much clearer and easier to work out if its required or not.
To move this along I think you should now go ask your three mentors to
help you get the current release artifacts sorted out and all the
LICENSE and NOTICE files updated correctly based on all the RC review
comments, thats what the signed up to help with, email them directly
to ask and if they don't answer quickly ask for someone else here to
help. Ping general@ when its almost done so we can do a quick review
and only then call a new vote.
...ant
Re: concerns about high overhead in Apache incubator releases
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message -----
> From: Jun Rao <ju...@gmail.com>
> To: general@incubator.apache.org
> Cc: kafka-dev@incubator.apache.org
> Sent: Sunday, November 27, 2011 2:13 PM
> Subject: concerns about high overhead in Apache incubator releases
>
> Dear Apache members,
[...]
> 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.
NO. The only time someone can claim to hold a veto over a release vote is
when they are jibberjabbering about legal issues. NOTICE errors really
don't risk a lawsuit from anyone, so those -1's are NOT vetoes.
(Now that I've written that, it's possible/probable that someone will offer
you a different opinion. What you should do as an incubating participant
is challenge any such opinions with a reference to supporting website
documentation.)
Yes, I share your frustrations with the whole experience here in general.
However, IME good and active mentors can mitigate a lot of the problems
you face as a podling. Yes there will be times when we have to argue things
out, but that aspect is one of the features of an org that tries to stay
flexible and not overrely on an abundance of rules set a long time ago.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: concerns about high overhead in Apache incubator releases
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Nov 27, 2011 at 7:13 PM, Jun Rao <ju...@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.
(Thanks to Joe for setting the VETO issue straight)
IMO The solution to the NOTICE and LICENSE is build automation with
more complete rules covering the common licenses. This is do-able and
we're working on it but we're short of resources (my recovery is
progressing well and hopefully Jochen will get well soon). If anyone
could spare a few cycles to help, that'd be great.
Robert
Re: concerns about high overhead in Apache incubator releases
Posted by ant elder <an...@gmail.com>.
On Sun, Nov 27, 2011 at 7:13 PM, Jun Rao <ju...@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
>
I'd like to apologize on behalf of the Incubator for this less than
excellent experience with your first release. Releases can be hard and
they are one of the top things poddlings need to learn how to do but
we should have been a bit better at teaching this and not let this
release become such a long drawn out and painful process.
As others have also commented in this email thread releases can't be
veto'ed so just because you have a -1 or negative comment doesn't mean
you need to respin right away. It does mean though that others might
be put off from voting +1 so if that happens get your mentors to sort
out it if its an issue or not, and don't be shy about emailing them
directly if they are not participating already.
Your email also mentions "rules" in several places - there aren't that
many rules so before assuming something really is a rule try to find
where its document that it is, and if no one can find that doc then
its not a rule. Also, rules are only defined on policy pages so just
because some "guide" type page says something doesn't make it true.
For example, the comment about needing to vote once on kafka-dev for
72 hours and then again on general@ for another 72 hours - nothing
says that must happen, if you like start right off here on general@,
or, keep it just on kafka-dev and persuade three Incubator PMC members
to vote over there (though you should probably notify general@ thats
happening just so we know). In fact, even the minimum of 72 hours
isn't a rule - the voting page people have been pointing you to only
says "Votes should generally be permitted to run for at least 72
hours..." so there is flexibility there.
However those comments aside you do still need to try to make your
release artifacts reasonably correct. Once you've got this done in the
first release it becomes less of a pain later because it likely wont
change that much in subsequent releases. A problem with doing this for
Kafka is that it has quite a lot of dependencies, 54 jars by a quick
count, so its a big job tracking down what all the licensing
conditions are. Additionally, what is there now in the LICENSE and
NOTICE files doesn't have any comments on why its there or what it
applies to so it makes it difficult to work out if it should be there
or not. For example, the LICENSE file presently includes things like
the MIT license but I don't know why, if you had a comment at the top
of each license saying its there because xyz.jar uses it then it would
be much clearer and easier to work out if its required or not.
To move this along I think you should now go ask your three mentors to
help you get the current release artifacts sorted out and all the
LICENSE and NOTICE files updated correctly based on all the RC review
comments, thats what the signed up to help with, email them directly
to ask and if they don't answer quickly ask for someone else here to
help. Ping general@ when its almost done so we can do a quick review
and only then call a new vote.
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: concerns about high overhead in Apache incubator releases
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Nov 27, 2011 at 7:13 PM, Jun Rao <ju...@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.
(Thanks to Joe for setting the VETO issue straight)
IMO The solution to the NOTICE and LICENSE is build automation with
more complete rules covering the common licenses. This is do-able and
we're working on it but we're short of resources (my recovery is
progressing well and hopefully Jochen will get well soon). If anyone
could spare a few cycles to help, that'd be great.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org