Re: Mentor docs: Incubator Access Authorization

[Henri Yandell]

Answering myself, it went to git.

https://git-wip-us.apache.org/repos/asf?p=infrastructure-puppet.git;a=blob;f=modules/subversion_server/files/authorization/asf-authorization-template

Hen

On Tue, Jan 24, 2017 at 10:33 PM, Henri Yandell  wrote:

> This looks out of date:
>
>   http://incubator.apache.org/guides/mentor.html#who-auth-karma
>
> It says:
>
> 
> Incubator Access Authorization
>
> Special karma is required to authorize incubator access for committers.
> This karma is limited to:
>
>- PMC Chairs (past and present)
>- Selected people in the Infrastructure team
>
> If any mentor has karma then they should authorize the committer. To grant
> authorization, update:
> infrastructure/trunk/subversion/authorization/asf-authorization-template
> =
>
> That seems to have moved (been a year since I've touched this). Anyone
> know where the new location is?  Or is it there and I've just lost perms
> for some reason? :)
>
> Thanks,
>
> Hen
>
>

Mentor docs: Incubator Access Authorization

[Henri Yandell]

This looks out of date:

  http://incubator.apache.org/guides/mentor.html#who-auth-karma

It says:


Incubator Access Authorization

Special karma is required to authorize incubator access for committers.
This karma is limited to:

   - PMC Chairs (past and present)
   - Selected people in the Infrastructure team

If any mentor has karma then they should authorize the committer. To grant
authorization, update:
infrastructure/trunk/subversion/authorization/asf-authorization-template
=

That seems to have moved (been a year since I've touched this). Anyone know
where the new location is?  Or is it there and I've just lost perms for
some reason? :)

Thanks,

Hen

Re: [DISCUSS] Podling report format changes

[P. Taylor Goetz]

I'm fine with 1 and 3, but 2 gives me pause. I like the idea of the maturity 
model, but is it yet another burden on mentors?

If we are trying to increase mentor engagement, we probably don't want to set 
too high  a bar.

-Taylor

> On Jan 24, 2017, at 8:15 PM, John D. Ament  wrote:
> 
> All,
> 
> The Incubator PMC has received feedback from the board that changes may
> need to be made to the structure of our report.  Specifically, there is
> confusion from the board members over how podlings get classified.  There
> is also a request to increase and improve mentor feedback on podling
> reports.  Based on this input, I would like to propose the following
> changes to our report format.  I would like to try to implement this for
> the March report, if not before then.
> 
> 1. Eliminate the podling summary section of the report.  It shouldn't be on
> the report manager to classify each podling.  We have begun leveraging a
> maturity model for podlings, while its not required to fulfill it serves as
> an equivalent to this section.  The list of podlings who failed to report
> shall remain.
> 
> 2. Add a "Podling Maturity Assessment" to the individual podling reports.
> This would give a clear opportunity for each podling to describe how they
> are doing, perhaps compared to the maturity model or our classic categories.
> 
> 3. Change the mentor sign off section to include a per-mentor comment.
> E.g. instead of the current:
> 
>  [ ](podling) mentor1
>  [ ](podling) mentor2
>  [ ](podling) mentor3
> 
> It would be:
> 
>  [ ](podling) mentor1
>  Comments:
>  [ ](podling) mentor2
>  Comments:
>  [ ](podling) mentor3
>  Comments:
> 
> And rename Shepherd/Mentor notes: to just "Shepherd notes:"
> 
> Thoughts?
> 
> John

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Podling report format changes

[Jim Apple]

Ah, sorry for the paragraphs, then.

