DMB-PPU decoupling vote

[Scott Kitterman]

On Tuesday, July 02, 2013 12:19:17 PM Emmet Hikory wrote:
> 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).

I think that the DMB exists to exercise judgment.  So when it comes to the 
question of "is membership a requirement to upload to this packageset?", I 
think a few general guidelines is sufficient and actually preferable.  I don't 
believe that the rules should be so defined as to prevent the current or future 
DMB members from taking the decisions they believe are appropriate.

i think we understand what we're arguing about in having the vote.  I do think 
it would be a good idea to make it a bit clearer, e.g. with examples, before 
sending it to the TB.

Scott K