Hey All,

Our little project is going pretty well: we have good discussion and
questions on the mailing lists, very active development, and a good set of
production usage. What do people think about pursuing graduation to be a
top-level project?

The criteria for this are documented here:
http://incubator.apache.org/guides/graduation.html

By my reading the main requirements on an incubator for graduation are:

   - Successfully create an apache release.
   - Develop a diverse community (described in more detail here:
   http://incubator.apache.org/guides/graduation.html#community). It boils
   down to being an open community that fosters discussion and is not
   dependent on a single company for success.
   - Fulfill various technical requirements: project naming, etc.

I think we have met these requirements.

We struggled a bit with licensing and packaging issues but we got those
issues resolved and did a release and this should be pretty easy going
forward.

This started as a LinkedIn project, and there are a still a number of us at
LinkedIn, but the discussion, JIRAs, patches, etc seems to be much more
well dispersed over a broad community of users and contributors.

It would be good to here from anyone following the list what they think.
Are there other things we should do either before (or in parallel to)
pursuing graduation?

I would also appreciate help from anyone with Apache experience navigating
the process.

Cheers,

-Jay

On May 23, 2012, at 8:14 PM, Jay Kreps wrote:

> Hey All,
>
> Our little project is going pretty well: we have good discussion and
> questions on the mailing lists, very active development, and a good set of
> production usage. What do people think about pursuing graduation to be a
> top-level project?
>
> The criteria for this are documented here:
> http://incubator.apache.org/guides/graduation.html
>
> By my reading the main requirements on an incubator for graduation are:
>
>   - Successfully create an apache release.
>   - Develop a diverse community (described in more detail here:
>   http://incubator.apache.org/guides/graduation.html#community). It boils
>   down to being an open community that fosters discussion and is not
>   dependent on a single company for success.
>   - Fulfill various technical requirements: project naming, etc.
>
> I think we have met these requirements.
>
> We struggled a bit with licensing and packaging issues but we got those
> issues resolved and did a release and this should be pretty easy going
> forward.
>
> This started as a LinkedIn project, and there are a still a number of us at
> LinkedIn, but the discussion, JIRAs, patches, etc seems to be much more
> well dispersed over a broad community of users and contributors.
>
> It would be good to here from anyone following the list what they think.
> Are there other things we should do either before (or in parallel to)
> pursuing graduation?
>
> I would also appreciate help from anyone with Apache experience navigating
> the process.

I would support graduation.

It's customary that a mentor stick around for just a little bit, as a PMC member, to make sure the transition goes smoothly and to provide advice and guidance.  I won't have time to fill this roll.  Would any other mentors be interested?

Also, we should update the status page to fill missing info.
Regards,
Alan

 

I would support graduation also. I would like to stay involved after
graduation to help with the transition to a TLP.

-- Owen

Graduation is warranted.

On Thu, May 24, 2012 at 10:03 AM, Owen O'Malley <[EMAIL PROTECTED]> wrote:
> I would support graduation also. I would like to stay involved after
> graduation to help with the transition to a TLP.
>
> -- Owen

I support graduation.

Is diversity in PPMC a requirement for graduation? Currently, Kafka has
diversity in committers, but not in PPMC.

Thanks,

Jun

On Wed, May 23, 2012 at 8:14 PM, Jay Kreps <[EMAIL PROTECTED]> wrote:

> Hey All,
>
> Our little project is going pretty well: we have good discussion and
> questions on the mailing lists, very active development, and a good set of
> production usage. What do people think about pursuing graduation to be a
> top-level project?
>
> The criteria for this are documented here:
> http://incubator.apache.org/guides/graduation.html
>
> By my reading the main requirements on an incubator for graduation are:
>
>   - Successfully create an apache release.
>   - Develop a diverse community (described in more detail here:
>   http://incubator.apache.org/guides/graduation.html#community). It boils
>   down to being an open community that fosters discussion and is not
>   dependent on a single company for success.
>   - Fulfill various technical requirements: project naming, etc.
>
> I think we have met these requirements.
>
> We struggled a bit with licensing and packaging issues but we got those
> issues resolved and did a release and this should be pretty easy going
> forward.
>
> This started as a LinkedIn project, and there are a still a number of us at
> LinkedIn, but the discussion, JIRAs, patches, etc seems to be much more
> well dispersed over a broad community of users and contributors.
>
> It would be good to here from anyone following the list what they think.
> Are there other things we should do either before (or in parallel to)
> pursuing graduation?
>
> I would also appreciate help from anyone with Apache experience navigating
> the process.
>
> Cheers,
>
> -Jay
>

I think the advice from Alan was to wait for a while to add new committers
to the PMC, so I guess obviously if we make people wait a year we can't
really increase the PMC diversity very rapidly...

Thoughts from any Apache folks on this? I think we are not too religious
one way or the other but are just looking for the official "best practice".

-Jay

On Fri, May 25, 2012 at 9:04 AM, Jun Rao <[EMAIL PROTECTED]> wrote:

> I support graduation.
>
> Is diversity in PPMC a requirement for graduation? Currently, Kafka has
> diversity in committers, but not in PPMC.
>
> Thanks,
>
> Jun
>
> On Wed, May 23, 2012 at 8:14 PM, Jay Kreps <[EMAIL PROTECTED]> wrote:
>
> > Hey All,
> >
> > Our little project is going pretty well: we have good discussion and
> > questions on the mailing lists, very active development, and a good set
> of
> > production usage. What do people think about pursuing graduation to be a
> > top-level project?
> >
> > The criteria for this are documented here:
> > http://incubator.apache.org/guides/graduation.html
> >
> > By my reading the main requirements on an incubator for graduation are:
> >
> >   - Successfully create an apache release.
> >   - Develop a diverse community (described in more detail here:
> >   http://incubator.apache.org/guides/graduation.html#community). It
> boils
> >   down to being an open community that fosters discussion and is not
> >   dependent on a single company for success.
> >   - Fulfill various technical requirements: project naming, etc.
> >
> > I think we have met these requirements.
> >
> > We struggled a bit with licensing and packaging issues but we got those
> > issues resolved and did a release and this should be pretty easy going
> > forward.
> >
> > This started as a LinkedIn project, and there are a still a number of us
> at
> > LinkedIn, but the discussion, JIRAs, patches, etc seems to be much more
> > well dispersed over a broad community of users and contributors.
> >
> > It would be good to here from anyone following the list what they think.
> > Are there other things we should do either before (or in parallel to)
> > pursuing graduation?
> >
> > I would also appreciate help from anyone with Apache experience
> navigating
> > the process.
> >
> > Cheers,
> >
> > -Jay
> >
>

I believe there's value in adding new committers directly to the PPMC
during incubation.  We did this in Giraph and it worked out great.
There's not enough institutional experience in the IPMC during
Incubation (that's what the Mentors are for), so adding them in
immediately helps to grow that as quickly as possible.  As with
commiters, should they not participate they can be dropped during
graduation.

On Fri, May 25, 2012 at 10:19 AM, Jay Kreps <[EMAIL PROTECTED]> wrote:
> I think the advice from Alan was to wait for a while to add new committers
> to the PMC, so I guess obviously if we make people wait a year we can't
> really increase the PMC diversity very rapidly...
>
> Thoughts from any Apache folks on this? I think we are not too religious
> one way or the other but are just looking for the official "best practice".
>
> -Jay
>
> On Fri, May 25, 2012 at 9:04 AM, Jun Rao <[EMAIL PROTECTED]> wrote:
>
>> I support graduation.
>>
>> Is diversity in PPMC a requirement for graduation? Currently, Kafka has
>> diversity in committers, but not in PPMC.
>>
>> Thanks,
>>
>> Jun
>>
>> On Wed, May 23, 2012 at 8:14 PM, Jay Kreps <[EMAIL PROTECTED]> wrote:
>>
>> > Hey All,
>> >
>> > Our little project is going pretty well: we have good discussion and
>> > questions on the mailing lists, very active development, and a good set
>> of
>> > production usage. What do people think about pursuing graduation to be a
>> > top-level project?
>> >
>> > The criteria for this are documented here:
>> > http://incubator.apache.org/guides/graduation.html
>> >
>> > By my reading the main requirements on an incubator for graduation are:
>> >
>> >   - Successfully create an apache release.
>> >   - Develop a diverse community (described in more detail here:
>> >   http://incubator.apache.org/guides/graduation.html#community). It
>> boils
>> >   down to being an open community that fosters discussion and is not
>> >   dependent on a single company for success.
>> >   - Fulfill various technical requirements: project naming, etc.
>> >
>> > I think we have met these requirements.
>> >
>> > We struggled a bit with licensing and packaging issues but we got those
>> > issues resolved and did a release and this should be pretty easy going
>> > forward.
>> >
>> > This started as a LinkedIn project, and there are a still a number of us
>> at
>> > LinkedIn, but the discussion, JIRAs, patches, etc seems to be much more
>> > well dispersed over a broad community of users and contributors.
>> >
>> > It would be good to here from anyone following the list what they think.
>> > Are there other things we should do either before (or in parallel to)
>> > pursuing graduation?
>> >
>> > I would also appreciate help from anyone with Apache experience
>> navigating
>> > the process.
>> >
>> > Cheers,
>> >
>> > -Jay
>> >
>>

On Fri, May 25, 2012 at 11:32 AM, Jakob Homan <[EMAIL PROTECTED]> wrote:

> I believe there's value in adding new committers directly to the PPMC
> during incubation.  We did this in Giraph and it worked out great.
>

It is up to the project to come up with the proposed PMC as part of the
resolution to graduate. In my opinion, it wouldn't be unreasonable to put
all of the current committers on the proposed PMC and it would immediately
address the diversity issue.

-- Owen

Ah, makes sense.

-jay

On Fri, May 25, 2012 at 11:41 AM, Owen O'Malley <[EMAIL PROTECTED]> wrote:

> On Fri, May 25, 2012 at 11:32 AM, Jakob Homan <[EMAIL PROTECTED]> wrote:
>
> > I believe there's value in adding new committers directly to the PPMC
> > during incubation.  We did this in Giraph and it worked out great.
> >
>
> It is up to the project to come up with the proposed PMC as part of the
> resolution to graduate. In my opinion, it wouldn't be unreasonable to put
> all of the current committers on the proposed PMC and it would immediately
> address the diversity issue.
>
> -- Owen
>

I'd support graduation without any reservations. From all I've seen,
Kafka is an excellent Apache community and project. -C

On Wed, May 23, 2012 at 8:14 PM, Jay Kreps <[EMAIL PROTECTED]> wrote:
> Hey All,
>
> Our little project is going pretty well: we have good discussion and
> questions on the mailing lists, very active development, and a good set of
> production usage. What do people think about pursuing graduation to be a
> top-level project?
>
> The criteria for this are documented here:
> http://incubator.apache.org/guides/graduation.html
>
> By my reading the main requirements on an incubator for graduation are:
>
>   - Successfully create an apache release.
>   - Develop a diverse community (described in more detail here:
>   http://incubator.apache.org/guides/graduation.html#community). It boils
>   down to being an open community that fosters discussion and is not
>   dependent on a single company for success.
>   - Fulfill various technical requirements: project naming, etc.
>
> I think we have met these requirements.
>
> We struggled a bit with licensing and packaging issues but we got those
> issues resolved and did a release and this should be pretty easy going
> forward.
>
> This started as a LinkedIn project, and there are a still a number of us at
> LinkedIn, but the discussion, JIRAs, patches, etc seems to be much more
> well dispersed over a broad community of users and contributors.
>
> It would be good to here from anyone following the list what they think.
> Are there other things we should do either before (or in parallel to)
> pursuing graduation?
>
> I would also appreciate help from anyone with Apache experience navigating
> the process.
>
> Cheers,
>
> -Jay

We have a healthy community, one release, discussions on the mailing list
and active committers. I support graduation.

Regarding the PMC diversity, I'm thinking it wouldn't hurt to start
graduation discussion on incubator mailing list and first figure out if it
is a real issue or not.

Thanks,
Neha

On Fri, May 25, 2012 at 4:41 PM, Chris Douglas <[EMAIL PROTECTED]> wrote:

> I'd support graduation without any reservations. From all I've seen,
> Kafka is an excellent Apache community and project. -C
>
> On Wed, May 23, 2012 at 8:14 PM, Jay Kreps <[EMAIL PROTECTED]> wrote:
> > Hey All,
> >
> > Our little project is going pretty well: we have good discussion and
> > questions on the mailing lists, very active development, and a good set
> of
> > production usage. What do people think about pursuing graduation to be a
> > top-level project?
> >
> > The criteria for this are documented here:
> > http://incubator.apache.org/guides/graduation.html
> >
> > By my reading the main requirements on an incubator for graduation are:
> >
> >   - Successfully create an apache release.
> >   - Develop a diverse community (described in more detail here:
> >   http://incubator.apache.org/guides/graduation.html#community). It
> boils
> >   down to being an open community that fosters discussion and is not
> >   dependent on a single company for success.
> >   - Fulfill various technical requirements: project naming, etc.
> >
> > I think we have met these requirements.
> >
> > We struggled a bit with licensing and packaging issues but we got those
> > issues resolved and did a release and this should be pretty easy going
> > forward.
> >
> > This started as a LinkedIn project, and there are a still a number of us
> at
> > LinkedIn, but the discussion, JIRAs, patches, etc seems to be much more
> > well dispersed over a broad community of users and contributors.
> >
> > It would be good to here from anyone following the list what they think.
> > Are there other things we should do either before (or in parallel to)
> > pursuing graduation?
> >
> > I would also appreciate help from anyone with Apache experience
> navigating
> > the process.
> >
> > Cheers,
> >
> > -Jay
>

On 2012-05-23 23:32, Alan D. Cabrera wrote:
>> We struggled a bit with licensing and packaging issues but we got those
>> issues resolved and did a release and this should be pretty easy going
>> forward.

This is the one point I am hesitant about.  I think it would be
reasonable to ask us for a history of more than a single release (and
I'm not sure we got the mirror situation 100% right yet).  We sure we
got this one?

For the more important parts, It's exciting to see the community grow
(particular the diversity part, that's a great accomplishment and I know
takes significant commitment).  On that note I would be interested in
hearing from other committers about graduation.

This is a fair point. I am not sure of the best practices on the number of
releases to do before graduation. The Incubator docs imply a fairly low
bar:
"Projects need to cut releases. Apache projects need to understand how to
cut Apache releases. Therefore it is an important step during your stay in
the incubator to demonstrate the ability to create an Apache Release. Podlings
do not need to actually *publish* a release to demonstrate that they
understand how to accomplish such a feat. However, creating a release that
is approved by the incubator project management
committee<http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29>
 is usually the simplest way to do this."
(http://incubator.apache.org/guides/graduation.html#releases)

They refer to "a release" not "releases", and mention that they don't
particularly care if you publish it or not. We might want to set a higher
bar for ourselves, though.

We had planned on having 0.8 be the next release, and that is still a few
months out I suspect. However we did take a number of minor features and
fixes post 0.7 that are only on trunk it would probably be possible to do a
0.7.1 without too much drama and that would make that work available to
people in a more easily consumable form . On the other hand it would be
nice to just be heads down and focus on 0.8 too. So if people agree with
Chris's feedback there are three options:

1. Pursue graduation now
2. Do a 0.7.1 release, pursue graduation when that is completed
3. Wait until 0.8 is out, pursue graduation after that

Anyone have a strong preference for one of these options?

-Jay

On Tue, Jun 5, 2012 at 7:17 PM, Chris Burroughs
<[EMAIL PROTECTED]>wrote:

> On 2012-05-23 23:32, Alan D. Cabrera wrote:
> >> We struggled a bit with licensing and packaging issues but we got those
> >> issues resolved and did a release and this should be pretty easy going
> >> forward.
>
> This is the one point I am hesitant about.  I think it would be
> reasonable to ask us for a history of more than a single release (and
> I'm not sure we got the mirror situation 100% right yet).  We sure we
> got this one?
>
> For the more important parts, It's exciting to see the community grow
> (particular the diversity part, that's a great accomplishment and I know
> takes significant commitment).  On that note I would be interested in
> hearing from other committers about graduation.
>

I think an 0.7.1 release would be suitable in any case given that there are
few additional features and API changes since 0.7.0 - I can drive that,
although an 0.7.1 release need not necessarily hold up pursuing graduation
if people prefer (1).

Joel

On Wed, Jun 6, 2012 at 12:51 PM, Jay Kreps <[EMAIL PROTECTED]> wrote:

> This is a fair point. I am not sure of the best practices on the number of
> releases to do before graduation. The Incubator docs imply a fairly low
> bar:
> "Projects need to cut releases. Apache projects need to understand how to
> cut Apache releases. Therefore it is an important step during your stay in
> the incubator to demonstrate the ability to create an Apache Release.
> Podlings
> do not need to actually *publish* a release to demonstrate that they
> understand how to accomplish such a feat. However, creating a release that
> is approved by the incubator project management
> committee<
> http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29
> >
>  is usually the simplest way to do this."
> (http://incubator.apache.org/guides/graduation.html#releases)
>
> They refer to "a release" not "releases", and mention that they don't
> particularly care if you publish it or not. We might want to set a higher
> bar for ourselves, though.
>
> We had planned on having 0.8 be the next release, and that is still a few
> months out I suspect. However we did take a number of minor features and
> fixes post 0.7 that are only on trunk it would probably be possible to do a
> 0.7.1 without too much drama and that would make that work available to
> people in a more easily consumable form . On the other hand it would be
> nice to just be heads down and focus on 0.8 too. So if people agree with
> Chris's feedback there are three options:
>
> 1. Pursue graduation now
> 2. Do a 0.7.1 release, pursue graduation when that is completed
> 3. Wait until 0.8 is out, pursue graduation after that
>
> Anyone have a strong preference for one of these options?
>
> -Jay
>
> On Tue, Jun 5, 2012 at 7:17 PM, Chris Burroughs
> <[EMAIL PROTECTED]>wrote:
>
> > On 2012-05-23 23:32, Alan D. Cabrera wrote:
> > >> We struggled a bit with licensing and packaging issues but we got
> those
> > >> issues resolved and did a release and this should be pretty easy going
> > >> forward.
> >
> > This is the one point I am hesitant about.  I think it would be
> > reasonable to ask us for a history of more than a single release (and
> > I'm not sure we got the mirror situation 100% right yet).  We sure we
> > got this one?
> >
> > For the more important parts, It's exciting to see the community grow
> > (particular the diversity part, that's a great accomplishment and I know
> > takes significant commitment).  On that note I would be interested in
> > hearing from other committers about graduation.
> >
>

I like option 1 since going with option 1 might make the next release go
smoother.

Thanks,
Neha

On Wed, Jun 6, 2012 at 5:46 PM, Joel Koshy <[EMAIL PROTECTED]> wrote:

> I think an 0.7.1 release would be suitable in any case given that there are
> few additional features and API changes since 0.7.0 - I can drive that,
> although an 0.7.1 release need not necessarily hold up pursuing graduation
> if people prefer (1).
>
> Joel
>
> On Wed, Jun 6, 2012 at 12:51 PM, Jay Kreps <[EMAIL PROTECTED]> wrote:
>
> > This is a fair point. I am not sure of the best practices on the number
> of
> > releases to do before graduation. The Incubator docs imply a fairly low
> > bar:
> > "Projects need to cut releases. Apache projects need to understand how to
> > cut Apache releases. Therefore it is an important step during your stay
> in
> > the incubator to demonstrate the ability to create an Apache Release.
> > Podlings
> > do not need to actually *publish* a release to demonstrate that they
> > understand how to accomplish such a feat. However, creating a release
> that
> > is approved by the incubator project management
> > committee<
> >
> http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29
> > >
> >  is usually the simplest way to do this."
> > (http://incubator.apache.org/guides/graduation.html#releases)
> >
> > They refer to "a release" not "releases", and mention that they don't
> > particularly care if you publish it or not. We might want to set a higher
> > bar for ourselves, though.
> >
> > We had planned on having 0.8 be the next release, and that is still a few
> > months out I suspect. However we did take a number of minor features and
> > fixes post 0.7 that are only on trunk it would probably be possible to
> do a
> > 0.7.1 without too much drama and that would make that work available to
> > people in a more easily consumable form . On the other hand it would be
> > nice to just be heads down and focus on 0.8 too. So if people agree with
> > Chris's feedback there are three options:
> >
> > 1. Pursue graduation now
> > 2. Do a 0.7.1 release, pursue graduation when that is completed
> > 3. Wait until 0.8 is out, pursue graduation after that
> >
> > Anyone have a strong preference for one of these options?
> >
> > -Jay
> >
> > On Tue, Jun 5, 2012 at 7:17 PM, Chris Burroughs
> > <[EMAIL PROTECTED]>wrote:
> >
> > > On 2012-05-23 23:32, Alan D. Cabrera wrote:
> > > >> We struggled a bit with licensing and packaging issues but we got
> > those
> > > >> issues resolved and did a release and this should be pretty easy
> going
> > > >> forward.
> > >
> > > This is the one point I am hesitant about.  I think it would be
> > > reasonable to ask us for a history of more than a single release (and
> > > I'm not sure we got the mirror situation 100% right yet).  We sure we
> > > got this one?
> > >
> > > For the more important parts, It's exciting to see the community grow
> > > (particular the diversity part, that's a great accomplishment and I
> know
> > > takes significant commitment).  On that note I would be interested in
> > > hearing from other committers about graduation.
> > >
> >
>

> This is the one point I am hesitant about.  I think it would be
> reasonable to ask us for a history of more than a single release

True, but I'd characterize this differently. A single release is not
necessarily a single data point. The Kafka community endured an
arduous series of RCs that exposed its members to a wide range of
Apache processes, conventions, and individual members. There was a lot
of experience transferred in that one release. Further, observation of
that episode (broadcast broadly on general@incubator) should yield
sufficient data for any interested observer to extrapolate the
podling's chances as a TLP.

That said, a point release would round out the incubation and spread
RM experience among other members of the project. I'd also recommend
option (2) for that reason, but hope graduation would soon follow.

> (and
> I'm not sure we got the mirror situation 100% right yet).  We sure we
> got this one?

Huh... is this why the Clutch status page isn't all green?

http://incubator.apache.org/clutch.html

-C

On Wed, Jun 6, 2012 at 12:51 PM, Jay Kreps <[EMAIL PROTECTED]> wrote:
> This is a fair point. I am not sure of the best practices on the number of
> releases to do before graduation. The Incubator docs imply a fairly low
> bar:
> "Projects need to cut releases. Apache projects need to understand how to
> cut Apache releases. Therefore it is an important step during your stay in
> the incubator to demonstrate the ability to create an Apache Release. Podlings
> do not need to actually *publish* a release to demonstrate that they
> understand how to accomplish such a feat. However, creating a release that
> is approved by the incubator project management
> committee<http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29>
>  is usually the simplest way to do this."
> (http://incubator.apache.org/guides/graduation.html#releases)
>
> They refer to "a release" not "releases", and mention that they don't
> particularly care if you publish it or not. We might want to set a higher
> bar for ourselves, though.
>
> We had planned on having 0.8 be the next release, and that is still a few
> months out I suspect. However we did take a number of minor features and
> fixes post 0.7 that are only on trunk it would probably be possible to do a
> 0.7.1 without too much drama and that would make that work available to
> people in a more easily consumable form . On the other hand it would be
> nice to just be heads down and focus on 0.8 too. So if people agree with
> Chris's feedback there are three options:
>
> 1. Pursue graduation now
> 2. Do a 0.7.1 release, pursue graduation when that is completed
> 3. Wait until 0.8 is out, pursue graduation after that
>
> Anyone have a strong preference for one of these options?
>
> -Jay
>
> On Tue, Jun 5, 2012 at 7:17 PM, Chris Burroughs
> <[EMAIL PROTECTED]>wrote:
>
>> On 2012-05-23 23:32, Alan D. Cabrera wrote:
>> >> We struggled a bit with licensing and packaging issues but we got those
>> >> issues resolved and did a release and this should be pretty easy going
>> >> forward.
>>
>> This is the one point I am hesitant about.  I think it would be
>> reasonable to ask us for a history of more than a single release (and
>> I'm not sure we got the mirror situation 100% right yet).  We sure we
>> got this one?
>>
>> For the more important parts, It's exciting to see the community grow
>> (particular the diversity part, that's a great accomplishment and I know
>> takes significant commitment).  On that note I would be interested in
>> hearing from other committers about graduation.
>>

On Jun 5, 2012, at 7:17 PM, Chris Burroughs wrote:

> On 2012-05-23 23:32, Alan D. Cabrera wrote:
>>> We struggled a bit with licensing and packaging issues but we got those
>>> issues resolved and did a release and this should be pretty easy going
>>> forward.
>
> This is the one point I am hesitant about.  I think it would be
> reasonable to ask us for a history of more than a single release (and
> I'm not sure we got the mirror situation 100% right yet).  We sure we
> got this one?

Nice to have but not a requirement.  IMO, the PPMC has proven that they are capable of performing a release.
Regards,
Alan

 

Actually, any committers outside of LinkedIn is interested in drive an
0.7.1 release? That will help diversifying the community. It should be much
easier than the 0.7.0 release since most of the licensing issues have been
resolved.

Thanks,

Jun

On Wed, Jun 6, 2012 at 5:46 PM, Joel Koshy <[EMAIL PROTECTED]> wrote:

> I think an 0.7.1 release would be suitable in any case given that there are
> few additional features and API changes since 0.7.0 - I can drive that,
> although an 0.7.1 release need not necessarily hold up pursuing graduation
> if people prefer (1).
>
> Joel
>
> On Wed, Jun 6, 2012 at 12:51 PM, Jay Kreps <[EMAIL PROTECTED]> wrote:
>
> > This is a fair point. I am not sure of the best practices on the number
> of
> > releases to do before graduation. The Incubator docs imply a fairly low
> > bar:
> > "Projects need to cut releases. Apache projects need to understand how to
> > cut Apache releases. Therefore it is an important step during your stay
> in
> > the incubator to demonstrate the ability to create an Apache Release.
> > Podlings
> > do not need to actually *publish* a release to demonstrate that they
> > understand how to accomplish such a feat. However, creating a release
> that
> > is approved by the incubator project management
> > committee<
> >
> http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29
> > >
> >  is usually the simplest way to do this."
> > (http://incubator.apache.org/guides/graduation.html#releases)
> >
> > They refer to "a release" not "releases", and mention that they don't
> > particularly care if you publish it or not. We might want to set a higher
> > bar for ourselves, though.
> >
> > We had planned on having 0.8 be the next release, and that is still a few
> > months out I suspect. However we did take a number of minor features and
> > fixes post 0.7 that are only on trunk it would probably be possible to
> do a
> > 0.7.1 without too much drama and that would make that work available to
> > people in a more easily consumable form . On the other hand it would be
> > nice to just be heads down and focus on 0.8 too. So if people agree with
> > Chris's feedback there are three options:
> >
> > 1. Pursue graduation now
> > 2. Do a 0.7.1 release, pursue graduation when that is completed
> > 3. Wait until 0.8 is out, pursue graduation after that
> >
> > Anyone have a strong preference for one of these options?
> >
> > -Jay
> >
> > On Tue, Jun 5, 2012 at 7:17 PM, Chris Burroughs
> > <[EMAIL PROTECTED]>wrote:
> >
> > > On 2012-05-23 23:32, Alan D. Cabrera wrote:
> > > >> We struggled a bit with licensing and packaging issues but we got
> > those
> > > >> issues resolved and did a release and this should be pretty easy
> going
> > > >> forward.
> > >
> > > This is the one point I am hesitant about.  I think it would be
> > > reasonable to ask us for a history of more than a single release (and
> > > I'm not sure we got the mirror situation 100% right yet).  We sure we
> > > got this one?
> > >
> > > For the more important parts, It's exciting to see the community grow
> > > (particular the diversity part, that's a great accomplishment and I
> know
> > > takes significant commitment).  On that note I would be interested in
> > > hearing from other committers about graduation.
> > >
> >
>

I would be interested to drive a 0.7.1 release.

On Jun 8, 2012, at 12:23 PM, Jun Rao <[EMAIL PROTECTED]> wrote:

> Actually, any committers outside of LinkedIn is interested in drive an
> 0.7.1 release? That will help diversifying the community. It should be much
> easier than the 0.7.0 release since most of the licensing issues have been
> resolved.
>
> Thanks,
>
> Jun
>
> On Wed, Jun 6, 2012 at 5:46 PM, Joel Koshy <[EMAIL PROTECTED]> wrote:
>
>> I think an 0.7.1 release would be suitable in any case given that there are
>> few additional features and API changes since 0.7.0 - I can drive that,
>> although an 0.7.1 release need not necessarily hold up pursuing graduation
>> if people prefer (1).
>>
>> Joel
>>
>> On Wed, Jun 6, 2012 at 12:51 PM, Jay Kreps <[EMAIL PROTECTED]> wrote:
>>
>>> This is a fair point. I am not sure of the best practices on the number
>> of
>>> releases to do before graduation. The Incubator docs imply a fairly low
>>> bar:
>>> "Projects need to cut releases. Apache projects need to understand how to
>>> cut Apache releases. Therefore it is an important step during your stay
>> in
>>> the incubator to demonstrate the ability to create an Apache Release.
>>> Podlings
>>> do not need to actually *publish* a release to demonstrate that they
>>> understand how to accomplish such a feat. However, creating a release
>> that
>>> is approved by the incubator project management
>>> committee<
>>>
>> http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29
>>>>
>>> is usually the simplest way to do this."
>>> (http://incubator.apache.org/guides/graduation.html#releases)
>>>
>>> They refer to "a release" not "releases", and mention that they don't
>>> particularly care if you publish it or not. We might want to set a higher
>>> bar for ourselves, though.
>>>
>>> We had planned on having 0.8 be the next release, and that is still a few
>>> months out I suspect. However we did take a number of minor features and
>>> fixes post 0.7 that are only on trunk it would probably be possible to
>> do a
>>> 0.7.1 without too much drama and that would make that work available to
>>> people in a more easily consumable form . On the other hand it would be
>>> nice to just be heads down and focus on 0.8 too. So if people agree with
>>> Chris's feedback there are three options:
>>>
>>> 1. Pursue graduation now
>>> 2. Do a 0.7.1 release, pursue graduation when that is completed
>>> 3. Wait until 0.8 is out, pursue graduation after that
>>>
>>> Anyone have a strong preference for one of these options?
>>>
>>> -Jay
>>>
>>> On Tue, Jun 5, 2012 at 7:17 PM, Chris Burroughs
>>> <[EMAIL PROTECTED]>wrote:
>>>
>>>> On 2012-05-23 23:32, Alan D. Cabrera wrote:
>>>>>> We struggled a bit with licensing and packaging issues but we got
>>> those
>>>>>> issues resolved and did a release and this should be pretty easy
>> going
>>>>>> forward.
>>>>
>>>> This is the one point I am hesitant about.  I think it would be
>>>> reasonable to ask us for a history of more than a single release (and
>>>> I'm not sure we got the mirror situation 100% right yet).  We sure we
>>>> got this one?
>>>>
>>>> For the more important parts, It's exciting to see the community grow
>>>> (particular the diversity part, that's a great accomplishment and I
>> know
>>>> takes significant commitment).  On that note I would be interested in
>>>> hearing from other committers about graduation.
>>>>
>>>
>>

That's awesome, Joe. So it sounds like the plan is to do a 0.7.1 release
and then pursue graduation? There were a few who just wanted to go for it,
any objection to waiting a bit to get this release out?

-Jay

On Fri, Jun 8, 2012 at 10:59 AM, Joe Stein <[EMAIL PROTECTED]> wrote:

> I would be interested to drive a 0.7.1 release.
>
> On Jun 8, 2012, at 12:23 PM, Jun Rao <[EMAIL PROTECTED]> wrote:
>
> > Actually, any committers outside of LinkedIn is interested in drive an
> > 0.7.1 release? That will help diversifying the community. It should be
> much
> > easier than the 0.7.0 release since most of the licensing issues have
> been
> > resolved.
> >
> > Thanks,
> >
> > Jun
> >
> > On Wed, Jun 6, 2012 at 5:46 PM, Joel Koshy <[EMAIL PROTECTED]> wrote:
> >
> >> I think an 0.7.1 release would be suitable in any case given that there
> are
> >> few additional features and API changes since 0.7.0 - I can drive that,
> >> although an 0.7.1 release need not necessarily hold up pursuing
> graduation
> >> if people prefer (1).
> >>
> >> Joel
> >>
> >> On Wed, Jun 6, 2012 at 12:51 PM, Jay Kreps <[EMAIL PROTECTED]> wrote:
> >>
> >>> This is a fair point. I am not sure of the best practices on the number
> >> of
> >>> releases to do before graduation. The Incubator docs imply a fairly low
> >>> bar:
> >>> "Projects need to cut releases. Apache projects need to understand how
> to
> >>> cut Apache releases. Therefore it is an important step during your stay
> >> in
> >>> the incubator to demonstrate the ability to create an Apache Release.
> >>> Podlings
> >>> do not need to actually *publish* a release to demonstrate that they
> >>> understand how to accomplish such a feat. However, creating a release
> >> that
> >>> is approved by the incubator project management
> >>> committee<
> >>>
> >>
> http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29
> >>>>
> >>> is usually the simplest way to do this."
> >>> (http://incubator.apache.org/guides/graduation.html#releases)
> >>>
> >>> They refer to "a release" not "releases", and mention that they don't
> >>> particularly care if you publish it or not. We might want to set a
> higher
> >>> bar for ourselves, though.
> >>>
> >>> We had planned on having 0.8 be the next release, and that is still a
> few
> >>> months out I suspect. However we did take a number of minor features
> and
> >>> fixes post 0.7 that are only on trunk it would probably be possible to
> >> do a
> >>> 0.7.1 without too much drama and that would make that work available to
> >>> people in a more easily consumable form . On the other hand it would be
> >>> nice to just be heads down and focus on 0.8 too. So if people agree
> with
> >>> Chris's feedback there are three options:
> >>>
> >>> 1. Pursue graduation now
> >>> 2. Do a 0.7.1 release, pursue graduation when that is completed
> >>> 3. Wait until 0.8 is out, pursue graduation after that
> >>>
> >>> Anyone have a strong preference for one of these options?
> >>>
> >>> -Jay
> >>>
> >>> On Tue, Jun 5, 2012 at 7:17 PM, Chris Burroughs
> >>> <[EMAIL PROTECTED]>wrote:
> >>>
> >>>> On 2012-05-23 23:32, Alan D. Cabrera wrote:
> >>>>>> We struggled a bit with licensing and packaging issues but we got
> >>> those
> >>>>>> issues resolved and did a release and this should be pretty easy
> >> going
> >>>>>> forward.
> >>>>
> >>>> This is the one point I am hesitant about.  I think it would be
> >>>> reasonable to ask us for a history of more than a single release (and
> >>>> I'm not sure we got the mirror situation 100% right yet).  We sure we
> >>>> got this one?
> >>>>
> >>>> For the more important parts, It's exciting to see the community grow
> >>>> (particular the diversity part, that's a great accomplishment and I
> >> know
> >>>> takes significant commitment).  On that note I would be interested in
> >>>> hearing from other committers about graduation.
> >>>>
> >>>
> >>
>