On Tue, Jan 24, 2017 at 5:52 PM, John D. Ament  wrote:
> Jim,
>
> Don't read too deeply into my use of "Podling Maturity Assessment."  The
> sections of the current summary are simply "Ready to Graduate", "Some
> Community Growth", "No Release" and "Still Getting Started."  I'm simply
> asking the podling to decide which of those 4 best describe themselves.
>
> John
>
> On Tue, Jan 24, 2017 at 8:40 PM Jim Apple  wrote:
>
>> There were a number of people who opposed the use of the maturity
>> model on this list in 2016. For instance, Greg Stein said: "There has
>> been past controversy on including that as a graduation step. I'm not
>> clear that was a proper addition." and "The Board has never required
>> the IPMC to use the APMM as a requirement for graduation."
>>
>> I find it to be pretty strange. Two examples:
>>
>> 1. "Convenience binaries can be distributed alongside source code but
>> they are not Apache Releases -- they are just a convenience provided
>> with no guarantee."
>>
>> I don't imagine this REQUIRES binaries, since
>> http://www.apache.org/legal/release-policy says:
>>
>> "The Apache Software Foundation produces open source software. All
>> releases are in the form of the source materials needed to make
>> changes to the software being released."
>>
>> So, if this isn't requiring binary releases, it seems to simply be
>> limiting them. That's fair enough, but how is that level level 4 of
>> "Releases" while "Releases are signed and/or distributed along with
>> digests", which requires actual work, is only level 3. Level 4 can be
>> achieved whilst napping by not guaranteeing anything while
>> sleepwalking.
>>
>> 2.  A number of the items don't seem to be mentioned in any other
>> incubating guide or don't seem to me to be true of TLPs in general.
>> Adding them here makes it look like there is new incubator policy that
>> snuck in the back door. Here are things I don't recall seeing
>> elsewhere:
>>
>> "The code can be built in a reproducible way using widely available
>> standard tools." -- widely available?
>>
>> "The project is open and honest about the quality of its code." --
>> Does anywhere else in the incubation documentation describe any sort
>> of quality disclosure procedure? What does this even mean -- what is
>> the scale?
>>
>> "The project puts a high priority on backwards compatibility" -- Is
>> this mentioned anywhere else on the incubation webpages?
>>
>> "The way in which contributors can be granted more rights such as
>> commit access or decision power is clearly documented" -- is this even
>> true for most TLPs? I spent some time looking at how big data TLPs
>> describe commit bit approvals, and most seem to be extremely vague in
>> describing what constitutes enough of a contribution to be granted the
>> bit.
>>
>> "The project is independent from any corporate or organizational
>> influence." -- Didn't Stratos just get moved to the attic because its
>> main corporate backer stopped backing it? How many other TLPs are in
>> this same boat?
>>
>> On Tue, Jan 24, 2017 at 5:15 PM, John D. Ament 
>> wrote:
>> > All,
>> >
>> > The Incubator PMC has received feedback from the board that changes may
>> > need to be made to the structure of our report.  Specifically, there is
>> > confusion from the board members over how podlings get classified.  There
>> > is also a request to increase and improve mentor feedback on podling
>> > reports.  Based on this input, I would like to propose the following
>> > changes to our report format.  I would like to try to implement this for
>> > the March report, if not before then.
>> >
>> > 1. Eliminate the podling summary section of the report.  It shouldn't be
>> on
>> > the report manager to classify each podling.  We have begun leveraging a
>> > maturity model for podlings, while its not required to fulfill it serves
>> as
>> > an equivalent to this section.  The list of podlings who failed to report
>> > shall remain.
>> >
>> > 2. Add a "Podling Maturity Assessment" to the individual podling reports.
>> > This would give a clear opportunity for each podling to describe how they
>> > are doing, perhaps compared to the maturity model or our classic
>> categories.
>> >
>> > 3. Change the mentor sign off section to include a per-mentor comment.
>> > E.g. instead of the current:
>> >
>> >   [ ](podling) mentor1
>> >   [ ](podling) mentor2
>> >   [ ](podling) mentor3
>> >
>> > It would be:
>> >
>> >   [ ](podling) mentor1
>> >   Comments:
>> >   [ ](podling) mentor2
>> >   Comments:
>> >   [ ](podling) mentor3
>> >   Comments:
>> >
>> > And rename Shepherd/Mentor notes: to just "Shepherd notes:"
>> >
>> > Thoughts?
>> >
>> > John
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: 

Re: [DISCUSS] Podling report format changes

[John D. Ament]

On Tue, Jan 24, 2017 at 8:54 PM Julian Hyde  wrote:

> John,
>
> What did you have in mind for “podling maturity assessment”? If it is
> simply one of the existing phases - “still getting started”, “no release”,
> “community growth”, “ready to graduate” - I can’t see that being
> contentious.
>
> Julian
>
>
Julian,

Exactly those.  But ultimately, freeform to let the podling describe how
they feel they are doing maturity wise.  E.g. I wouldn't want to write down
it must be one of those 4 items.

Obviously I'd update http://incubator.apache.org/guides/ppmc.html to
include this new section to explain how they feel they're doing.

John


>
>
> > On Jan 24, 2017, at 5:39 PM, Jim Apple  wrote:
> >
> > There were a number of people who opposed the use of the maturity
> > model on this list in 2016. For instance, Greg Stein said: "There has
> > been past controversy on including that as a graduation step. I'm not
> > clear that was a proper addition." and "The Board has never required
> > the IPMC to use the APMM as a requirement for graduation."
> >
> > I find it to be pretty strange. Two examples:
> >
> > 1. "Convenience binaries can be distributed alongside source code but
> > they are not Apache Releases -- they are just a convenience provided
> > with no guarantee."
> >
> > I don't imagine this REQUIRES binaries, since
> > http://www.apache.org/legal/release-policy says:
> >
> > "The Apache Software Foundation produces open source software. All
> > releases are in the form of the source materials needed to make
> > changes to the software being released."
> >
> > So, if this isn't requiring binary releases, it seems to simply be
> > limiting them. That's fair enough, but how is that level level 4 of
> > "Releases" while "Releases are signed and/or distributed along with
> > digests", which requires actual work, is only level 3. Level 4 can be
> > achieved whilst napping by not guaranteeing anything while
> > sleepwalking.
> >
> > 2.  A number of the items don't seem to be mentioned in any other
> > incubating guide or don't seem to me to be true of TLPs in general.
> > Adding them here makes it look like there is new incubator policy that
> > snuck in the back door. Here are things I don't recall seeing
> > elsewhere:
> >
> > "The code can be built in a reproducible way using widely available
> > standard tools." -- widely available?
> >
> > "The project is open and honest about the quality of its code." --
> > Does anywhere else in the incubation documentation describe any sort
> > of quality disclosure procedure? What does this even mean -- what is
> > the scale?
> >
> > "The project puts a high priority on backwards compatibility" -- Is
> > this mentioned anywhere else on the incubation webpages?
> >
> > "The way in which contributors can be granted more rights such as
> > commit access or decision power is clearly documented" -- is this even
> > true for most TLPs? I spent some time looking at how big data TLPs
> > describe commit bit approvals, and most seem to be extremely vague in
> > describing what constitutes enough of a contribution to be granted the
> > bit.
> >
> > "The project is independent from any corporate or organizational
> > influence." -- Didn't Stratos just get moved to the attic because its
> > main corporate backer stopped backing it? How many other TLPs are in
> > this same boat?
> >
> > On Tue, Jan 24, 2017 at 5:15 PM, John D. Ament 
> wrote:
> >> All,
> >>
> >> The Incubator PMC has received feedback from the board that changes may
> >> need to be made to the structure of our report.  Specifically, there is
> >> confusion from the board members over how podlings get classified.
> There
> >> is also a request to increase and improve mentor feedback on podling
> >> reports.  Based on this input, I would like to propose the following
> >> changes to our report format.  I would like to try to implement this for
> >> the March report, if not before then.
> >>
> >> 1. Eliminate the podling summary section of the report.  It shouldn't
> be on
> >> the report manager to classify each podling.  We have begun leveraging a
> >> maturity model for podlings, while its not required to fulfill it
> serves as
> >> an equivalent to this section.  The list of podlings who failed to
> report
> >> shall remain.
> >>
> >> 2. Add a "Podling Maturity Assessment" to the individual podling
> reports.
> >> This would give a clear opportunity for each podling to describe how
> they
> >> are doing, perhaps compared to the maturity model or our classic
> categories.
> >>
> >> 3. Change the mentor sign off section to include a per-mentor comment.
> >> E.g. instead of the current:
> >>
> >>  [ ](podling) mentor1
> >>  [ ](podling) mentor2
> >>  [ ](podling) mentor3
> >>
> >> It would be:
> >>
> >>  [ ](podling) mentor1
> >>  Comments:
> >>  [ ](podling) mentor2
> >>  Comments:
> >>  [ ](podling) mentor3
> >>  Comments:
> >>
> >> And rename 

