[OpenDaylight TSC] proposed clarifications to the graduation review

Colin Dixon colin at colindixon.com
Thu Sep 3 15:28:26 UTC 2015


I realized that the previous e-mail relied on HTML formatting and so didn't
render well in the mailing list archives. I've created this version which
should work well as plaintext. I've used <added> and <removed> tags to
indicate what's new and taken out instead of colors. Given that we're
closer to having mature projects and stable features I'd like to get
opinions on these proposed clarifications.

It sounds like there might be some opinions/ideas/revisions around GPG keys
[0].

--Colin

2.3.2 Graduation Review
   1. Graduation Proposal Posted for 2 weeks:
      1. Working code base
<added>
         1. The code should build and an average user/developer should
            be able to accomplish its primary function based on
            easily-found documentation.
         2. Security conscious
            1. Has responded to known security vulnerabilities
               promptly, i.e., in two business days or less.
            2. Has no unfixed, known vulnerabilities older than a week
               that are considered “important” [1] by the security
               response team or marked with a “high” CVSS [2] in their
               CVE.
            3. All externally-facing APIs are secured using
               community-accepted authentication/authorization
               mechanisms.
</added>
      2. Active Community
<added>
         1. Strong evidence of recent activity in the form of code
            commits, reviews, etc.
         2. All committers must have a GPG key.
         3. All comitter GPG keys must be attached to the OpenDaylight
            web of trust.
         4. The committers must provide enough diversity, e.g., time
            zone and/or geographic, to counter systemic risks.
      3. History of Releases (using Mature Release Process):
<added>
         1. Participated in the two previous OpenDaylight releases
         2. Average delivery of milestone status reports within 5
            business days of the deadline in the immediately previous
            release.
         3. Successful delivery of all cross-project milestone
            deliverables, i.e., those specified in the simultaneous
            release plan and those which the project agreed to provide
            to dependent projects as part of their release plan, within
            10 business days of the deadline in immediately previous
            release.
</added>
      4. Destination Top Level Project Specified
<added>
         (if joining a Top Level Project)
</added>
      5. Acceptance of conditions of proposed <removed>TLP</removed>
<added>
         Top Level Project (if joining a Top Level Project)
</added>
   2. Committers vote on seeking graduation
   3. Accepted by vote of destination
<added>
      Top Level Project (if joining a Top Level Project)
</added>
   4. Review by TSC and Approval

While we're at it, I'd also like to change the terminology around
termination review to an archival review in two places:
* Last row of table in 2.2.
* In clauses 2.3.5, 2.3.5.1, and 2.3.5.1.1

[0] https://lists.opendaylight.org/pipermail/tsc/2015-September/003756.html
[1]
https://wiki.opendaylight.org/view/TSC:Vulnerability_Management#Risk_Assessment
[2] https://nvd.nist.gov/cvss.cfm

On Wed, Jul 22, 2015 at 2:43 PM, Colin Dixon <colin at colindixon.com> wrote:

> Since I'm hoping that we're about to see the first set of projects in
> OpenDaylight move to mature, it likely makes sense to provide some clarity
> to what  is involved in the graduation review. Along those lines, you can
> find below a proposed set of deeper interpretation of the existing
> requirements. The existing document can be found here:
> http://www.opendaylight.org/project-lifecycle-releases
>
> Text in green was added. Text in red and crossed out was removed.
>
> 2.3.2 Graduation Review
>>
>> 1. Graduation Proposal Posted for 2 weeks:
>>
>> 1. Working code base
>>
>> 1. The code should build and an average user/developer should be able to
>> accomplish its primary function based on easily-found documentation.
>>
>> 2. Security conscious
>>
>> 1. Has responded to known security vulnerabilities promptly, i.e., in two
>> business days or less.
>>
>> 2. Has no unfixed, known vulnerabilities older than a week that are
>> considered “important
>> <https://wiki.opendaylight.org/view/TSC:Vulnerability_Management#Risk_Assessment>”
>> by the security response team or marked with a “high” CVSS
>> <https://nvd.nist.gov/cvss.cfm> in their CVE.
>>
>> 3. All externally-facing APIs are secured using community-accepted
>> authentication/authorization mechanisms.
>>
>> 2. Active Community
>>
>> 1. Strong evidence of recent activity in the form of code commits,
>> reviews, etc.
>>
>> 2. All committers must have a GPG key.
>>
>> 3. All comitter GPG keys must be attached to the OpenDaylight web of
>> trust.
>>
>> 4. The committers must provide enough diversity, e.g., time zone and/or
>> geographic, to counter systemic risks.
>>
>> 3. History of Releases (using Mature Release Process):
>>
>> 1. Participated in the two previous OpenDaylight releases
>>
>> 2. Average delivery of milestone status reports within 5 business days of
>> the deadline in the immediately previous release.
>>
>> 3. Successful delivery of all cross-project milestone deliverables, i.e.,
>> those specified in the simultaneous release plan and those which the
>> project agreed to provide to dependent projects as part of their release
>> plan, within 10 business days of the deadline in immediately previous
>> release.
>>
>> 4. Destination Top Level Project Specified (if joining a Top Level
>> Project)
>>
>> 5. Acceptance of conditions of proposed TLP Top Level Project (if
>> joining a Top Level Project)
>>
>> 2. Committers vote on seeking graduation
>>
>> 3. Accepted by vote of destination Top Level Project (if joining a Top
>> Level Project)
>> 4. Review by TSC and Approval
>>
>
> While we're at it, I'd also like to change the terminology around
> termination review to an archival review in two places:
> * Last row of table in 2.2.
> * In clauses 2.3.5, 2.3.5.1, and 2.3.5.1.1
>
> It's simply less aggressive and seems more in line with the reality.
>
> If people have thoughts, please give feedback. Eventually it would be good
> if the TSC could vote on this language and send it to the board to ratify
> it so that we can change the formal document.
>
> Cheers,
> --Colin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/tsc/attachments/20150903/1103c507/attachment-0001.html>


More information about the TSC mailing list