Recommendation for the procedure to add platform packages

Duncan Coutts duncan.coutts at
Mon Sep 14 14:56:43 EDT 2009

On Tue, 2009-09-08 at 13:02 +0100, Simon Marlow wrote:

> > The main document contains:
> >        * the procedure itself, which is relatively short
> >        * a rationale, cross-linked to the procedure
> >        * a procedure to help us make decisions
> >
> >
> On the whole, +1.
> The process is quite detailed, so we shouldn't expect reviewers to be 
> familiar with all the rules; instead it's up to the steering committee 
> to guide the discussion and remind people of the administrative details 
> at each stage (e.g. "you have until X to respond, or we assume you 
> agree", or "this is the first phase, during which we are trying to reach 
> consensus on Z").

Right. I think that's fine. We'll all get the hang of it after the first
round or so.

> Specific comments:
> "come to view on whether the package should be accepted"
> -> "help achieve a consensus ... "


> "the libraries mailing list reach consensus to accept it"
> -> "the reviewers reach a consensus to accept it" ?


> "Compile on all operating systems and compilers that the platform targets"
> -> ".. except where the package is compiler- or platform-specific" ?

Right, we want language that lets us have platform-specific stuff where
it's really essential but strongly encourage portable as the default.
For example we've got the win32 and unix packages because they're there
to expose the native platform apis. But for example if we added file
change notification I expect we'd want to provide a platform independent
api rather than three packages, one for each native api (or at least
we'd want to provide something portable in addition to low level native

> The "Interim Licesne Policy" should be one of the bullet points
> under Package Requirements.  e.g.
>    "The package must be distributed under an acceptable license.  The
>     only license currently acceptable is BSD3 [rationale..]"

Yes and no :-). I'll say that it must comply with the license policy.
I've been trying very hard to avoid writing the sentence "the only
license acceptable is BSD3" because it's highly misleading to say that.

> I'd like to see something about API style mentioned in the "Package 
> Requirements".  e.g.:
>    Packages admitted to the platform should follow an API style
>    similar to those packages already in the package.  While the
>    style guidelines for package APIs have not yet been written down,
>    we expect that to change in the future.

That's for the discussion after we agree on the procedure. There are
plenty more package requirements that we'll want to discuss. We've
deliberately started with a minimal set because we wanted to separate
the two discussions.

Ok, so I'll check the above with someone else on the steering committee
and update the document.


More information about the Libraries mailing list