Re: [DISCUSS] Podling report format changes

[Julian Hyde]

John,

What did you have in mind for “podling maturity assessment”? If it is simply 
one of the existing phases - “still getting started”, “no release”, “community 
growth”, “ready to graduate” - I can’t see that being contentious.

Julian



> On Jan 24, 2017, at 5:39 PM, Jim Apple  wrote:
> 
> There were a number of people who opposed the use of the maturity
> model on this list in 2016. For instance, Greg Stein said: "There has
> been past controversy on including that as a graduation step. I'm not
> clear that was a proper addition." and "The Board has never required
> the IPMC to use the APMM as a requirement for graduation."
> 
> I find it to be pretty strange. Two examples:
> 
> 1. "Convenience binaries can be distributed alongside source code but
> they are not Apache Releases -- they are just a convenience provided
> with no guarantee."
> 
> I don't imagine this REQUIRES binaries, since
> http://www.apache.org/legal/release-policy says:
> 
> "The Apache Software Foundation produces open source software. All
> releases are in the form of the source materials needed to make
> changes to the software being released."
> 
> So, if this isn't requiring binary releases, it seems to simply be
> limiting them. That's fair enough, but how is that level level 4 of
> "Releases" while "Releases are signed and/or distributed along with
> digests", which requires actual work, is only level 3. Level 4 can be
> achieved whilst napping by not guaranteeing anything while
> sleepwalking.
> 
> 2.  A number of the items don't seem to be mentioned in any other
> incubating guide or don't seem to me to be true of TLPs in general.
> Adding them here makes it look like there is new incubator policy that
> snuck in the back door. Here are things I don't recall seeing
> elsewhere:
> 
> "The code can be built in a reproducible way using widely available
> standard tools." -- widely available?
> 
> "The project is open and honest about the quality of its code." --
> Does anywhere else in the incubation documentation describe any sort
> of quality disclosure procedure? What does this even mean -- what is
> the scale?
> 
> "The project puts a high priority on backwards compatibility" -- Is
> this mentioned anywhere else on the incubation webpages?
> 
> "The way in which contributors can be granted more rights such as
> commit access or decision power is clearly documented" -- is this even
> true for most TLPs? I spent some time looking at how big data TLPs
> describe commit bit approvals, and most seem to be extremely vague in
> describing what constitutes enough of a contribution to be granted the
> bit.
> 
> "The project is independent from any corporate or organizational
> influence." -- Didn't Stratos just get moved to the attic because its
> main corporate backer stopped backing it? How many other TLPs are in
> this same boat?
> 
> On Tue, Jan 24, 2017 at 5:15 PM, John D. Ament  wrote:
>> All,
>> 
>> The Incubator PMC has received feedback from the board that changes may
>> need to be made to the structure of our report.  Specifically, there is
>> confusion from the board members over how podlings get classified.  There
>> is also a request to increase and improve mentor feedback on podling
>> reports.  Based on this input, I would like to propose the following
>> changes to our report format.  I would like to try to implement this for
>> the March report, if not before then.
>> 
>> 1. Eliminate the podling summary section of the report.  It shouldn't be on
>> the report manager to classify each podling.  We have begun leveraging a
>> maturity model for podlings, while its not required to fulfill it serves as
>> an equivalent to this section.  The list of podlings who failed to report
>> shall remain.
>> 
>> 2. Add a "Podling Maturity Assessment" to the individual podling reports.
>> This would give a clear opportunity for each podling to describe how they
>> are doing, perhaps compared to the maturity model or our classic categories.
>> 
>> 3. Change the mentor sign off section to include a per-mentor comment.
>> E.g. instead of the current:
>> 
>>  [ ](podling) mentor1
>>  [ ](podling) mentor2
>>  [ ](podling) mentor3
>> 
>> It would be:
>> 
>>  [ ](podling) mentor1
>>  Comments:
>>  [ ](podling) mentor2
>>  Comments:
>>  [ ](podling) mentor3
>>  Comments:
>> 
>> And rename Shepherd/Mentor notes: to just "Shepherd notes:"
>> 
>> Thoughts?
>> 
>> John
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Podling report format changes

