incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Apple <jbap...@cloudera.com>
Subject Re: [DISCUSS] Podling report format changes
Date Wed, 25 Jan 2017 05:02:41 GMT
Ah, sorry for the paragraphs, then.

On Tue, Jan 24, 2017 at 5:52 PM, John D. Ament <johndament@apache.org> 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 <jbapple@cloudera.com> 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 <john.d.ament@gmail.com>
>> 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-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


Mime
View raw message