Bug#614907: [Pkg-javascript-devel] Bug#680080: Invalidated by dependency: Excuse for mediawiki-extensions

2012-07-11 Thread Thorsten Glaser
On Tue, 10 Jul 2012, Jonas Smedegaard wrote:

> Because it performs worse, which makes it less used in general, which 
> makes it less tested, which makes it less trustworthy.  I thought that 
> was already clarified at bug#679665.  Does it make sense now?

Thanks, yes.

> It is helpful that you introduce _different_ approaches if you have 
> ideas you think might be better, but less helpful to repost existing 
> ones rephrased.

Oh, sorry. I thought I had read through the bugreports, but apparently
didn’t see the connection.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-314
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Boris Esser, Sebastian Mancke



--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.2.02.1207110921370.8...@tglase.lan.tarent.de



Bug#614907: [Pkg-javascript-devel] Bug#680080: Invalidated by dependency: Excuse for mediawiki-extensions

2012-07-11 Thread Jonas Smedegaard
On 12-07-11 at 09:22am, Thorsten Glaser wrote:
> On Tue, 10 Jul 2012, Jonas Smedegaard wrote:
> 
> > Because it performs worse, which makes it less used in general, 
> > which makes it less tested, which makes it less trustworthy.  I 
> > thought that was already clarified at bug#679665.  Does it make 
> > sense now?
> 
> Thanks, yes.
> 
> > It is helpful that you introduce _different_ approaches if you have 
> > ideas you think might be better, but less helpful to repost existing 
> > ones rephrased.
> 
> Oh, sorry. I thought I had read through the bugreports, but apparently 
> didn’t see the connection.

No problem - just glad we are on same page now :-)

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature


Re: Draft GR for supermajority fix

2012-07-11 Thread Anthony Towns
On Mon, Jul 9, 2012 at 2:02 PM, Kurt Roeckx  wrote:
> On Mon, Jul 09, 2012 at 04:11:21AM +0100, Ian Jackson wrote:
>>Therefore, in the Debian Constitution amend A.6(3) as follows:
>>3. Any (non-default) option which does not defeat the default
>>   option by its required majority ratio is dropped from
>>   consideration.
>>1. Given two options A and B, V(A,B) is the number of voters
>>   who prefer option A over option B.
>> -  2. An option A defeats the default option D by a majority
>> - ratio N, if V(A,D) is strictly greater than N * V(D,A).
>> -  3. If a supermajority of S:1 is required for A, its majority
>> - ratio is S; otherwise, its majority ratio is 1.
>> +  2. An option A defeats the default option D by its
>> + required majority ratio if:
>> +  (a) V(A,D) is strictly greater than V(D,A); and
>> +  (b) if a supermajority of N:M is required for A,
>> +  M * V(A,D) is greater than or equal to N * V(D,A).
> I'm also not very happy with the wording of supermajority.  It's
> not really defined what it means, but is used.  For instance
> 4.1.5.3 talks about a "3:1 majority" and not about a
> supermajority.  I will probably translate this to if N > 1
> for use in devotee.

The original patch for this issue changed those to refer to a
supermajority requirement:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636783#10

Using the term "supermajority" consistently to refer to 3:1 etc but
not 1:1 seems like the clearer approach to me.

Cheers,
aj

-- 
Anthony Towns 


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAJS_LCVWsGFVUBnBE26CvDUHLL6eHSyB=czyqkxn9dnn_wk...@mail.gmail.com



Re: TC-initiated GRs, redux

2012-07-11 Thread Stefano Zacchiroli
On Wed, Jul 11, 2012 at 01:26:14AM +0100, Ian Jackson wrote:
> I think the recent flurry of discussion has more or less converged.
> You can find the results here:

Thanks a lot for your very effective coordination work in drafting these
GRs, Ian. I really appreciate it.

> I'd appreciate a final round of review (especially by TC members and
> the Secretary) at this stage.  If that is broadly positive I intend to
> propose these as TC resolutions shortly after Debconf.
> 
> The files are:
> 
>   informal-propose  allow private discussion (const. change)

I've some pending comments on this one, but for family reasons I'll be
unable to post them before July 20th or so. If you'd like to hear them
before officially starting the GR in question, I'd appreciate if you
could wait 1 week more after DebConf end. But I also don't want to stop
this very welcome activism wave! So I though of simply mentioning this,
but in the end do as you please.

Cheers.
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature


Re: Draft GR for permitting private discussion

2012-07-11 Thread Michael Gilbert
On Mon, Jul 9, 2012 at 6:57 PM, Ian Jackson wrote:
> Michael Gilbert writes ("Re: Draft GR for permitting private discussion"):
>> Just to clarify, that is not my perspective.  Like I said in the
>> following sentence,
>>
>>   The importance of a more stringent wording (I think) is to make it clear to
>>   project members that the committee will only be using this power in the
>>   most sensitive of situations, rather than all the time.
>
> I think the key difference between us is this: you seem to be arguing
> that the wording discouraging or limiting the TC's private
> conversations should be normative - that is, that the text should
> somehow say that under some vaguely specified situations, the TC would
> be actually forbidden from having the conversation in private.

Not really. My point is that any such change should maximally support
the ideals the project has set for itself in the Social Contract (i.e.
bullet 3).

> Whereas I think that this text should be in  - ie it should be
> rationale and explanation, but not grounds for anyone to assert that
> the TC had somehow violated the constitution and therefore that a
> decision was invalid, or something.

Having the wording grant explicit permission to take a discussion
private seems like it would be sufficient to guard against that type
of complaint.

> My suggestion was this:
>
> [+The Technical Committee is encouraged to
> hold discussions in public where feasible.+]
>
> But I'm happy to see a stronger wording:
>
> [+The Technical Committee should limit private
> discussions to situations where holding the conversation in
> public would be infeasible or unconstructive.+]

I think this wording is still lacking in idealization.  It needs some
kind of humility; acknowledging that private discussions are a
compromise that the committee is making only to protect human
emotions/feelings and other very sensitive matters, and in the
majority of cases are to be avoided.

I don't think infeasible or unconstructive are the best qualifiers.
Unconstructive discussions are not necessarily bad since they can
easily be ignored.  I'm hard pressed to come up with an infeasible
case (except perhaps when one does not have the ability to send mail
over the internet).

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MPVyBv9zpLCEdnw7O8gndF-=kgzfro03fxkdccad8u...@mail.gmail.com



Re: Draft GR for permitting private discussion

2012-07-11 Thread Russ Allbery
Michael Gilbert  writes:

> I don't think infeasible or unconstructive are the best qualifiers.
> Unconstructive discussions are not necessarily bad since they can easily
> be ignored.  I'm hard pressed to come up with an infeasible case (except
> perhaps when one does not have the ability to send mail over the
> internet).

Counterproductive, perhaps?  That's the best word that I can come up with
to capture my concern, which is that forcing some of these discussions to
be public would make the underlying problem considerably worse.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gu9n921@windlord.stanford.edu