[John D. Ament]

Jim,

Don't read too deeply into my use of "Podling Maturity Assessment."  The
sections of the current summary are simply "Ready to Graduate", "Some
Community Growth", "No Release" and "Still Getting Started."  I'm simply
asking the podling to decide which of those 4 best describe themselves.

John

On Tue, Jan 24, 2017 at 8:40 PM Jim Apple  wrote:

> There were a number of people who opposed the use of the maturity
> model on this list in 2016. For instance, Greg Stein said: "There has
> been past controversy on including that as a graduation step. I'm not
> clear that was a proper addition." and "The Board has never required
> the IPMC to use the APMM as a requirement for graduation."
>
> I find it to be pretty strange. Two examples:
>
> 1. "Convenience binaries can be distributed alongside source code but
> they are not Apache Releases -- they are just a convenience provided
> with no guarantee."
>
> I don't imagine this REQUIRES binaries, since
> http://www.apache.org/legal/release-policy says:
>
> "The Apache Software Foundation produces open source software. All
> releases are in the form of the source materials needed to make
> changes to the software being released."
>
> So, if this isn't requiring binary releases, it seems to simply be
> limiting them. That's fair enough, but how is that level level 4 of
> "Releases" while "Releases are signed and/or distributed along with
> digests", which requires actual work, is only level 3. Level 4 can be
> achieved whilst napping by not guaranteeing anything while
> sleepwalking.
>
> 2.  A number of the items don't seem to be mentioned in any other
> incubating guide or don't seem to me to be true of TLPs in general.
> Adding them here makes it look like there is new incubator policy that
> snuck in the back door. Here are things I don't recall seeing
> elsewhere:
>
> "The code can be built in a reproducible way using widely available
> standard tools." -- widely available?
>
> "The project is open and honest about the quality of its code." --
> Does anywhere else in the incubation documentation describe any sort
> of quality disclosure procedure? What does this even mean -- what is
> the scale?
>
> "The project puts a high priority on backwards compatibility" -- Is
> this mentioned anywhere else on the incubation webpages?
>
> "The way in which contributors can be granted more rights such as
> commit access or decision power is clearly documented" -- is this even
> true for most TLPs? I spent some time looking at how big data TLPs
> describe commit bit approvals, and most seem to be extremely vague in
> describing what constitutes enough of a contribution to be granted the
> bit.
>
> "The project is independent from any corporate or organizational
> influence." -- Didn't Stratos just get moved to the attic because its
> main corporate backer stopped backing it? How many other TLPs are in
> this same boat?
>
> On Tue, Jan 24, 2017 at 5:15 PM, John D. Ament 
> wrote:
> > All,
> >
> > The Incubator PMC has received feedback from the board that changes may
> > need to be made to the structure of our report.  Specifically, there is
> > confusion from the board members over how podlings get classified.  There
> > is also a request to increase and improve mentor feedback on podling
> > reports.  Based on this input, I would like to propose the following
> > changes to our report format.  I would like to try to implement this for
> > the March report, if not before then.
> >
> > 1. Eliminate the podling summary section of the report.  It shouldn't be
> on
> > the report manager to classify each podling.  We have begun leveraging a
> > maturity model for podlings, while its not required to fulfill it serves
> as
> > an equivalent to this section.  The list of podlings who failed to report
> > shall remain.
> >
> > 2. Add a "Podling Maturity Assessment" to the individual podling reports.
> > This would give a clear opportunity for each podling to describe how they
> > are doing, perhaps compared to the maturity model or our classic
> categories.
> >
> > 3. Change the mentor sign off section to include a per-mentor comment.
> > E.g. instead of the current:
> >
> >   [ ](podling) mentor1
> >   [ ](podling) mentor2
> >   [ ](podling) mentor3
> >
> > It would be:
> >
> >   [ ](podling) mentor1
> >   Comments:
> >   [ ](podling) mentor2
> >   Comments:
> >   [ ](podling) mentor3
> >   Comments:
> >
> > And rename Shepherd/Mentor notes: to just "Shepherd notes:"
> >
> > Thoughts?
> >
> > John
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Podling report format changes

[Jim Apple]

There were a number of people who opposed the use of the maturity
model on this list in 2016. For instance, Greg Stein said: "There has
been past controversy on including that as a graduation step. I'm not
clear that was a proper addition." and "The Board has never required
the IPMC to use the APMM as a requirement for graduation."

I find it to be pretty strange. Two examples:

1. "Convenience binaries can be distributed alongside source code but
they are not Apache Releases -- they are just a convenience provided
with no guarantee."

I don't imagine this REQUIRES binaries, since
http://www.apache.org/legal/release-policy says:

"The Apache Software Foundation produces open source software. All
releases are in the form of the source materials needed to make
changes to the software being released."

So, if this isn't requiring binary releases, it seems to simply be
limiting them. That's fair enough, but how is that level level 4 of
"Releases" while "Releases are signed and/or distributed along with
digests", which requires actual work, is only level 3. Level 4 can be
achieved whilst napping by not guaranteeing anything while
sleepwalking.

