Recommendation for the procedure to add platform packages

[Ian Lynagh]

On Sun, Aug 23, 2009 at 07:49:23PM +0100, Duncan Coutts wrote:
> 
> The intro says:
> 
>       * The rationale section gives an explanation and justification for
>         the policy.
> 
> Is there a wording that would make it clearer that you do not have to
> read it unless you want an explanation for a point in the policy?

I didn't read that line. I'll expand on this (and the other questions
about process description length) in a reply to your other e-mail.

> > Drifting off-topic, but I think that the two discussions are orthogonal
> > (i.e. we could have them in either order), but the "detailed
> > requirements" discussion is the more important one. People can make
> > proposals without a process being nailed down (and that may even help us
> > work out what the process should be), but how can we decide if a package
> > should be included if we don't know what the acceptance criteria are?
> 
> The acceptance criteria is clearly specified.

Well, it says (somewhat tautologically):

    A package is considered as accepted if, by the discussion deadline,
    the libraries mailing list reach consensus to accept it.

but I don't see how we can reach consensus about a package that (for
example) is not -Wall clean if we haven't decided whether or not all
packages in the platform must be -Wall clean.

> It is not that a set of
> minimal requirements be met. It is that the reviewers, using their
> judgement come to a consensus to accept the package.

I agree that some of the requirements will be fuzzy (such as "good
API"), and we may even overlook black-and-white requirements in
particular cases if there is a good reason.

> > > Would those things increase work for the proposal
> > > authors / package maintainers?
> > 
> > It should reduce work for the authors / package maintainers.
> 
> Even taking into account that you would expect them to write these
> external documents? Where is the reduction coming from?

Like you said at the start of your mail, "the 'tar' example could be
improved and shortened", so to some extent at least we are in agreement,
and the issue was just that the example was written for an earlier, more
rigid process.

I suspect that I would say that it could be shortened even more than you
are thinking, with more of your paragraphs being condensed into a line
in the checklist (in the common case where the package obviously
satisfies the criteria).

> Less text in the proposal or less text in total?

A mixture of both.


Thanks
Ian