Skip to content

Latest commit

 

History

History
88 lines (55 loc) · 2.75 KB

core_inclusion.pod

File metadata and controls

88 lines (55 loc) · 2.75 KB
Raw

NAME

docs/project/core_inclusion.pod - Core Inclusion

Questions we'll consider when deciding if a piece of code should be moved into core.

Abstract

Occasionally useful bits of code will arise that someone thinks should be made core components of Parrot. This document lists some of the questions we'll consider when deciding whether this is a good idea.

Introduction

When considering whether to add code to Parrot, we'll ask ourselves and the developer(s) the following questions, in approximate order of importance. This is not an exhaustive list as much as a guide to help us make sure we think through the implications of adopting and supporting a new core component.

  • What benefit will the code provide to Parrot and its users?

    How will it help Parrot and its users to further their goals? Examples include better debugging, increased execution speed, better code generation and improved modularity.

  • How does its benefit outweigh its maintenance (testing, updating, support, deprecation, etc.) burden?

    This is somewhat subjective, but the main question concerns how high the maintenance burden will be relative to the benefits the code will provide.

  • Is the code something that most of Parrot's users will be happy to find?

    More specifically, will the addition make development more fun for the majority of Parrot's users. A generic optimization framework would help most projects and have a good chance of inclusion. A specialized math library or an HLL-specific datatype won't be of use to most projects and should live as a separate project.

  • How well-documented and tested is it?

    If we can't figure out how it works or if it does what it claims, it'll have a hard getting accepted. We have enough undertested and underdocumented code already.

  • Which committers have expressed willingness to maintain it? How familiar are they with it?

    Core code needs to be maintained. If an experienced core committer expresses willingness to maintain an addition, that's good. If that committer has worked with the code, that's better.

  • Does the code have any portability issues?

    We want Parrot to run on as many platforms as possible. If the code has any OS- or CPU-specific components, are they well-separated and easy to port to other systems?

  • What impact does it have on Parrot's install footprint?

  • How will having the code in core help Parrot more than having it in an external project would?

  • How will the addition impact Parrot's runtime characteristics, e.g. its memory usage, speed, startup time, etc?

  • What drawbacks will result from including the addition in core?