2.  A number of the items don't seem to be mentioned in any other
incubating guide or don't seem to me to be true of TLPs in general.
Adding them here makes it look like there is new incubator policy that
snuck in the back door. Here are things I don't recall seeing
elsewhere:

"The code can be built in a reproducible way using widely available
standard tools." -- widely available?

"The project is open and honest about the quality of its code." --
Does anywhere else in the incubation documentation describe any sort
of quality disclosure procedure? What does this even mean -- what is
the scale?

"The project puts a high priority on backwards compatibility" -- Is
this mentioned anywhere else on the incubation webpages?

"The way in which contributors can be granted more rights such as
commit access or decision power is clearly documented" -- is this even
true for most TLPs? I spent some time looking at how big data TLPs
describe commit bit approvals, and most seem to be extremely vague in
describing what constitutes enough of a contribution to be granted the
bit.

"The project is independent from any corporate or organizational
influence." -- Didn't Stratos just get moved to the attic because its
main corporate backer stopped backing it? How many other TLPs are in
this same boat?

On Tue, Jan 24, 2017 at 5:15 PM, John D. Ament  wrote:
> All,
>
> The Incubator PMC has received feedback from the board that changes may
> need to be made to the structure of our report.  Specifically, there is
> confusion from the board members over how podlings get classified.  There
> is also a request to increase and improve mentor feedback on podling
> reports.  Based on this input, I would like to propose the following
> changes to our report format.  I would like to try to implement this for
> the March report, if not before then.
>
> 1. Eliminate the podling summary section of the report.  It shouldn't be on
> the report manager to classify each podling.  We have begun leveraging a
> maturity model for podlings, while its not required to fulfill it serves as
> an equivalent to this section.  The list of podlings who failed to report
> shall remain.
>
> 2. Add a "Podling Maturity Assessment" to the individual podling reports.
> This would give a clear opportunity for each podling to describe how they
> are doing, perhaps compared to the maturity model or our classic categories.
>
> 3. Change the mentor sign off section to include a per-mentor comment.
> E.g. instead of the current:
>
>   [ ](podling) mentor1
>   [ ](podling) mentor2
>   [ ](podling) mentor3
>
> It would be:
>
>   [ ](podling) mentor1
>   Comments:
>   [ ](podling) mentor2
>   Comments:
>   [ ](podling) mentor3
>   Comments:
>
> And rename Shepherd/Mentor notes: to just "Shepherd notes:"
>
> Thoughts?
>
> John

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[DISCUSS] Podling report format changes

[John D. Ament]

All,

The Incubator PMC has received feedback from the board that changes may
need to be made to the structure of our report.  Specifically, there is
confusion from the board members over how podlings get classified.  There
is also a request to increase and improve mentor feedback on podling
reports.  Based on this input, I would like to propose the following
changes to our report format.  I would like to try to implement this for
the March report, if not before then.

1. Eliminate the podling summary section of the report.  It shouldn't be on
the report manager to classify each podling.  We have begun leveraging a
maturity model for podlings, while its not required to fulfill it serves as
an equivalent to this section.  The list of podlings who failed to report
shall remain.

2. Add a "Podling Maturity Assessment" to the individual podling reports.
This would give a clear opportunity for each podling to describe how they
are doing, perhaps compared to the maturity model or our classic categories.

3. Change the mentor sign off section to include a per-mentor comment.
E.g. instead of the current:

  [ ](podling) mentor1
  [ ](podling) mentor2
  [ ](podling) mentor3

It would be:

  [ ](podling) mentor1
  Comments:
  [ ](podling) mentor2
  Comments:
  [ ](podling) mentor3
  Comments:

And rename Shepherd/Mentor notes: to just "Shepherd notes:"

Thoughts?

John

Re: [VOTE] Release of Apache Mnemonic-0.4.0-incubating [rc1]

[Justin Mclean]

Hi,

Vote results been called, but I did check. All good but don’t forget to update 
the year in your NOTICE file.

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[John D. Ament]

I think my argument is need vs require.  Basically with this policy, we
would be telling people there are certain tools you may not use.

John

On Tue, Jan 24, 2017 at 5:04 PM Ted Dunning  wrote:

> The single case that I can see for mystery jars in binary form is when a
> test case needs to cover malformed binaries or binaries produced on
> obsolete platforms (does anybody have a Java 1.3 compiler handy).
>
>
> (don't answer that, I wouldn't be surprised if a fair number of people
> still require 1.3 compatibility)
>
>
>
>
> On Tue, Jan 24, 2017 at 1:36 AM, Tom Barber  wrote:
>
> > Yeah, Paul makes a very good point. When you're new to a platform and
> > trying to debug tests, trying to find out whats hidden inside mysterious
> > test jars etc is often tedious at best. Build at test time is ideal.
> >
> > Tom
> >
> > On Tue, Jan 24, 2017 at 9:16 AM, Bertrand Delacretaz <
> > bdelacre...@codeconsult.ch> wrote:
> >
> > > On Tue, Jan 24, 2017 at 6:48 AM, Paul King  wrote:
> > > > ...I actually think what we ended up with does make it clearer
> > > > exactly what is going on
> > >
> > > Definitely - what Groovy did avoids having Mysterious Binaries in
> > > their releases, which we don't want.
> > >
> > > -Bertrand
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Tom Barber
> > CTO Spicule LTD
> > t...@spicule.co.uk
> >
> > http://spicule.co.uk
> >
> > @spiculeim 
> >
> > Schedule a meeting with me 
> >
> > GB: +44(0)5603641316 <+44%2056%200364%201316>
> > US: +18448141689 <(844)%20814-1689>
> >
> > 
> >
>

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[Ted Dunning]

