DMB-PPU decoupling vote
ubuntu at kitterman.com
Tue Jul 2 03:36:27 UTC 2013
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.
More information about the Devel-permissions