Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package

[Ian Jackson <ian@davenant.greenend.org.uk>]

Ian Jackson writes ("Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package"):
> I therefore hereby propose the following two alternative versions of a
> resolution for this issue:

See below for the full text, and my last message for my views.
(Wichert said he wanted until at least the 5th and hasn't said
anything more, so ...)


I hereby call for a vote on this resolution.  We'll vote on the whole
lot on one ballot - effectively, conducting two votes one after the
other.  The overall options are:

    A    Version A (allow maintainer discretion to bundle)
    B    Version B (overrule maintainer, split packages)
    FD   Further Discussion

It'll be easiest if you just rank these in descending order of
preference.


If you're not familiar with the voting arrangements you may want to
reread the constitution section A.  We'll interpret the results as
follows:

* First - constitution A.3(1) - we select either A or B as the `most
preferred form' (henceforth P), or choose FD.  If we choose FD, then
we go back to further discussion.  Otherwise A or B goes onto the next
round:

* Second - constitution A.3(2) - we decide whether the most preferred
form P beats FD by enough to pass.  When considering this, we
disregard any preferences for the losing form; a vote is counted as
for `Yes' if it ranks P above FD, `No' if FD above P, or abstain
otherwise.

* Results - constitution 6.3, A.6:

There is a quorum of 2.  Additionally, overruling a developer requires
a 3:1 supermajority.  So:

If P is A and beats FD by at least 2 votes, then A is carried.

If P is B and beats FD by at least 2 votes, and also at least 3 times
as many ballots prefer B to FD as prefer FD to B, then B is carried
and is binding: the maintainer is directed to split the package.

If P is B and beats FD by at least 2 votes, but not the required
supermajority, then B is carried and is a recommendation only: the
maintainer is recommended to split the package.


I hereby vote as follows:

 1    A    Version A (allow maintainer discretion to bundle)
 2    FD   Further Discussion
 3    B    Version B (overrule maintainer, split packages)

Ian.

>  Version A (my favourite):
> 
>   1. It is generally bad for programs to fail due to run-time
>      linkage failures, in most cases.  There may however be other
>      tradeoffs involved that make this a reasonable choice.
> 
>   2. In this particular case, splitting the package introduces a level
>      of administration and other overhead which outweighs the minor
>      ugliness of the run-time linker error message.
> 
>   3. We therefore agree with the package maintainer that pcmcia-cs
>      should remain one package, with cardinfo included.
> 
>   4. The bug report should be closed with no action.
> 
>  Version B (Anthony and Manoj, I think):
> 
>   1. It is generally bad for programs to fail due to run-time
>      linkage failures, in most (if not all) cases.
> 
>   2. In this particular case there are no countervailing tradeoffs
>      that legitimise the behaviour.  In particular, the alternative
>      solution of splitting the package has no significant problems
>      that are relevant.
> 
>   3. We therefore agree with the submitter that pcmcia-cs should be
>      split, with cardinfo being put into a separate binary.  We
>      recommend or direct that the maintainer do so.
> 
>   4. The bug report should be reassigned to the pcmcia-cs package.

-- 
Ian Jackson, at home.           Local/personal: ijackson@chiark.greenend.org.uk
ian@davenant.greenend.org.uk       http://www.chiark.greenend.org.uk/~ijackson/


-- 
To UNSUBSCRIBE, email to debian-ctte-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org