The single case that I can see for mystery jars in binary form is when a
test case needs to cover malformed binaries or binaries produced on
obsolete platforms (does anybody have a Java 1.3 compiler handy).


(don't answer that, I wouldn't be surprised if a fair number of people
still require 1.3 compatibility)




On Tue, Jan 24, 2017 at 1:36 AM, Tom Barber  wrote:

> Yeah, Paul makes a very good point. When you're new to a platform and
> trying to debug tests, trying to find out whats hidden inside mysterious
> test jars etc is often tedious at best. Build at test time is ideal.
>
> Tom
>
> On Tue, Jan 24, 2017 at 9:16 AM, Bertrand Delacretaz <
> bdelacre...@codeconsult.ch> wrote:
>
> > On Tue, Jan 24, 2017 at 6:48 AM, Paul King  wrote:
> > > ...I actually think what we ended up with does make it clearer
> > > exactly what is going on
> >
> > Definitely - what Groovy did avoids having Mysterious Binaries in
> > their releases, which we don't want.
> >
> > -Bertrand
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
>
> --
> Tom Barber
> CTO Spicule LTD
> t...@spicule.co.uk
>
> http://spicule.co.uk
>
> @spiculeim 
>
> Schedule a meeting with me 
>
> GB: +44(0)5603641316
> US: +18448141689
>
> 
>

[RESULT][VOTE] Release of Apache Mnemonic-0.4.0-incubating [rc1]

[Gary]

*Hi all,*

After being opened for over more than 72 hours, the vote for releasing Apache
Mnemonic 0.4.0-incubating passed with 3 binding +1s, 1 non-binding +1s and no 0 
or -1.

**Binding votes +1s:**
Patrick Hunt (phunt)
Henry Saputra (hsaputra)
Gangumalla, Uma (umamahesh)

**non-binding votes +1s:**
Gary (garyw)

*Project Members Role Info*
http://mnemonic.incubator.apache.org/develop/

**Thanks all**
Cheers
Gary


On 1/16/2017 11:20 AM, Gary wrote:
> Hello incubator PMCs,
>
> The Apache Mnemonic community PPMCs and developers have voted and approved 
> the proposal to release Apache Mnemonic 0.4.0 (incubating).
>
> Apache Mnemonic is an advanced hybrid memory storage oriented library, it's 
> proposed a non-volatile/durable Java object model and durable computing model 
> that bring several advantages to significantly improve the performance of 
> massive real-time data processing/analytic. developers are able to use this 
> library to design their cache-less and SerDe-less high performance 
> applications.
>
> [VOTE] thread:
> http://mail-archives.apache.org/mod_mbox/incubator-mnemonic-dev/201612.mbox/%3C2cadfa42-9e64-e9cf-1a3e-bee220a89503%40apache.org%3E
> http://mail-archives.apache.org/mod_mbox/incubator-mnemonic-dev/201701.mbox/%3CCANLc_9KHFu4hawNSosjJADYQ8jtZTv5pThd5qBGBmbjAQOLBZw%40mail.gmail.com%3E
> http://mail-archives.apache.org/mod_mbox/incubator-mnemonic-dev/201701.mbox/%3CCALuGr6a5MM3Tsikt71W1%2BhGdbY9JpCB7z9Y8aaZb9NT0HkzDFg%40mail.gmail.com%3E
> http://mail-archives.apache.org/mod_mbox/incubator-mnemonic-dev/201701.mbox/%3CD49D5EAD.2C76A%25uma.gangumalla%40intel.com%3E
>
> [VOTE RESULT] thread:
> http://mail-archives.apache.org/mod_mbox/incubator-mnemonic-dev/201701.mbox/%3C2c07ce2b-84b1-4751-d99a-5fe0de7ae24f%40apache.org%3E
>
> We now kindly request the Incubator PMC members review and vote on this 
> incubator release.
>
> The Apache Mnemonic-0.4.0-incubating release candidate is now available with 
> the following artifacts for a project vote:
>
> The source tarball, including signatures, digests, etc. can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/mnemonic/0.4.0-incubating-rc1/src/
>
> The tag to be voted upon is v0.4.0-incubating:
> https://git-wip-us.apache.org/repos/asf?p=incubator-mnemonic.git;a=shortlog;h=refs/tags/v0.4.0-incubating
>
> The release hash is 178035c68f1df26e4f3fcf9314bb6248c2ad3ac0:
> https://git-wip-us.apache.org/repos/asf?p=incubator-mnemonic.git;a=commit;h=7799e7094545db9640269d14543bf28d7a7e0335
>
> Release artifacts are signed with the following key:
> https://dist.apache.org/repos/dist/dev/incubator/mnemonic/KEYS
>
> KEYS file available:
> https://dist.apache.org/repos/dist/dev/incubator/mnemonic/KEYS
>
> For information about the contents of this release, see:
> https://dist.apache.org/repos/dist/dev/incubator/mnemonic/0.4.0-incubating-rc1/CHANGES.txt
>
> The vote will be open for ~72 hours.
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build from source, and test.  The
> please vote:
>
> [ ] +1 Release this package as apache-mnemonic-0.4.0-incubating
> [ ] +0 no opinion
> [ ] -1 Do not release this package because because...
>
>
> Thanks,
> Gary on behalf of the Apache Mnemonic (incubating) team
>
>



