DMB-PPU decoupling vote

Emmet Hikory persia at ubuntu.com
Tue Jul 2 03:19:17 UTC 2013


Scott Kitterman wrote:
> On Tuesday, July 02, 2013 10:55:02 AM Emmet Hikory wrote:
> >     As written, these are a little unclear.  Is the deciding consideration
> > whether a package in the packageset ships in an product, thereby affecting
> > some release commitment, or something else?
> 
> I think it's that plus some other possible cases which, in my view, we 
> shouldn't over specify.  A past example, for me, would have been the Sugar 
> packageset.  It's not just an administrative convenience to provide a 
> packageset, but a coherent set of functionality, even if it doesn't directly 
> impinge on a product commitment.

    The key part of my worry is the start of this: "I think".  My opinion
on the underlying idea behind this has been on record for the last 6 years,
but independently, I don't believe it to be safe to perform a vote when
the options are insufficiently clear, as the result of the vote fails to
ensure acceptance of a resulting implementation.  Note that I wouldn't
support building a definitive list of affected packagesets, because this
also doesn't provide clear guidance for the future.

    For the purpose of determining the proposal submitted by the DMB to the
TB, I would strongly recommend restructuring the options in terms of specific
declarative discriminants, e.g.:

   a) Packageset contains a package shipped in a product
   b) Packageset is specifically related to a product
   c) Packageset contains a package contained in a coherent concept (e.g. sugar)
   d) Packageset defines a coherent concept (e.g. sugar)
   (...)

    Note that there may be multiple discriminants, in which case it may be
better to poll on them separately.  For example:

    I) Package group inclusion rules
        a) Packageset defines package group
        b) Packageset contains package in package group
        c) Packageset contains package that is dependency of package in
            package group.

    II) Package group membership rules
        x) Membership is required for flavour package groups
        y) Membership is required for coherent concept package groups

where the recommendation by the DMB to the TB might be e.g. ay or cx.  The
example discriminant table is not intended to be comprehensive: those with
greater focus on the minutiae of the debate are much better qualified to
create an accurate list of points of nonconsensus for voting purposes.

    That notwithstanding, if the DMB is confident that there is a common
understanding of the underlying discriminants, a vote is safe, although the
documentation produced by this (and the wording of the recommendation to
the TB) probably ought be restructured to be as clearly understood by
the TB and arbitrary potential contributors reviewing the documentation.
While a fuzzy definition allows wider scope for personal opinion by the
administrators, in the case of this long-standing debate, it is probably
wise to formalise it fairly strictly (as prior to this model, DMB members
could just vote membership in those cases where someone was technically good
and reliable and didn't have the history or defer approval in cases where
someone wasn't considered trusted to upload due to lack of release cycle
concern, whereas with this model, such opinions need specific support).

-- 
Emmet HIKORY




More information about the Devel-permissions mailing list