signature.asc
Description: OpenPGP digital signature

[RESULT] [VOTE] Release Gossip version gossip-0.1.1-incubating (RC2)

[Edward Capriolo]

The vote passes: The results of the VOTE was:

+1 : 5
0: 0
-1:0

+1 (binding)
Justin Mclean
Drew Farris
John D. Ament
P. Taylor Goetz
Josh Elser

Vote Thread:
http://apache-incubator-general.996316.n3.nabble.com/VOTE-Release-Gossip-version-gossip-0-1-1-incubating-RC2-td53327.html

Thank you everyone for your help.

Re: [VOTE] Apache CarbonData 1.0.0-incubating release (RC2)

[Jean-Baptiste Onofré]

+1 (binding)

Casting my vote here.

Regards
JB⁣​

On Jan 24, 2017, 13:59, at 13:59, Jacky Li <13561...@qq.com> wrote:
>Hi Incubator PMC, 
>
>Please vote on releasing the following candidate as Apache
>CarbonData(incubating) version 1.0.0. 
>
>PPMC has passed the vote,  here's the PPMC vote thread for 1.0.0
>release: 
>http://apache-carbondata-mailing-list-archive.1130556.n5.nabble.com/VOTE-Apache-CarbonData-1-0-0-incubating-release-RC2-td7016.html
>
>The source distribution, with signatures is there: 
>https://dist.apache.org/repos/dist/dev/incubator/carbondata/1.0.0-incubating-rc2/
>
>Build guide(need install Apache Thrift 0.9.3, use command: mvn clean
>-DskipTests -Pbuild-with-format -Pspark-1.6 install), please find the
>detail:
>https://github.com/apache/incubator-carbondata/tree/master/build
>
>The Git Tag is :  
>https://git-wip-us.apache.org/repos/asf?p=incubator-carbondata.git;a=commit;h=39efa332be094772daed05976b29241593da309f
> 
>
>
>The artifacts have been signed with this key: 
>https://dist.apache.org/repos/dist/dev/incubator/carbondata/KEYS
>
>Please vote to approve this release: 
>
>[ ] +1 Approve the release 
>[ ] -1 Don't approve the release (please provide specific comments) 
>
>This vote will be open for at least 72 hours.
>
>Regards,
>Jacky Li
>
>
>
>
>--
>View this message in context:
>http://apache-incubator-general.996316.n3.nabble.com/VOTE-Apache-CarbonData-1-0-0-incubating-release-RC2-tp53517.html
>Sent from the Apache Incubator - General mailing list archive at
>Nabble.com.
>
>-
>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Apache CarbonData 1.0.0-incubating release (RC2)

[Jacky Li]

Hi Incubator PMC, 

Please vote on releasing the following candidate as Apache
CarbonData(incubating) version 1.0.0. 

PPMC has passed the vote,  here's the PPMC vote thread for 1.0.0 release: 
http://apache-carbondata-mailing-list-archive.1130556.n5.nabble.com/VOTE-Apache-CarbonData-1-0-0-incubating-release-RC2-td7016.html

The source distribution, with signatures is there: 
https://dist.apache.org/repos/dist/dev/incubator/carbondata/1.0.0-incubating-rc2/

Build guide(need install Apache Thrift 0.9.3, use command: mvn clean
-DskipTests -Pbuild-with-format -Pspark-1.6 install), please find the
detail:
https://github.com/apache/incubator-carbondata/tree/master/build

The Git Tag is :  
https://git-wip-us.apache.org/repos/asf?p=incubator-carbondata.git;a=commit;h=39efa332be094772daed05976b29241593da309f
  

The artifacts have been signed with this key: 
https://dist.apache.org/repos/dist/dev/incubator/carbondata/KEYS

Please vote to approve this release: 

[ ] +1 Approve the release 
[ ] -1 Don't approve the release (please provide specific comments) 

This vote will be open for at least 72 hours.

Regards,
Jacky Li




--
View this message in context: 
http://apache-incubator-general.996316.n3.nabble.com/VOTE-Apache-CarbonData-1-0-0-incubating-release-RC2-tp53517.html
Sent from the Apache Incubator - General mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [RESULT] MXNet to enter the Incubator

[John D. Ament]

Great news.  I see your commit for the mailing lists.  Before infra can
process them, you'll need to create a JIRA for the DNS entries (or they may
end up just creating the DNS when they create the mailing lists... depends
on the infra admin).  Here's an example JIRA from Ratis recently to do
this: https://issues.apache.org/jira/browse/INFRA-13187

John

On Tue, Jan 24, 2017 at 2:03 AM Henri Yandell  wrote:

> Thanks John.
>
> For those following along -
> http://incubator.apache.org/projects/mxnet.html
> created. Mailing lists requested.
>
> On Mon, Jan 23, 2017 at 3:34 PM, John D. Ament 
> wrote:
>
> > Nope, its not an issue.  As a reminder, don't forget to create a
> > content/projects/mxnet.xml for the project (infra requires both to get
> > started).
> >
> > John
> >
> > On Mon, Jan 23, 2017 at 1:16 PM Henri Yandell  wrote:
> >
> > > Heh - I was assuming Champion automatically became Mentor.  Any issue
> if
> > I
> > > do that, or have I just created red-tape hell?
> > >
> > > I think pulling the content out would be better - that way you have
> > startup
> > > Mentor cost and recurring Mentor cost described separately.
> > >
> > > Hen
> > >
> > > On Mon, Jan 23, 2017 at 10:11 AM, John D. Ament  >
> > > wrote:
> > >
> > > > Henri,
> > > >
> > > > That's because technically speaking you're off the hook.  You're only
> > the
> > > > champion of the podling, its up to the mentors now to get them
> > > > bootstrapped.  Since you weren't on the mentor list, you have nothing
> > > more
> > > > to worry about for MXNet.
> > > >
> > > > I've contemplated (and still do) pulling out podling bootstrap from
> the
> > > > mentor guide.  Right now it makes sense since mentors are responsible
> > for
> > > > coordinating w/ INFRA and doing self-serve stuff.
> > > >
> > > > John
> > > >
> > > > On Mon, Jan 23, 2017 at 1:06 PM Henri Yandell 
> > wrote:
> > > >
> > > > > Yeah; it was a bit tricky to find the page but I got there after
> > > working
> > > > > backwards from RocketMQ's JIRA issues :)
> > > > >
> > > > > Mental note that a "Vote successful; what next?" Guide might be a
> > good
> > > > > idea. It didn't occur to me to go look at the Mentor doc.
> > > > >
> > > > > Hen
> > > > >
> > > > > On Mon, Jan 23, 2017 at 9:43 AM, John D. Ament <
> > johndam...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Henri,
> > > > > >
> > > > > > Compare the list of steps you're planning to take vs
> > > > > > http://www.apache.org/dev/infra-contact#requesting-podling
> > > > > >
> > > > > > John
> > > > > >
> > > > > > On Mon, Jan 23, 2017 at 12:20 PM Henri Yandell <
> bay...@apache.org>
> > > > > wrote:
> > > > > >
> > > > > > > Vote is closed and successful.
> > > > > > >
> > > > > > > 7 binding +1 votes.
> > > > > > >
> > > > > > > Henry Saputra   (hsaputra)
> > > > > > > Sebastian Schelter  (ssc)
> > > > > > > Markus Weimer   (weimer)
> > > > > > > Stian Soiland-Reyes(stain)
> > > > > > > Suneel Marthi (smarthi)
> > > > > > > Jean-Baptiste Onofré  (jbonofre)
> > > > > > > Henri Yandell  (bayard)
> > > > > > >
> > > > > > > 7 community +1 votes.
> > > > > > >
> > > > > > > Charith Elvitigala(charithcc)
> > > > > > > Lieven Govaerts   (lgo)
> > > > > > > Byung-Gon Chun   (bgchun)
> > > > > > > Xingjian SHI
> > > > > > > Liang Chen
> > > > > > > 梁德澎
> > > > > > > YiZhi Liu
> > > > > > >
> > > > > > > I'll go ahead and start things off tonight. My intention is:
> > > > > > >
> > > > > > > 1) Ask Infra for the mailing lists. Once setup, I'll mail all
> > > listed
> > > > > > > committers with a heads up.
> > > > > > > 2) Set up a project page (
> > > > > > > 3) Open a Name Search JIRA item.
> > > > > > > 4) Ask gstein@ (or the suitable forum) for approval to use
> > GitHub
> > > > for
> > > > > > > issues.
> > > > > > > 5) Email Infra to ask for their advice/assistance on
> transferring
> > > > code
> > > > > > (new
> > > > > > > repo vs transferring existing repo etc).
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Hen
> > > > > > >
> > > > > > > On Mon, Jan 16, 2017 at 8:20 PM, Henri Yandell <
> > bay...@apache.org>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Hi Incubator folk,
> > > > > > > >
> > > > > > > >I would like to call a vote for accepting "MXNet" for
> > > incubation
> > > > > in
> > > > > > > > the Apache Incubator.
> > > > > > > >
> > > > > > > > The full proposal is available at this wiki link:
> > > > > > > >
> > > > > > > > https://wiki.apache.org/incubator/MXNetProposal?
> > > > > > action=recall=19
> > > > > > > >
> > > > > > > > I will reply to this email with a copy of the proposal.
> > > > > > > >
> > > > > > > > MXNet already has a broad community, which I think is clear
> > from
> > > > the
> > > > > > > > interest from many contributors in being a part of the
> project
> > at
> > > > > > Apache.
> > > > > > > > There are four mentors signed up, 

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[Tom Barber]

Yeah, Paul makes a very good point. When you're new to a platform and
trying to debug tests, trying to find out whats hidden inside mysterious
test jars etc is often tedious at best. Build at test time is ideal.

Tom

On Tue, Jan 24, 2017 at 9:16 AM, Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> On Tue, Jan 24, 2017 at 6:48 AM, Paul King  wrote:
> > ...I actually think what we ended up with does make it clearer
> > exactly what is going on
>
> Definitely - what Groovy did avoids having Mysterious Binaries in
> their releases, which we don't want.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim 

Schedule a meeting with me 

GB: +44(0)5603641316
US: +18448141689

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[Bertrand Delacretaz]

On Tue, Jan 24, 2017 at 6:48 AM, Paul King  wrote:
> ...I actually think what we ended up with does make it clearer
> exactly what is going on

Definitely - what Groovy did avoids having Mysterious Binaries in
their releases, which we don't want.

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org