Re: Bug#797533: New CTTE members

[Anthony Towns]

On Mon, Sep 14, 2015 at 09:37:28AM -0400, Sam Hartman wrote:
> What I'm hearing is that there seems to be general support for TC
> members calling for quick votes in cases like this.  If I were doing it
> I'd probably give 24 hours to comment on an interim ballot and then do a
> CFV.

It seems to me that the only way you'd get a ballot like that out quickly
is if there's a template you could easily fill out, that's "good enough"
for, say, 80% of issues. If you're coming up with something within a
day of an issue being filed, I don't think it's reasonable to try to
have a detailed background of the issue in the ballot, for instance.

A) agree with the bug:

 A.1) Under 6.1.2 of the constitution, the committee resolves the dispute
  between developers [...] (as maintainer of [...]) and [...] (as
  maintainer of [...]) by determining that:

   * [the priority of package ___ should be ___]
   * [/usr/bin/___ should be owned by package ___]
   * [bug  should be fixed in package ___]
   * [package ___ should be maintained by ___]
   * [...]

 A.2) Under 6.1.3 of the constitution, the committee accepts the
  delegation by developer [...] of the right to decide [...], and
  determines [...].

 A.3) Under 6.1.4 of the constitution, the committee overrules the
  developers involved, and requests the following technical course
  of action be undertaken:

   * [package ___ should be reuploaded with the following patch
  applied, or equivalent functionality: ...]
   * [package ___ should be reuploaded with the following patch
  reverted: ...]
   * [...]

 A.4) Under 6.1.5 of the constitution, the committee offers the following
  recommendation for dealing with the issue raised, but at this point
  leaves the final decision in the hands of the developers involved:

   * [the priority of package ___ should be ___]
   * [/usr/bin/___ should be owned by package ___]
   * [bug  should be fixed in package ___]
   * [package ___ should be maintained by ___]
   * [package ___ should be reuploaded with the following patch
  applied, or equivalent functionality: ...]
   * [package ___ should be reuploaded with the following patch
  reverted: ...]
   * [...]

B) decline the bug:

 B.1) The committee think the issue raised requires further discussion,
  but that the project would be best served if this took place via
  [the bug log | debian-policy | the  mailing list | ]
  rather than involving the committee directly at this point in time.

 B.2) The committee endorse the actions of [...] as the responsible
  maintainer and as such decline to overrule their decision.

 B.3) While not endorsing the decisions of [...] regarding this issue, the
  committee accepts that they were not unreasonable, and bearing in mind
  that, in general, individual developers have the right to "make any
  technical or non-technical decision with regard to their own work",
  declines to overrule the decision in this case.

For bug escalations where users think a developer's done something
wrong, A.3, A.4, B.1, B.2 and B.3 would be reasonable.

For conflicts between developers with overlapping jurisdictions, A.1, A.4,
B.1, B.2 and B.3 seem reasonable (and I don't think A.3 is necessary).

For the rare case where a DD delegates a decision to the ctte, A.2 or
B.1 would be the only reasonable options I think? If FD won initially,
and discussion resulted in consensus that the DD went ahead with, B.2
could become an option I guess.

If someone asks the ctte for advice on a topic before there's an
entrenched disagreement (!) I think FD and B.1 would be sufficient
alternatives for an initial vote?

(Hmm, having templates like this might make it easier for people to
understand how the ctte can actually help, maybe...?)

> I understand there are community members who want to go further than
> that and have automatic votes, etc.

FWIW, to me "automatic" means "quick", "easy", and "likely to actually
happen"; while "manual" means "slow", "painful", and "likely to be
forgotten pretty frequently". If you end up with a process that turns
out quick, easy and likely to actually happen, but requires people to
do manual steps, I'm likely to call it "automatic" anyway. ;)

Cheers,
aj


signature.asc
Description: Digital signature

Re: Bug#797533: New CTTE members

[Anthony Towns]

On Wed, Sep 09, 2015 at 10:31:24PM +0100, Wookey wrote:
> +++ Steve Langasek [2015-09-09 12:17 -0700]:
> > On Wed, Sep 09, 2015 at 05:30:03PM +0100, Wookey wrote:
> > > So what I learned from this is that, as currently operating, the
> > > committee is incapable of making quick 'overrule unreasonableness'
> > > decisions. My overriding impression was that those involved simply did
> > > not have the time available that would be be needed to enable that.
> > No, what you see here is that the TC did not agree with you that the
> > maintainer's action was unambiguously unreasonable under the circumstances.
> Well, maybe. Maybe there were discussions to that effect I didn't see.

FWIW, I read that bug at the time; though the only evidence I see off hand
is that I retitled it about a week after the jessie freeze began. Hmm.

Aha, it was off-list, but still in my email archives! This was on the
17th Nov, so AIUI it was already too late for anything useful, but FWIW
my response was:

---
Good grief. The timeline of that bug is:

Filed
 Date: Sat, 25 Oct 2014 05:58:36 +0200

Maintainer responds the next day (on a weekend), dropping from serious
to wishlist
 Date: Sun, 26 Oct 2014 14:04:05 +0100

Ten minutes later, submitter bounces the severity back to serious,
calls the change "hostile"
 Date: Sun, 26 Oct 2014 14:15:35 +0100

An hour later, Matthias bounces the severity back to wishlist
 Date: Sun, 26 Oct 2014 15:15:36 +0100

Thirty-five minutes later, tech ctte is officially called in
 Date: Sun, 26 Oct 2014 15:51:00 +0100

I don't see any serious attempt to work with the maintainer there.

>From what I can tell, doko's mistaken in saying it's not a release
goal. CrossToolchains is listed on https://wiki.debian.org/ReleaseGoals
and the link there recommends behaviour that the changes break. Release
goals justify an important severity bug, not a serious one though,
so the severity bouncing seems marginally abusive.

doko didn't mark the bug as wontfix, just wishlist, so I don't see any
indication that he doesn't think the bug's worth fixing. That leaves the
question of prioritising the fix (in particular pre- or post- jessie),
and what form the fix should actually take.

If it were me, I'd be inclined to:

 - reset the severity to important, since it's a release goal

 - recommend doko resolve it by:
 (a) reverting the change,
 (b) updating the wiki page with correct documentation on how to
 do multilib cross-builds (particularly addressing the issue
 that packages are apparently uninstallable?), or
 (c) inviting Wookey or similar to co-maintain that aspect of the
 packaging (and deal with bug reports due to it)

 - criticise Helmut for inflating the severity and invoking the ctte so
   quickly rather than working with doko

As far is jessie is concerned, it seems like the release goal mostly
missed the boat? All the cross-gcc* packages are blocked by the
freeze, and have RC bugs filed by doko, without any response from the
maintainer... So it seems like a shame to miss jessie, but I'm not seeing
any huge reason why it should bypass the freeze.

The timing wrt the freeze seems to be:

 - 22nd Oct: cross-gcc-* packages make it into unstable
 - 24th Oct: cross-gcc-defaults makes it into unstable
 - 24th Oct: doko uploads change to gcc-4.9
 - 24th Oct: doko files bugs against cross-gcc-* packages
 - 25th Oct: last day for uploads to unstable to hit before freeze

which again says to me that the cross-gcc-* stuff was left way too late,
but also dropping support for that method of cross-building gcc at almost
the last minute before the freeze seems a bit unreasonable.

I don't see anything here that justifies overruling the maintainer
though. Maybe if I were the maintainer (heaven forbid) I'd do things
differently, but that's barely justification for offering advice, let
alone setting policy or overruling the current maintainer.
---

I guess at this point I'd summarise it as three things:

 - Trying to get a release goal done by uploading to unstable a couple of
   days before the absolute deadline for uploads to unstable is a bad
   plan.

 - That issue was actually pretty complicated, and not one that's going
   to come to an obvious consensus in a couple of days, so expecting an
   effectively instant endorsement of your view (either by doko being
   convinced by your bug, or the ctte overruling doko within the 24
   hours or so you'd need in order to get a reversion into unstable)
   wasn't really reasonable. Again, a good reason to do things well
   before the freeze.

 - Given they weren't going to overrule immediately, and thus cross-gcc
   wasn't going to make jessie, it would have been good for the ctte to
   have actually said "we're not going to overrule doko in time for the
   freeze" within 24 hours of the issue being referred -- eg, by having
   an immediate vote where 3+ members vote for further discussion over
   overruling. This has never happened before, and the 

tech-ctte decision/feedback speed (was: Re: Bug#797533: New CTTE members)

[Anthony Towns]

(bug dropped, subject changed)

On Thu, Sep 10, 2015 at 01:32:16PM -0400, Sam Hartman wrote:
> > "josh" == josh   writes:
> josh> That's not a bad plan, actually.  The three standard options
> josh> could be, in effect, "preliminary injunction against the
> josh> maintainer to avoid immediate harm, but we still need to talk
> josh> about this more", "dismissed as completely inappropriate to
> josh> have taken to the TC at all", or "we need further discussion
> josh> before we can even offer an opinion".
> Sure, and I'd also argue that someone on the TC should believe that an
> option other than FD should win before holding a vote.
> We don't need more process for process's sake.

In this case the process wouldn't be for process's sake, though. One of
the failures with #776708 was that it was urgent and there was simply no
feedback from the ctte that there was disagreement blocking a quick
resolution.

> But having something like this in place and an understanding on the TC
> that if k TC members (probably k = 1) feel this is reasonable calling
> for such a vote is a fine thing to do.

I think if the submitter thinks the issues is urgent ("freeze deadline in
24 hours! help!") that should be enough; even if none of the TC think an
immediate decision is actually reasonable, having an actual vote that
documents that would still be helpful.

I tend to think "automatic" processes are better than ones that actually
require humans to think about them. In this case, if ctte members have
to come up with an answer to "is immediately overriding the maintainer
reasonable?", then it seems easier to do that in response to a thoughtless
automatic vote, and also more transparent to do it by voting than simply
not doing anything as a result of deciding one way.

Heck, maybe make the process be: urgent issues get voted on a day after
they're filed, and every issue gets a vote proposed one day after the
monthly meeting. FD is always a valid option, but members voting for FD
should make it clear what they think actually needs further discussion.

(In #766708's case, I would probably have personally voted "decline to
overrule maintainer" above FD for #766708 immediately, given the freeze
deadline likely made FD an effective rejection anyway)

Cheers,
aj

Re: Policy Process and Rough Consensus

[Anthony Towns]

On Tue, Mar 31, 2015 at 12:40:00AM +, Sam Hartman wrote:
 Steve, in one of the TC meetings last year, you made the claim that the
 policy process was not a rough consensus process.

I believe this was:

vorlon keithp: our policy process isn't based on rough
 consensus, but on a stricter definition of consensus

http://meetbot.debian.net/debian-ctte/2014/debian-ctte.2014-12-04-18.00.log.html
 
 I recently read process.txt.gz from the debian-policy package.  That
 document (admittedly dated after #741573 was submitted) claims the
 opposite.
 I don't know what the document said previously (although I realize I
 could git clone if I cared).

That's mostly from:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545548
 
isn't it?

Here's some other sources on how objections work:

] I think
] that we should stick to the current method of policy changes which
] allows for anyone to initiate discussions, and a small group of
] developers to bring changes forth; what we need is someone with
] authority to step in and steer discussions that are stalled; and
] decide whether a consensus has been reached.
]
] I still do not think that this person should be able to
] override formal objections from more than one developer

 -- Manoj, Mar 2000
https://lists.debian.org/debian-policy/2000/03/msg00135.html

] The old document also sates that the whole process could be
] stopped dead in its tracks by a single formal objection. And then we
] deferred to the TC or took a vote.  I think that is a flaw -- if
] there are serious objections from a significant minority of active
] members of the mailing list, sure, we should punt to the TC or a GR,
] but not if there is one lone objection.

 -- Manoj, Oct 2006
    https://lists.debian.org/debian-vote/2006/10/msg00397.html


] * Bill's other objections haven't met with any other agreement, so the
] consensus is to procede despite them.  To use IETF terms, Bill's in the
] rough part of rough consensus.  (I've been there before myself.)

 -- Russ, Aug 2009
    https://lists.debian.org/debian-policy/2009/08/msg00172.html


] The special tasks of Policy delegates are: ...
]
] * Rejecting proposals.  Anyone can argue against a proposal, but the way
]   I'd been thinking of it, only Policy delegates can formally reject it.
] 
] * Counting seconds and weighing objections to proposals to determine
]   whether the proposal has sufficient support to be included.

 -- Russ, Aug 2009
    https://lists.debian.org/debian-policy/2009/08/msg00155.html

] 3. Whenever there is any disagreement over a change, the process here
]    effectively grinds to a halt.  We don't seem to have a workable process
]    for achieving rough consensus with some disagremeent, or making
]    decisions when there's disagreement.  We might be able to get around
]    this by more aggressively appealing to the tech-ctte.  Obvious
]    examples: #587279, #248809.

 -- Russ, Jul 2012
https://lists.debian.org/debian-policy/2012/07/msg00073.html

That seems to me to add up more to policy is based on rough consensus,
but at times fails to live up to that, and instead requires a stricter
definition of consensus than what Steve said.

 Under that process, I'd assume the following:
 * three seconds without an articulated unresolved technical objection is
   strong evidence that a proposal has received rough consensus.
 * When a proposal has received three seconds, someone claiming that
   there is not rough consensus must clearly articulate what they believe
   is an unresolved technical objection.

https://bugs.debian.org/555979 is arguably an example both ways:
a single objection arguably stalled the bug for a couple of months,
however a single objection was not enough to block the change. (IMO,
the objection wasn't even addressed, but eh). That said, it was a trivial
one line patch where the patch took five years to be written...

I guess my understanding is the policy process is supposed to be:

(a) proposer:
 - proposes a change
 - gets three or more seconds
 - addresses any objections raised

followed by one of:

(b) policy editor:
 - evaluates objections and responses, determines consensus exists
 - commits the change to policy

(c) proposer: withdraws change

(d) tech ctte: reviews difficult proposals where consensus isn't able
to be obtained

But there are four significant failure modes where that doesn't work
in practice:

 1) proposer doesn't propose a concrete change or there's no comments
(and hence no seconds)
 2) objections just sit around rather than getting addressed/resolved
 3) policy editor doesn't make policy changes in the event of even minor
disagreements
 4) tech ctte doesn't take on the difficult issues 

?

Cheers,
aj


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150331104419.ga3...@master.debian.org

Re: Resigning from the TC

[Anthony Towns]

On 5 December 2014 at 03:15, Colin Watson cjwat...@debian.org wrote:

 I confess to having lost track of what effect my resignation would have
 on things like the TC term limit GR, especially given Ian's and Russ's
 resignations.


​Only effect I can see is that if Lucas's 2-R proposal is the one that's
chosen, then whether you resign in 2014 or 2015 will affect whether Steve's
term expires on 1/1/2016 or 1/1/2017.​ I don't think that matters much (and
if anyone else resigns over the next twelve months, that'd change things
too under the 2-R rules).

The other effect possibly worth considering is that if you resign prior to
a new member being appointed, then there'll be 5 members on the ctte and
the ctte can appoint the next new member without the DPL's approval
(6.2.3). If I were you, I'd probably just schedule my resignation for
shortly after the 1st new ctte member nomination gets approved by the DPL?

​Cheers,
aj​

-- 
Anthony Towns a...@erisian.com.au

Re: [CTTE #746578] libpam-systemd to switch alternate dependency ordering

[Anthony Towns]

On 17 November 2014 05:37, Steve Langasek vor...@debian.org wrote:

 On Sun, Nov 16, 2014 at 04:52:37PM +0100, John Paul Adrian Glaubitz wrote:

  A decision which lead to another great Debian Developer leave the
  ship!
  Great Work!
 This demonization of the Technical Committee for doing their job under the
 constitution needs to stop.

I don't think a sarcastic Great Work! rises to the level of
demonisation.


  On Sat, Nov 15, 2014 at 04:16:28PM -0800, Don Armstrong wrote:
   5. We therefore overrule the decision of the maintainer of
 ​​

 ​...​
   I hope that he doesn't
 actually view this TC override as an attack on the systemd maintainers.

​... this is the TC providing technical guidance when
 asked to do so; and if the TC comes to a different conclusion than a
 maintainer who is acting in good faith, that is not an attack on that
 maintainer.


The committee has five powers:
 1. decide on technical policy
 2. decide on overlapping jurisdictions
 3. make decisions on a requestor's behalf
 4. overrule developers
 5. offer advice

​The tech ctte could've addressed this issue by providing policy guidance
or by just offering advice, and assuming that the systemd maintainers would
act on th​e advice or policy in good faith. Choosing to override the
systemd maintainers was far from the most friendly available option.

I don't think it's unfair to say that the technical committee is both the
most powerful and least accountable group in Debian. Honestly I'd imagine
most folks in Debian would expect anyone holding that level of power to act
with a fairly high degree of caution, deliberation and, frankly, compassion
for those who don't share those powers. Personally, I'd expect that power
imbalance would imply an inverse courtesy imbalance -- that is, the
technical committee members go out of their way to be considerate of their
less-powerful co-developers, and tolerant of criticisms made about their
actions.

Let me put it this way: have the four committee members that were on the
upstart side of the fence considered asking for the demonisation of the
systemd developers to stop? The committee could do that under their power
to make formal announcements about its views on any matter, and that
might go some distance to re-establishing some trust. The systemd
developers (both upstream and the Debian maintainers) certainly seem to
have had more demonisation than the committee to me.

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au

Re: Resigning from the TC

[Anthony Towns]

On 8 November 2014 22:51, Colin Watson cjwat...@debian.org wrote:
 I hereby declare my intent to resign from the Debian Technical
 Committee.  The Constitution doesn't really have a clear procedure for
 handling resignations here;

FWIW:

  2.1. General rules
  ...
3. A person may leave the Project or resign from a particular post
   they hold, at any time, by stating so publicly.

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cajs_lcxhv2bo+5sdbgtdglobt8dnvofft4wqe8mhdanqnns...@mail.gmail.com

Bug#636783: TC minimum discussion period

[Anthony Towns]

On 28 June 2014 10:50, Steve Langasek vor...@debian.org wrote:
 In the IRC meeting on May 22, we discussed several different approaches for
 handling the call for votes.  The one I favor is to introduce a formal
 cloture vote into the process.

I thought this made sense too.

 A cloture vote is a procedural up/down vote on whether to close debate on a
 question and move to a vote on the ballot.  ...

Here's an alternative strawman:

 - Any member of the TC may call for votes on a ballot at any time.
 - When calling for votes, the TC member may propose any combination
of resolutions they believe is appropriate to be considered on the
ballot, provided they fall under the ctte's constitutional powers.
 - When voting on the ballot, TC members may rank the proposed options
from 1 to n in the normal manner for Debian ballots.
 - An additional Cloture option will be automatically added to the ballot.
 - The Cloture option may only be marked Y to approve cloture, or
N to deny cloture.
 - The Cloture option is the default option for the SRP. A Y vote
for cloture is treated as ranking the default option below all others
(including unranked options). A N vote is treated as ranking the
default option above all others.
 - In the event that cloture fails (ie, the default option wins the
SRP), the TC members should discuss the reasons for the failure and
produce a new ballot that is able to pass cloture.

(SRP=Standard Resolution Procedure)

  - Ballot options proposed during the cloture vote shall be included on the
ballot.

I don't think that's likely to be compatible with the or when the
outcome is beyond doubt provision. ie:

  Let's vote on upstart vs systemd!
  next ten minutes: yes yes yes yes yes
  okay, here's the ballot!

  three hours later: what? no! i want option upstart and must
support multiple systemds on the ballot
  too bad, suckah

To make that provision work, I think you'd have to have a minimum
voting period, in which case I don't think there's any value beyond
just having a minimum discussion period.

But ultimately, if a majority of the ctte want to vote on a particular
question that's within the ctte's remit, I don't see why any minority
should get to block them from having exactly that vote. I do think it
makes sense to formally establish that a majority do want to undertake
that vote though.

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cajs_lcxtwotzxpefbujxh_x8-sq0oafy571lgg4yz0xjzzo...@mail.gmail.com

Bug#741573: Two menu systems

[Anthony Towns]

, then everything additional that
the trad menu does is by definition useless (for users who want to do
menu things, anyway)... And if it's changed so it doesn't do anything
additional, what's the point?

So based on that I would say:

 - requirement that they should *not* be present
 - consequence of having them should be a minor bug

But I don't even know if I'm using desktop menus or trad menus, so...

 * How Policy should formally represent the distinction between different
   levels of requirements.

FWIW, I think policy should be distinguishing whether its
recommendations are requirements for distribution (legal issues,
dependency errors), proper practice (ie, it's a bug if you don't do
this), or just a good idea to consider (a suggestion from experienced
developers/packagers), but beyond that should just be documenting how
to make optimal packages assuming infinite time and motivation. I
don't know how you could do that more effectively; must/should/may
still seems reasonable to me, but it doesn't seem that effective.
Splitting them as three separate documents (distro/release
requirements, policy, suggested practices) might be an option. Maybe
it would be more effective to approach the problem from the other end
-- provide a document/site of what the project thinks are the most
important things to work on, so that people who want to force
maintainers into doing things go there rather than debating which verb
is used in policy.

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


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

Bug#727708: call for votes on default Linux init system for jessie

[Anthony Towns]

On 10 February 2014 06:41, Serge Kosyrev skosy...@ptsecurity.ru wrote:
 False.  Three messages on this list brought this conflict of interest
 into light:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2810 by Anthony Towns
 [...]
 There was no answer.

So, fwiw, I thought the above was kind of mean on my behalf. Not
/wrong/ per se, just mean.

I haven't been able to think of a *good* answer for this concern,
even in an arbitrary ideal world where the constraints are different.

For instance, Steve could recuse himself from the discussion entirely
-- that's what you'd expect in many cases where there are commercial
conflicts of interest, eg. But that would be ridiculous here, because
both his technical knowledge as upstart maintainer is nigh-on
essential to the discussion, and his input as to how things have
worked in Canonical is pretty useful too.

He could recuse himself from voting, or perhaps the committee chair or
committee as a whole could ask him to do so -- but at least at this
point, that would be effectively equivalent to Steve directly voting
systemd above upstart, and that would be a fairly unreasonable forced
reversal of preferences for Steve to make, or it would involve a
conflict of interest on behalf of the chair (who's indicated a
preference for systemd), or the rest of the committee (which has
indicated a 4:3 preference for systemd). Maybe one of these things
would have been good to do earlier, before positions had coalesced,
but I don't think they're reasonable things to do or expect now. (They
might have been when I sent the mail, but if so, they only remained
plausible for a pretty short window in my opinion; further, Steve
mentions that the committee discussed this earlier and came to the
conclusion that no action was needed)

If the committee had the flexibility to do so, maybe a reasonable
thing would have been to replace Steve for this vote with a less
interested party early in the discussions; eg by letting Phil Kern
step in to provide the 8th vote for this issue, so that Steve could
simply act as an advocate and technical advisor to the committee on
this issue. Alternatively, perhaps a reasonable thing might have been
to give the primary systemd, sysvinit and upstart maintainers the
ability to vote on this issue too. Neither were options open to the
committee though.

As it stands, though, Steve has to: consider the implications for
Debian, consider the implications for upstart (as maintainer),
consider the implications for Canonical and Ubuntu (as a Canonical
employee and Ubuntu dev), mostly dismiss the implications for
Canonical/Ubuntu (in order to prioritise the implications for Debian
as a ctte member making a ctte decision), and deal with accusations of
having a conflict of interest, despite not being able to do anything
concrete to address them. Oh, and I gather Steve's trying to run a
debconf in six months time or so too, which I understand could add
some degree of stress on its own...

So yeah, I stand by my description of that as fairly challenging,
and I'm really glad it's not me in that position.

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
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_lcxoeoohwrkhlk67rjhcobonfqg-b6zat9sow5vd2aq...@mail.gmail.com

Re: Bug#727708: Call for votes on init system resolution

[Anthony Towns]

On 8 February 2014 18:26, Adrian Bunk b...@stusta.de wrote:
 On Sat, Feb 08, 2014 at 04:40:22AM +, Anthony Towns wrote:
 I'd consider that tactical voting. Basically, I think the value in the
 FD option is to be able to say this option has not been fully baked,
 and more discussion would be helpful to ensure it is properly understood
 and the consequences are clear.
 The Constitution disagrees with you on that:
Options which the voters rank above the default option are options
they find acceptable. Options ranked below the default options are
options they find unacceptable.

Well, the constituition was drafted by humans, who do occasionally get
things wrong. Probably whoever came up with that wording was an idiot,
and no one should pay attention to anything he says... [0]

It seems to me, the point of having a vote is one of two things:

 - to come up with a decision, despite different options being
available and no easy consensus between them
 - to have the group commit formally to a decision so the entire group
is accountable for it

At the point at which someone calls for a vote between various
options, there's a few possible outcomes:

 - a decision is made to adopt one of the options
 - no decision is made
 - the vote gets put on hold and re-held with different/additional options

It seems to me that no decision is made is not actually a *useful*
possible outcome of the voting system; but it's effectively what FD
describes, and by giving it extra powers, the voting mechanism
encourages its use.

I'd actually go further, and say that calling options acceptable and
unacceptable is a bad idea, and is opposed to the
consensus-building approach that's really the ideal. It's not that
any of these things aren't acceptable; it's all just software, it's
not a big deal to work around even the craziest ideas out there. I
mean, talk about crazy, but how many people are there out there
running operating systems they don't even have the source for? There's
just different ideas, some of which are better than others, and we
occasionally have to pick between them.

 A less disputed example makes it more clear where that does make sense:
 3 of the 6 TC votes (Steve, Colin, Russ) voted all sysvinit options
 below FD since they do not consider sysvinit acceptable as default
 init system for jessie.

 I doubt anyone thinks that further discussion is needed for sysvinit,
 but some TC members do sincerely not consider it an acceptable option.

Yes, that's exactly the inconsistency I'm attacking here. If further
discussion isn't needed, it shouldn't be being voted for.

Voting sysvinit below FD isn't needed in the above case, because
either 5 or 6 of 6 TC votes rank it below the other options. If that
weren't the case, and sysvinit were a contender, and further
discussion wasn't useful, the only thing voting FD above sysvinit
would achieve is avoiding a decision getting made, when that is
exactly the *purpose* of voting.

 That's a long way different to saying if my preferred option does not
 win, we should delay making a decision and keep holding votes until it
 does win.
 No TC member ranked FD on second place, and all 6 votes stated that
 both D and U are acceptable.

Three TC members voted the L options for systemd and upstart above FD,
and FD above all the T options. (I really hope that won't be the case
on the next vote)

 independent of Keith and Bdale's ballots.
 Under the assumption that both Keith and Bdale rank DT above FD.

Yes, I essentially specified DT as Bdale and Keith's first choice. The
only other systemd option to rank first was DL, and if that had been
either's first choice, then the result would have been a casting vote
between DL and UL:

DL  DT 5:3
DL  UT {8,7}:{0,1}
DL = UL 4:4
DL  FD {8,7}:{0,1}

(Same result if both voted DL first)

 I'd actually call it a bug in the voting system that the casting vote
 might decide between an option that 3 TC members do not find acceptable,
 and an option that is unanimously considered acceptable. [1]

Sure, that's the power of the word unacceptable. But it's not like
there's an objective measurement of what's acceptable -- it's
(literally) just whether an individual is willing to tolerate
something that's not perfect. If you want to put it in its most
negative light, it's empowering the intolerant, which probably isn't a
terribly healthy thing to do.

The reason that FD works the way it does is to allow a minority of
developers to object to changes they don't like -- like social
contract changes to drop non-free, or constitutional changes to elect
a benevolent dictator for life. That sort of obstructionism is
probably a useful thing to enable to some degree, but it's not
something that should be used tactically in the way that should I
vote X above or below FD usually is. Ultimately, you shouldn't have
to think hmm, I really dislike Y, but I really, really, really
dislike Z; do I put FD just before Z or before Y too?. You should

Bug#727708: call for votes on default Linux init system for jessie

[Anthony Towns]

On 9 February 2014 09:52, Russ Allbery r...@debian.org wrote:
 If you're looking for Policy Editors who enjoy running things through a
 process that won't be successful just so that we can say they've been run
 through a process, you're going to need someone other than me.

In that case, wouldn't it make sense to have a quick chat with the
other policy editors about officially delegating the task of deciding
on policy for depending on init systems to the tech ctte?

Could even open a new bug for it!

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
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_lcvyxkwb8sg1v+pgsj+kle1+2qyxyogzgvl_h1sf4-2...@mail.gmail.com

Re: Bug#727708: Call for votes on init system resolution

[Anthony Towns]

Bug cc dropped, replaced with -ctte.

On Fri, Feb 07, 2014 at 08:29:27AM +0200, Adrian Bunk wrote:
 On Fri, Feb 07, 2014 at 08:59:59AM +1000, Anthony Towns wrote:
  It's really pretty terrible to actively use FD to try to block options
  that aren't your favourite.
 When you are saying a set of proposals considered reasonable by all the 
 members, that basically implies don't offer the T rider options since 
 these are options that are not considered reasonable by at large part 
 (at least 3 members) of the TC.

I'd consider that tactical voting. Basically, I think the value in the
FD option is to be able to say this option has not been fully baked,
and more discussion would be helpful to ensure it is properly understood
and the consequences are clear.

That's a long way different to saying if my preferred option does not
win, we should delay making a decision and keep holding votes until it
does win.

It's obviously not possible to tell which one of those motivations is
behind a vote just from looking at the vote; but if you're voting FD above
an option and not trying to make it clearer what the consequences are,
or trying to improve it to make it better understood or better match
people's intentionds, I think it's fair to say you're abusing the FD
option. Proposing options, then voting them below FD seems especially
hard to rationalise as anything but an attempt to use the voting system
to prevent a decision being made.

That the Debian voting system uses the FD to enforce quorum and
supermajority requirements makes it effective to vote tactically. I
think that's a mistake though (and given my involvement, probably my
istake at that).

 What we see in the combined vote is actually that DL is an option
 that makes both sides win in what they consider their most important
 question - and that seems considered reasonable by all TC members.

With only 6 of 8 votes in, I don't think you can draw that
conclusion. Half of the tech ctte members who indicated a preference for
systemd didn't put in a ballot for that vote; and the vote was cancelled
due to all four of the ctte members who'd indicated a preference for
upstart wanting to give Steve a chance to come up with an alternative
to L/T.

Given neither quorum not supermajority requirements are an issue in
this vote; here's how a pure Condorcet treatment of the votes would look
(ignoring GR, and the OpenRC, SysV options):

  ian, steve, andi:
 UL DL FD UT DT
  colin: UL DL UT DT FD
  russ:  DT DL UT FD UL
  don:   DT DL UT UL FD
  
  bdale, keith: 
 DT  DL UT  UL
 DT  UT DL  UL
 DT  UL,FD

  DL  UT (6:0)
  DT = DL (4:4)
  DT = UL (4:4)
  DT = UT (4:4)
  UT = UL (4:4)
  DL = UL (4:4)

  UL  FD (5:1)
  DT  FD (5:3)
  DL  FD (6:0)
  UT _ FD (3:3)

The transitive defeats are then:
  DL  UT
  UL, DT, DL  FD
and possibly (depending on the details of Keith and Bdale's ballots):
  UT  FD
or
  FD  UT

Since there aren't any circular transitive defeats, Schwartz set is
every unbeaten option, and thus is:

  DL, UL, DT

independent of Keith and Bdale's ballots. There aren't any defeats
between these options, so it's down to a casting vote.

In the hypothetical where the votes were:

  4x UL DL FD UT DT
  4x DT DL FD UT UL

the only defeats would be:

  8:0  DL  FD  UT

and the Schwartz set would be {UL, DT, DL} with the casting vote
choosing amongst that set (ie, exactly the same outcome).

If half the committee thinks DT needs more discussions, and the other
half thinks UL needs more discussion, I would hope that they'd actually
undertake that discussion, and propose a ballot with UL', DT', and DL
as options, rather than just choosing one straight away.

On the other hand, if the committee has sincerely finished discussion and
wants to come to a conclusion, I think that's the right outcome for such
a precisely divided issue, and that the fact the Debian voting system
would actually drop UL and DT in the above case is a problem. I think
that's due to insincere ranking of FD, but if it is, then rewarding
that is a bug in the voting system.

Having Further Discussion be a yes or no option, rather than being
ranked against other options would probably have been a better plan --
the result then would presumably be 8:0 FD*, or 8:0 *FD. I don't know
how you'd reasonably require a supermajority for some options but not
others in that case though.

Cheers,
aj


-- 
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/20140208044022.ga28...@master.debian.org

Bug#727708: Call for votes on init system resolution

[Anthony Towns]

On 7 February 2014 08:44, Adrian Bunk b...@stusta.de wrote:
 If Colin joins Ian, Andreas and Steve in voting DT and UT below FD,
 then T is dead.

It's really pretty terrible to actively use FD to try to block options
that aren't your favourite. Honestly, I would have expected the tech
ctte to be able to come to a consensus on a set of proposals
considered reasonable by all the members, and accept whatever a
majority decided. I'd certainly hope that tech ctte members won't
tactically change their vote to try to hack the process.

(The obvious counter is for the four members who prefer T to L to vote
all the L options below FD in the same way as Andi, Ian and Steve have
voted all the T options below FD)

(Longer term, it seems to me the vote system would be improved by only
allowing voters to cast a vote that ranks the proposed options between
themselves, or to vote for Further Discussion (with no ability to
express preferences amongst the proposals). Quorum would then be
satisfied by having Q votes ranking the options, and a vote would only
be blocked if there was 50% or more of voters voting for FD. A similar
idea to supermajority requirements could be achieved by allowing
proposals to be blocked by 1/N voters voting for FD where N  2)

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
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_lcvxq2eqa_93so6hg7ng_xrpcjt1u0kojqiri8ejd5t...@mail.gmail.com

Bug#727708: call for votes on default Linux init system for jessie

[Anthony Towns]

Hey Colin,

On 29 January 2014 21:13, Colin Watson cjwat...@debian.org wrote:
 On Wed, Jan 29, 2014 at 07:21:43AM +1000, Anthony Towns wrote:
Q2: Is it OK for packages to depend on a specific init system as
pid 1 ?
   Q2a: Is it OK for packages providing init systems to provide other
 APIs beyond just the minimum needed for starting/stopping services?
 We might disagree on the extent, perhaps, but I doubt anyone on the
 committee would vote against this in its general form;

So looking at the votes today, I would have said that both Ian and
Andi's original votes are against this (ranking the options which
allow specifying a dependency on a specific init below further
discussion), and probably Steve's does too, although I assume that's
more an objection against the wording.

At least, the impact seems like it is:

 - init systems can provide whatever extra APIs they like
 - other packages can only use extra APIs if they have a dependency on
the providing package
 - packages may not depend on specific init systems

 * therefore packages cannot use the extra APIs

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
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_LCVyWXwTGjK0K=pooaz+pvvngrbxu1_rcblz7h6079x...@mail.gmail.com

Bug#727708: Call for votes on init system resolution

[Anthony Towns]

On 6 February 2014 11:20, Russ Allbery r...@debian.org wrote:
 I therefore intend to change my vote to list FD first iff Steve does the
 same, since I think it's up to him to decide whether he wants to stop,
 rework, and start again, or just continue on since the vote has started
 anyway.

The votes so far are:

 ian: UL DL OL VL GR *FD* UT OT VT DT
 andi: UL DL OL VL *FD* GR UT DT OT VT

 steve: UL DL *FD* OL VL UT DT OT=VT GR
 russ: DT GR DL UT *FD* OT VT UL OL VL
 colin: UL DL OL UT DT GR *FD* OT VL VT
 don: DT DL UT UL OT OL VT VL GR *FD*

 ian2: FD UL DL OL VL GR UT OT VT DT
 andi2: FD UL DL OL VL GR UT DT OT VT

With the initial vote, the following options are eliminated:

 OT, VT  (ian, andi, steve, russ vote these below FD)

With Ian and Andi's changed votes, the following options are eliminated:

 OL, VL (ian2, andi2, steve, russ vote these below FD)

That leaves UL, UT, DL, DT and GR still in the race against FD.

If Steve changes his vote to FD  *, and Russ does likewise as he's
stated, the vote will be decided as FD again.

If no one changes their vote, then, at present, the comparisons are:

  UL = FD 3:3 (steve, colin, don in favour; russ, ian2, andi2 against)
  UT = FD 3:3 (russ, colin, don in favour; steve, ian/ian2, andi/andi2 against)
  DT = FD 3:3 (russ, colin, don in favour; steve, ian/ian2, andi/andi2 against)
  GR = FD 3:3 (russ, colin, don in favour; steve, ian2, andi/andi2 against)

So those options will be eliminated if Bdale and Keith don't vote, or
if either Bdale or Keith vote them below FD.

  DL  FD 4:2 (ian2, andi2 against)

That can only be eliminated at this point if both Bdale and Keith vote
it below FD. It's the only option that had all six original votes
ranking it above FD.

(As it stands, DL would thus win the vote since all other options are
eliminated)

As it stands, that also means that Bdale and Keith could collude to
determine the outcome of the vote amonst {D,U}{L,T} by only voting the
option they prefer above FD.

GR comparisons are:

  UL  GR 5:1 (russ against)
  UT = GR 3:3 (steve, colin, don in favour; ian, andi, russ against)
  DL  GR 6:0
  DT  GR 4:2 (ian, andi against)

Rankings between remaning actual outcomes is:

  4x  UL  DL  UT  DT  (steve, colin, ian, andi)
  2x  DT  DL  UT  UL  (russ, don)

So that's

   UL  DL  DT  4:2
   UL  UT  DT  4:2
   DL  UT  6:0

It seems to me that if this ballot fails to FD, any future ballots
should skip options:

  OT, VT  (insufficient support over FD)
  OL, VL  (at least 6 of 8 committee members prefer UL and DL over
these options)

It seems unlikely that there's any actual support for UT, either.


Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
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_LCVhLfgK9zi6PjrZnDQ8edd+qHYczG-=da79eh1pqtv...@mail.gmail.com

Bug#727708: Call for votes on init system resolution

[Anthony Towns]

On 6 February 2014 16:27, Anthony Towns a...@erisian.com.au wrote:
 Rankings between remaning actual outcomes is:
   4x  UL  DL  UT  DT  (steve, colin, ian, andi)
   2x  DT  DL  UT  UL  (russ, don)

Ah! I thought there was something to add here

The above votes divide neatly into upstart v systemd camps. Given
Bdale and Keith have expressed a preference for systemd previously,
presumably they fall onto the systemd side; so will vote presumably
vote either DT or DL above the other options, and will vote DL  UL,
and DT  UT.

In that case,

  DL  UT6:2, 7:1 or 8:0

  DL = DT  6:2, 5:3 or 4:4
  UL = UT  6:2, 5:3 or 4:4
  UL = DT  6:2, 5:3 or 4:4

  DT = UT  4:4
  DL = UL  4:4

UT would thus have no chance of being in the Schwartz set (it doesn't
beat anything, and is beaten by DL).

Possible outcomes are then:

  DL = DT  6:2, 5:3 or 4:4
  UL = DT  6:2, 5:3 or 4:4
  DL = UL4:4

ie:
 - if either Bdale or Keith vote DT below UL or DL, DT loses, and the
result is determined by Bdale's casting vote between UL and DL
 - otherwise, the result is determined by Bdale's casting vote amongst
UL, DL and DT

Also, Russ correctly points out:
DL  GR 6:0
 For whatever it's worth, I think this line is wrong.  I voted GR above DL.

Hopefully there wasn't much else wrong with the analysis. (Having 10
options on a vote that's supposed to have its results tallied by hand
seems nuts to me...)

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
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_lcvgqenurnnuzffvwfw29wvadt3su1wveabffnwc-l2...@mail.gmail.com

Bug#727708: TC resolution revised draft

[Anthony Towns]

On 2 February 2014 04:05, Uoti Urpala uoti.urp...@pp1.inet.fi wrote:
 On Sat, 2014-02-01 at 17:10 +, Ian Jackson wrote:
 Sébastien Villemot writes (Bug#727708: TC resolution revised draft):
  P1: DT  UT  DL  UL

 So his example was one where the D/U and L/T choices were independent
 for every voter,

Formally, there isn't a way to vote for an arbitrary partial order by
ranking options. ie, you can't vote for:

  DT  UT
  DL  UL
  UT  UL
  DT  DL

without inadvertently and insincerely expressing further preferences.

Err, yes you can:

  DT  UT = DL  UL

works fine. In which case the votes would be:

  P1: DT  UT = DL  UL
  P2: DL  UL = DT  UT
  P3: UT  DT = UL  DL
  P4: UT  DT = UL  DL

and the pairwise defeats are:

  DT  DL : 3 vs 1
  UT  UL : 3 vs 1
  DT  UL : 1 vs 0
  UT  DL : 2 vs 1

  UT = DT : 2 vs 2
  UL = DL : 2 vs 2

Transitive defeats are then just:

  DT t. defeats DL, UL
  UT t. defeats DL, UL

Schwartz set: { DT, UT }

There aren't any defeats in the schwartz set, so P1 uses a casting
vote to choose which of DT, UT is the winner, presumably DT.

Compare that to the corrected example's potential results:

  combined: UT wins
  D/U first: draw, tie break = D, T wins, so DT
  L/T first: T wins, draw, tie break = D, so DT

So I think you can put the difference down to either people expressing
insincere preferences, or that the additional, sincerely held,
preferences expressable via the combined vote having an effect on the
outcome, which shouldn't be surprising.

Cheers,
aj


--
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_lcxyabseptncr5zjw1zl7shuwy9x_rro+t4fsghgj++...@mail.gmail.com

Bug#727708: call for votes on default Linux init system for jessie

[Anthony Towns]

On 28 January 2014 21:39, Ian Jackson ijack...@chiark.greenend.org.uk wrote:
 I don't want to pass a resolution specifying the default without also
 answering the other two, related, contentious questions:
   Q1: Do we intend to support multiple systems long-term, or do we
   intend to settle on a single system, probably in jessie+1 ?

FWIW, that seems overly prescriptive to me -- if we settle on systemd
now, and as a result upstart stops getting maintained and systemfree
gets written that uses the same config files but only works on FreeBSD
and Hurd, maybe no one will want to maintain multiple init systems
later. Conversely, maybe people get excited about some init system we
don't pick as default for jessie and it becomes really awesome by the
time jessie is out; why would we want to prevent it being available in
Debian even if it's not ready to be default, or doesn't work with
Gnome yet, or whatever?

   Q2: Is it OK for packages to depend on a specific init system as
   pid 1 ?

I don't think that's the right question for the issue(s) at play here.

From what I can tell, the important question isn't whether systemd or
upstart happens to be pid 1, but rather whether certain interfaces
(dbus, logind, potentially others) that are only (currently) provided
by systemd are available on the system.

That would make the question break down into something like:

  Q2a: Is it OK for packages providing init systems to provide other
APIs beyond just the minimum needed for starting/stopping services?

  Q2b: If so, is it OK for packages requiring those APIs (such as
logind) to just depend on the particular init system known to provide
them (eg Depends: systemd)?

There's a third related question that I don't think is particularly
crucial, regarding the different ways of telling different init
systems about your service:

  Q2c: Is it OK for packages to provide a service start/stop
description that is understandable by some but not all available init
systems in Debian?

After Steve's and Russ's comments in [0] and [1], and thinking about
it some more, I'm inclined to think all those questions could
reasonably be dealt with through the policy process, though I still
think some non-binding advice from the tech ctte wouldn't be out of
place.

[0] https://lists.debian.org/debian-ctte/2014/01/msg00382.html
[1] https://lists.debian.org/debian-ctte/2014/01/msg00383.html

  Q2: Requiring specific init is forbidden

Note that this answer would preclude providing a package designed to,
say, duplicate aj's environment exactly, because it's awesome and all
his friends want to just be able to apt-get install it and be just as
cool as aj is. I don't think that's a win.

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
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_lcxhqy5ubbtm6s9pujagdos_uxkjqbd9lxhmrvfstr-...@mail.gmail.com

Re: call for votes on default Linux init system for jessie

[Anthony Towns]

On 28 January 2014 08:44, Bdale Garbee bd...@gag.com wrote:
 Don Armstrong d...@debian.org writes:
 It's unclear what the best approach is to do that.  Can/should I
 terminate the vote prematurely, or does it have to run to conclusion?

I don't think you can unilaterally terminate a vote, but the vote can
end early if the outcome is no longer in doubt. If there were an two
votes in addition to Ian's and Don's ranking Further Discussion above
all other options, that would be the case. (Four of eight votes with
FD ranked above all other options would exclude all other options in
step A.6.3 of the vote tallying, leaving FD the only undropped otpion
in A.6.4, and hence the winner)

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
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_lcvumdth5ctz_7sqefu1ctr7utwu5kbdnpksovxvosp...@mail.gmail.com

Bug#727708: On diversity

[Anthony Towns]

On 20 January 2014 14:29, Russ Allbery r...@debian.org wrote:
 Steve Langasek vor...@debian.org writes:
 On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote:
 For my part I think this is generally a good idea, but I have the
 impression that at least Russ would be strongly opposed to this because
 it's too prescriptive.  Probably not much sense in fleshing out such a
 resolution if there's not a consensus for it.
 I think this is all great work to do.  I'm just dubious about enforcing it
 with a technical committee decision.  This is the sort of thing that I was
 expecting to need to do on the Policy front once we have a decision.  I
 think that's the right forum for drilling into the details.

So I wondered what it might look like to say the same thing in a
minimally prescriptive way. Not even going to try guessing if this is
anywhere sufficient as far as Russ is concerned -- I'm not claiming to
know where Russ might draw the line on that topic. I've also added
some minimal tech ctte-esque boiler plate; I'm sure Ian could do
better.

---
The tech ctte determines as follows:

  [non-essential-init] In order to allow Debian users and developers
to easily design, test and deploy alternative init systems both now
and in the future, no init system in Debian should be provided via an
Essential:yes package.

  [default-init] Having examined the features and bugs of the various
init systems packaged for Debian, the default init system for jessie
for Linux architectures shall be {OpenRC | systemd | upstart |
determined by a GR}.

The tech ctte further offers the following advice to maintainers:

  [logind] The systemd/logind API provided by systemd and documented
on the freedesktop API will be important for a number of packages, and
that API should be made available within Debian for users of init
systems other than systemd. The various non-systemd init system
maintainers are encouraged to work with the systemd maintainers and
upstream to limit the code duplication that may result from this, and
to ensure enhancements and bug fixes are as widely available as
practical (both within Debian for different inits/architectures and
upstream). The maintainers involved should work through the policy
process to establish a virtual package for this API if needed.

  [required-init] In order to avoid users mistakenly removing all init
systems from their machine, we recommend the init maintainers
establish a virtual package (eg, init-system) that all init systems
in Debian both provide and conflict with, and that an Essential:yes
package depend on that virtual package. This should be undertaken
using the normal policy process.

  [init-minimal-compatability] In order to make it simple for packages
to work with different available init systems, a simple means of
providing a startup script/configuration that is understood by all
Debian init systems should be documented in policy as a requirement
for for packages providing the init system virtual package. This may
be providing a sysvinit style script and adding it via update-rc.d for
instance. This method may be assumed to always be available if the
[required-init] advice is followed, and thus packages can avoid a
dependency on the virtual package.

  [init-crossgrades] In order to provide a good user experience when
switching init systems, maintainers of init systems other than the
default should test converting both to and from their init system, and
that the system is able to correctly shutdown and restart after
transitions to different init systems.

  [init-related-patches] Maintainers should accept non-intrusive
patches to provide enhanced support for init systems (both for the
default init and other inits included in Debian). Patches may be
considered intrusive by the maintainer if they introduce additional
dependencies or significant patches to code that are not accepted
upstream. Patches that merely add files to the package or provide
extra code to maintainer scripts should generally not be considered
intrusive. Where a reasonable amount of time has been given to the
maintainer to review proposed patches via the BTS, and no objection
has been raised, a NMU to incorporate the patch is appropriate.

  [cgroups] Maintainers should be aware cgroups is a Linux-only
feature; if their package requires the use of cgroups to be usable it
should be configured to not build for non-Linux architectures. Where
cgroups support is a compile-time feature, it should generally be
supported on Linux architectures, and disabled on non-Linux
architectures, for the same reason.

  [systemd-portability] Maintainers should be aware systemd relies
heavily on cgroups and potentially other Linux-only features, and thus
should be aware that unless/until this changes, requiring use of a
systemd unit file for startup will likewise require their package to
be configured to not build for non-Linux architectures.
---

I think the [non-essential-init] and any of the four options for
[default

Bug#727708: On diversity

[Anthony Towns]

On 17 January 2014 03:52, Ian Jackson ijack...@chiark.greenend.org.uk wrote:
 What is Debian ?  In one respect, Debian is an operating system.  And
 of course in another respect Debian is a community.
 * Debian is a forum for cooperation and technical development.
 * Debian, as a piece of software, tries to be all things to all
   people (within reason).

So the original message referring this to the tech ctte was about
deciding on the default init system. Honestly, that seems like the
least interesting part of this discussion to me; and I wonder if the
ctte shouldn't consider answering some different, but related question
that more directly addresses issues like packages depending on cgroups
or logind. Something like:

 a) maintainers should be aware cgroups is a Linux-only feature; if
their package requires the use of cgroups to be usable it should be
configured to not build for non-Linux architectures.

 b) maintainers should be aware systemd relies heavily on cgroups, and
thus should be aware that requiring use of a systemd unit file for
startup will likewise require their package to be configured to not
build for non-Linux architectures.

 c) logind or an equivalent service implementing the freedesktop.org
systemd/logind api should be available under all supported init
systems and architectures in Debian. It should be provided via a
virtual package fdo-logind and packages (such as desktop managers)
expecting logind to be available should Depend on fdo-logind

 d) [are packages likely to start depending on
localed/hostnamed/timedated/machined/??? in the same way as logind
such that it would need to be available outside systemd for upstart to
be a useful init?]

 e) no init system in Debian should be marked as Essential:yes, or
depended upon by any Essential:yes or Priority:required package except
through the virtual package init-system. All init packages should
Provide: and Conflict: init-system. base-files should Depend:
init-system.

 f) all init systems Providing the init-system virtual package must
support packages providing sysv style init scripts via update-rc.d.

 g) packages that do not work with sysv must declare a Depends: on the
init systems they do support, eg upstart | systemd

 h) having examined the various current available init systems, the
tech ctte considers [OpenRC] to be the best available init
implementation at present, and so determines that the relevant
maintainers, including the installer team and ftpmasters se it as the
default init-system for new Debian installs. This decision becomes
vacant should a general resolution specifying an alternative init
system as the default pass with a simple majority prior to jessie's
release.

 i) all these decisions revert to advisory opinions after the release
of jessie, and may then be changed by the usual methods of consensus
driven policy development, and maintainer decisions, or by referring
the issue to the tech ctte again.

I think (a) and (b) are pretty non-controversial. (c) and (d) are
required if we want to deal with new GNOME stuff and anything other
than systemd probably, and don't seem very hard to either do or
document. (e), (f) and (g) seem like a fairly straightforward of
allowing for multiple init systems in Debian. I think something like
(i) might be a good way of sunsetting tech ctte decisions so if
there's an actual consensus in future, there's no need to get a
pro-forma vote from the ctte to make changes in future. YMMV of
course.

In my ideal world, the tech ctte would work out good answers to all
the bits above except (h) and get those added to policy, then propose
various options for (h) as a GR themselves, with well argued
rationales for each of the options along the lines of what's already
been posted to the list. How much that conflicts with the No detailed
design work portion of the ctte's mission statement is up for debate
though. Why you'd have a *technical* committee and forbid them making
sure the details are right doesn't make a lot of sense to me though.
Fortunately I'm not on the tech ctte list, so I can look into details
all I like ;)

Cheers,
aj


-- 
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_lcxtps1xdy6owf6eqwz5jwujccj0sio8kadakqwv2k8...@mail.gmail.com

Bug#727708: On diversity

[Anthony Towns]

On 20 January 2014 14:29, Russ Allbery r...@debian.org wrote:
 Steve Langasek vor...@debian.org writes:
 On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote:
 I think (a) and (b) are pretty non-controversial. (c) and (d) are
 required if we want to deal with new GNOME stuff and anything other
 than systemd probably, and don't seem very hard to either do or
 document. (e), (f) and (g) seem like a fairly straightforward of
 allowing for multiple init systems in Debian. I think something like
 (i) might be a good way of sunsetting tech ctte decisions so if there's
 an actual consensus in future, there's no need to get a pro-forma vote
 from the ctte to make changes in future. YMMV of course.
 For my part I think this is generally a good idea, but I have the
 impression that at least Russ would be strongly opposed to this because
 it's too prescriptive.  Probably not much sense in fleshing out such a
 resolution if there's not a consensus for it.
 I think this is all great work to do.  I'm just dubious about enforcing it
 with a technical committee decision.  This is the sort of thing that I was
 expecting to need to do on the Policy front once we have a decision.  I
 think that's the right forum for drilling into the details.

Personally, I'm still not really clear on where the ctte is leaning
wrt supporting multiple init systems; if the idea is that [OpenRC]
becomes the new default, and declares itself as Essential:yes, and the
Debian maintainers of [systemd and upstart] say okay, I give up, I'm
going to work on [OpenRC] now, it doesn't seem like there'd be much
need for policy work. Obviously, switch the init systems around as
appropriate. I believe I've seen comments along those lines from both
systemd and upstart maintainers should upstart or systemd be chosen as
the default, but maybe I'm mistaken. I'm pretty sure I've seen
numerous comments that Debian should only support one init system (per
kernel, at any rate), which would make the Essential:yes part make
sense. To me that seems like it would be a bad outcome (even if we
adopted upstart everywhere and abandoned sysvrc, systemd and openrc
entirely; it would still make it unduly difficult to experiment with
the next next-generation init systems in a Debian environment). I'd
expect the tech ctte's decision to be prescriptive enough that it's
clear what non-default-init-system maintainers and users should do,
post-apocalypse, I guess.

On a practical note, having a quick look at the policy list, it seems
like that's not actually crazy active/responsive at present either
(long overdue updates to menu policy and triggers documentation are
the only topics this month?), so relying on -policy for detail work
doesn't seem like it would actually work out in a timely fashion?

Honestly, I was a bit surprised that Steve thinks the above's a good
idea, given I wrote it from the (my) perspective of wanting to support
multiple init systems within Debian; and my understanding is his
opinion is that that's kind-of nuts. I think that's pretty great
through, especially in that it affirms my naive faith that drilling
down into technical details is a good way of achieving consensus
amongst people with very different goals and political/philosophical
stances... ;)

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
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_lcw-vs6mi7qk-gvaqayqsu49dqbgojpa79gwhzbm6jt...@mail.gmail.com

Bug#727708: init system thoughts

[Anthony Towns]

On 31 December 2013 12:55, Colin Watson cjwat...@debian.org wrote:
 The criticisms of Upstart's event model in the systemd position
 statement simply do not make sense to me.  Events model how things
 actually happen in reality; dependencies are artificial constructions on
 top of them, and making them work requires the plethora of different
 directives in systemd (e.g. Wants, which is sort of a non-depending
 dependency) to avoid blocking the boot process on a single failing
 service.

Riffing off this more than replying to it.

I tend to think dependencies and events are both useful ways of
describing when to start up parts of the system. In particular, it
seems like:

 - when a network is connected, start web server
 - when a usb disk is connected, mount it
 - when a VPN is started, sync various things

are best described by an event model, while:

 - in order to run GNOME, logind must be started
 - in order to run logind, dbus must be available
 - as part of making the system ready for a user, network-manager
should be running

make the most sense when described by dependencies. In particular,
in many of those cases, the reverse might not be true: For debugging,
I might want to start the web server manually without connecting the
network; or I might want logind running without GNOME, or
network-manager running without the other parts of my desktop
environment.

Events and dependencies aren't that different; an event essentially
lets a service X say that:

  whenever Y happens, X happens
  whenever Y happens, X stops happening

while a (systemd'ish) dependency says either:

  when X happens, Y happens as well[X Requires: Y]
  before X happens, Y happens as well   [X Requires: Y, After: Y]
  after X happens, Y happens as well [X Requires: Y, Before: Y]

(with Wants and Requisite and Overridable variants as well; also
RequiredBy and WantedBy variants)

If you look at Y, there are a few phases it could go through:

no-Y
Y-starts-starting
Y-started
Y-begins-ending
no-Y

If you wanted to emulate upstart events with dependencies, you'd need
to do four things, I think:

* create a dummy Y-started-event unit [network-is-available,
usb-is-available]
* invoke systemctl start Y-started-event when Y is finished starting
* invoke systemctl stop Y-started-event when Y begins ending
* add RequiredBy: Y-started-event and PartOf: Y-started-event
to X's unit file

That seems reasonably straight forward to me? If the event is
something systemd already knows about, you might only need to do
something equivalent to the last step. I don't think invoking
systemctl start/stop is any better or worse than whatever would be
needed to notify upstart of the same events.

To emulate systemd dependencies in an event model (ie, X depends on
Y), you'd need to do either:

* change Y's job to say start on starting X
* add stop on stopping Y to X's job description

or

* add a pre-start script to X in order to start Y first
* add stop on stopping Y to X's job description

The latter looks like it's the documented way of doing things. Neither
of those seem particularly great -- I think that's due to upstart not
letting you reverse event descriptions in the same way that systemd
has Requires/RequiredBy statements. If you could say:

   * on starting start Y
   * stop on stopping Y

in X's job description, by contrast, I think that would be a fine way
of declaring a dependency from X to Y without leaving the event
model. Not having a simple way of specifying this sort of dependency
seems pretty weak on upstart's behalf.

It would probably also be nice to have a way of saying when a new
network comes up, reload/refresh service X -- so that it could bind
to new ports or whatever even if it was already running; that seems
like the sort of thing that would be easier to specify in an event
model (on new-network-interface-started reload or start), than in a
dependency model.

Cheers,
aj


-- 
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_LCUGaM6JS8Ec-73z30+_h8yW+HqSqfqVvHVh=ykpqn+...@mail.gmail.com

Bug#727708: Bits from linux.conf.au

[Anthony Towns]

On 15 January 2014 20:36, Martin Pitt mp...@debian.org wrote:
 It's not realistic for a maintainer to continuously test three init
 systems;

It's not realistic for a maintainer to continuously test against 13
architectures (including three different kernel trees) either. So we
don't do that and instead let maintainers make their best effort when
packaging, expect them to test locally, and then rely on porters and
users to report bugs when there are problems.

 it's not realistic for a porter to continously test startup
 scripts for thousands of packages.

It's reasonable to semi-continuously test installation scripts for
thousands of packages -- that's what piuparts does, and we have
sponsored cloud resources to support that. It seems like that would be
fairly straightforward to duplicate for testing packages with
alternative init systems.

Cheers,
aj


-- 
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_lcu0jw2cupw7bynnq2laxhdrzc4hbj8ouot9o9qpdfe...@mail.gmail.com

Bug#727708: init system discussion status

[Anthony Towns]

On Jan 5, 2014 2:39 AM, Russ Allbery r...@debian.org wrote:
 I'm doubtful that either of us are going to convince the other on this
 point.  I don't consider it comparable to the other examples you're
 citing, and I think it's inobvious that raise(SIGSTOP) is a good technical
 choice.  Simple, yes, but that's not the same thing.

How hard would it be to write an external wrapper that converts the systemd
style socket activation to the SIGSTOP  protocol (for upstart invoking a
systemd compatible daemon)? Or to add support to start-stop-daemon for both
protocols so a reliable sysv style script is trivial for more modern
daemons?

Cheers,
aj

Bug#727708: init system discussion status

[Anthony Towns]

On Jan 5, 2014 10:40 AM, Russ Allbery r...@debian.org wrote:
 Anthony Towns a...@erisian.com.au writes:
  How hard would it be to write an external wrapper that converts the
  systemd style socket activation to the SIGSTOP protocol (for upstart
  invoking a systemd compatible daemon)?

On second thoughts, I think I meant this the other way around - systemd
invoking an upstart compatible daemon, since it seems like upstart is more
likely to support the systemd socket activation protocol than systemd is to
support upstart's SIGSTOP  protocol.

 The wrapper could fork
 and then exec the daemon in the *parent*, and have the *child* listen for
 the notification message and then kill(SIGSTOP) its parent and immediately
 exit.  I wonder if that would actually work

Nice :)

Cheers,
aj

Bug#727708: init system other points, and conclusion

[Anthony Towns]

  xfce4  16800 0 0 0 16800
(Debian Xfce Maintainers)

Personally, I run xfce because it works best for me; I wouldn't give
even a moments thought to running Gnome because by doing so I might
find and fix some bugs that would help other folks. I'd apply the same
argument to systemd/upstart, personally. To me, that seems like the
best way to let the most beneficial technology win out.

It seems to me like what should the default init system be? is a
very different question depending on whether other init systems are
also well supported. I get the impression that you think there's not
much chance of other init systems working well, while what I've read
from Russ and Ian seems to indicate that it ought to at least be
feasible. I can certainly understand that multiple init systems isn't
a winning idea from the point of view Ubuntu (or Red Hat) would take
when putting together a distribution, but I would have thought it was
something Debian could/should/would manage.

Forced to make a choice, should Debian go for smoother/tighter
integration between apps, or more choice for users/sysadmins? I'd
expect Debian to choose the latter; though Ubuntu, Red Hat and
possibly Fedora might choose the former.

Cheers,
a por que no los dos? j

-- 
Anthony Towns a...@erisian.com.au
Not speaking for my employer...


-- 
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_lcuwkje-hxq85kj_11ov_3o0deknct6q86slkjf7oz0...@mail.gmail.com

Bug#727708: loose ends for init system decision

[Anthony Towns]

Okay, let's see how replying to a mail on my phone while in flight mode
goes. Apologies in advance for formatting, quoting and vocabulary issues.

On Dec 31, 2013 4:48 AM, Russ Allbery r...@debian.org wrote:

 2. Impact of Multiple Init Systems
 Obviously, the ideal situation for project-wide integration and support,
 and for Debian's ability to make full use of the capabilities of new init
 systems, is for all of Debian's ports to be running the same init system.

So, reading this (and trimming loss of stuff that makes sense) I wonder if
it's worth stepping back and considering what happens when a package
doesn't support /any/ init system. The answer I think is that the sysadmin
sighs, adds their own configuration, and maybe thinks well at least I
didn't have to compile it, I guess.

That still sucks compared to the alternative of typing apt-get install
and having it just start working, of course.

 Attempting to support multiple init systems has several obvious drawbacks:

 * Packages will either be limited by the functionality of the least
   capable init system or will behave differently (and have to be
   configured differently) on different ports.

I think the Debian way of dealing with multiple init systems would be to
provide a compatibility layer for the most common packaging and admin
tasks, and allowing packages to provide fancier integration where
appropriate. I'm thinking of things like newaliases and sendmail, and
cgi-bin and apache modules, I guess. Probably that's already covered for
init systems via sysvinit compatibility and update-rc.d. Maybe there's a
missing tool that could be written to let you set init specific
configuration somehow, which would change /etc/default for sysv and other
files for upstart/systemd.

It seems like there's maybe three separate questions then: what init system
gets used by default, what work gets done to make that experience
different/better than everything just having upstart or systemd pretending
to be sysvinit, and what's the experience of maintaining packages to
support secondary init systems and using secondary init systems on a Debian
system?

(Personally, I think a gr would be better for choosing the default then
having the tech ctte decide that issue, but whatever)

Based on what I've read, it seems like the ideas floating around amount to:

- if systemd is default: there would be a release goal to include systemd
configs added to packages and to get daemons converted to support socket
activation. Maybe other stuff too? As far as maintaining sysvinit, openrc
or upstart systemd goes, you'd just have to get upstart configs written and
packaged, and accept that there's an unused systemd library on your system.
Multiple inits must be supported to some extent, since systemd isn't
available on ports and that isn't likely to change apparently.

- upstart is default, other inits are supported: pull in Ubuntu configs for
upstart for various packages. If systemd socket stuff is allowed, dummy
library will probably be on most systems, if not, systemd in Debian won't
be very interesting.

- upstart is default and only init supported by Debian. Same support work
for Jessie, except any ports that want to stick around need to get upstart
enabled.

I don't think the latter is really the Debian way - better to have the
choice left in the users' hand if feasible, but it's likely a lot easier to
get some impressive results that way. I think the ideal page for tradeoffs
like that is in derivatives like Ubuntu personally.

 I believe Debian should take this path forward:
 1. We should select a new init system for jessie, either systemd or
upstart.  Support for that init system should be release-critical, but
only in the sense that the daemon works properly under that init
system.  In other words, use of the sysvinit compatibility of either
init system is acceptable support for jessie.

So that would mean switching the init system, and decorating anything that
breaks as a result RC buggy. Seems sensible.

 2. All packages providing init scripts must continue to support sysvinit
scripts through the jessie release.  Such support will continue to be
release-critical.

I'm not sure this makes sense, though. If someone packages a new daemon
that works fine with systemd and upstart, I don't see why it shouldn't get
released just because it doesn't work with two secondary init systems.
Filling a wishlist bug with a patch and doing an NMU seem like they'd be
sufficient here.

As far as upgrades go, if the idea is that systemd is the way to go for
Jessie it seems to me that an update would by default switch you from
sysvinit to systemd (likewise for upstart) - I don't think it makes much
sense to do systemd/upstart for new installs but leave upgrades with sysv
until Jessie+1.

 7. After jessie, functionality between systems running the primary Linux
init system and other init systems (including non-Linux ports) should
be allowed to drift.  In other 

Bug#699808: tech-ctte: syslinux vs the wheezy release

[Anthony Towns]

On 5 February 2013 22:48, Julien Cristau jcris...@debian.org wrote:
 Package: tech-ctte

 - the debian-installer source package, which builds the installer images
   for debian's releases, build-depends on syslinux
 - the release freeze for wheezy started in June 2012, and is now in its
   final stages
 - one of the prerequisites for the release is a release candidate for
   the installer
 - the syslinux maintainer uploaded new upstream versions of his package
   to unstable, which were unsuitable for wheezy, in November 2012, and
   again at the end of January 2013
 - the latest of these uploads breaks the installer, [...]

Isn't this a rationale for d-i to use the stable builds of syslinux
present in testing (or potentially testing-proposed-updates) rather
than unstable?

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
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_LCWkAk+1Cz70xf426wrVoV=hdswsbzteuv8cbteqq-u...@mail.gmail.com

Re: Draft GR for supermajority fix

[Anthony Towns]

On Fri, Jul 13, 2012 at 12:41 PM, Ian Jackson
ijack...@chiark.greenend.org.uk wrote:
 Anthony Towns writes (Re: Draft GR for supermajority fix):

 How about this.  I have dropped your change to the cite at the end
 of the Standard Resolution Procedure.

Looks good to me.

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
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_LCXNTn-4LspB8NvOJV=roz9ksaq7nubvmfixs_7z5oz...@mail.gmail.com

Re: Draft GR for supermajority fix

[Anthony Towns]

On Mon, Jul 9, 2012 at 2:02 PM, Kurt Roeckx k...@roeckx.be 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 a...@erisian.com.au


-- 
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

chiark -ctte copies

[Anthony Towns]

Hi,

I'm still getting duplicates of the -ctte lists via:

Received: from chiark.greenend.org.uk ([212.13.197.229])
by azure.erisian.com.au with esmtp (Exim 4.63 #1 (Debian))
id 1LLRLI-0008BV-QK
for a...@erisian.com.au; Sat, 10 Jan 2009 10:04:45 +1000
Received: from liszt.debian.org ([82.195.75.100])
by chiark.greenend.org.uk (Debian Exim 3.36 #1) with esmtp
(return-path
bounce-debian-ctte=ijackson+debian-ctte=chiark.greenend.org...@lists.deb
ian.org) id 1LLRLG-0001R1-00 for
ijackson+debian-c...@chiark.greenend.org.uk; Sat, 10 Jan 2009 00:04:42
+

I think that was to make the -ctte-private list work or something, so I've
just been ignoring them, but it'd be nice if they could stop now, pls. :)

Cheers,
aj



signature.asc
Description: Digital signature

Bug#503814: foo2zjs

[Anthony Towns]

On Fri, Oct 31, 2008 at 03:52:31PM +0100, Andreas Barth wrote:
 1. Currently, the submitter claims that the bug is serious, the
 maintainer don't think so, and there is no decision by the release team
 yet. So the current state of the bug isn't serious, but important. 

ie, the views (on serious severity) are prioritised as:

- submitter's (default)
- maintainer's (can override submitter, and in this case does)
- release team's (can override maintainer and submitter)
- tech-ctte (can override all three of the above)
- general resolution (likewise)

 2.  As per constitution, we (the tech ctte) only makes decision as last
 resort. So currently, the next step would be for anyone who disagrees
 with this bug not being release critical to ask the release team to
 review the decision and maybe overrule it.

I'm not sure I'd want the release team to be able to stop the tech-ctte
from being involved simply by not making a decision, so I'm not sure I
agree with this precisely. But in the general case, yes, I'd rather see
the release team making the call on this.

 tech ctte members, any opinion from you on that?

Basically, +1.

On a technical level, it seems to me there's two aspects:

   (1) can a package in main include a script that gets stuff from some
   random website really be considered DFSG-free/policy-compliant?

   (2) should we make sure that the stuff on the random website is also
   available from somewhere in Debian, in case the random website gets
   shut down, etc?

(1) seems to be resolved as per Andi's comments, but I kind-of think
(2) is actually the more important issue, and that the stuff getting
downloaded should probably be packaged for non-free and possibly volatile,
in order to remove the external dependency. The package in main would
then get a Suggests: foo2zjs-nonfree-drivers, and if the script gets
moved to contrib, that could then become Suggests: foo2zjs-nf-d |
foo2zj-nf-d-getter-script. That assumes someones willing to do the
legwork of packaging the drivers, of course, which might require
negotiating permission to redistribute them from whoever owns them.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Code reformatting

[Anthony Towns]

On Tue, Mar 11, 2008 at 04:14:45PM -0700, Steve Langasek wrote:
 Because this is being done *in lieu of* merging the triggers branch, with
 the result that the triggers branch becomes harder to merge afterwards.

The triggers branch is already difficult to merge because it has numerous
unrelated changes.

 I agree with Ian that this is a bad thing.  I can't fathom why Guillem is
 making changes like this while the triggers merge is outstanding, and I
 agree with Ian that it should stop.

From at least August last year, the triggers branch has had significant
stylistic changes compared to the dpkg codebase.

http://lists.debian.org/debian-dpkg/2007/08/msg00014.html

  As it's in a vcs, I don't see why they need to stop doing that as these
  commits on code reformatting can easily be reverted, no?
 They can be - but isn't that counterproductive for everyone involved?

Arguing about code style certainly seems counterproductive for everyone
involved.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical wish

[Anthony Towns]

On Tue, Dec 18, 2007 at 12:24:21PM -0500, Noah Meyerhans wrote:
 This is done.  Steffani now has interface eth0.64 with address 18.24.0.11

Hrm, if you had security.debian.org pointing at:

 18.24.0.11
 212.211.132.032
 212.211.132.250

The rule9-prediction scripts says you get:

000.000.000.000-127.255.255.255: steffani
128.000.000.000-255.255.255.255: villa and/or lobos

and the previous maths would predict about:

steffani:  13.53 MB/s  (down from 14.58 MB/s)
villa:  7.53 MB/s  (up from 5.33 MB/s)
lobos:  3.77 MB/s  (down from 4.92 MB/s)

If you add 18.24.0.11 to the round-robin twice (ie, steffani, villa,
steffani, lobos instead of steffani, villa, lobos), you should get a more
even balance between villa and lobos (about 5.65 MB/s each). Leaving
them unbalanced allows for more deductions from the maths though (in
particular the ability to estimate how many MB/s are due to hosts that
just do pure round-robin).

Having both steffani's addresses in there would (presumably) give steffani
23.60 MB/s and villa and lobos only 1.23 MB/s combined.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical wish

[Anthony Towns]

On Tue, Dec 18, 2007 at 03:35:51PM +0100, Josip Rodin wrote:
 On Mon, Dec 17, 2007 at 07:51:18PM +0100, Martin Schulze wrote:
   I've asked DSA for server-status already, and mentioned the logs too,
   we'll see (they haven't replied yet).
  Server status is configured on localhost.
 OK, so I started measuring that too, and the rates for the last half a day
 or so are:
 * villa: 20.4 rps, 6.18 Mbps
 * lobos: 18.9 rps, 6.23 Mbps
 * steffani: 40.0 rps, 15.92 Mbps
 The ratios for both parameters are matching the general bandwidth ratios,
 so the measurements should be correct.

As of, umm, 2007-12-18 08:30 UTC (about 20 hours ago), testing users
should be starting to hit each mirror equally. So for future numbers,
we should have a noticable change which should result in all the testing
users assigned to classes B and C appearing in class A.

The numbers so far have gone:

villa: 4.29 (19%) -  5.33 (21%) -  6.18 (22%)
lobos: 3.91 (17%) -  4.92 (20%) -  6.23 (22%)
steffani: 14.86 (64%) - 14.58 (59%) - 15.92 (56%)

The calculations give:

A   = 18.84 MB/s (67%)
B   =  9.64 MB/s (34%)
C-F = -0.15 MB/s (-1%)

That's obviously a pretty odd outcome for C-F, and is due to lobos
getting more traffic than villa, which shouldn't be happening according
to RR+rule9. I guess means that the random factors amongst about 30% of
hosts (1/3rd of the hosts in class A/B) are playing a bigger role than
the entirety of class C (about 5% of hosts at last estimate), ie, we
have an random noise factor of about 17% (about 6.51 MB/s in total)...
That's not unreasonable given the usage patterns for security.d.o,
though I was hoping they'd cancel out better :(

Working with requests rather than b/w, which will have noise due to the
number of packages needing an update rather than the total size of the
packages and Packages files needing an update, gives:

A   = 52.2 rps (66%)
B   = 22.6 rps (28%) 
C-F =  4.5 rps ( 6%)

which is closer to what I'd expect given previous estimates, though still
notably different to the earlier 55%/40%/5% split based on bandwidth. Note
that A included all unstable users who'd upgraded in the past week or so,
as well as 0.0.0.0-127.255.255.255 hosts. In future it will include all
testing users who've upgraded since the 18th UTC, up until the DNS change.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical wish

[Anthony Towns]

On Sun, Dec 16, 2007 at 03:45:37AM +0100, Josip Rodin wrote:
 After around 11 hours, we've had:
 * villa 4.29 MB/s
 * lobos 3.91 MB/s
 * steffani 14.86 MB/s

The rule9 prediction was:

A: 000.000.000.000-127.255.255.255: steffani, villa, lobos
B: 128.000.000.000-191.255.255.255: steffani
C: 192.000.000.000-212.211.131.255: villa, lobos
D: 212.211.132.000-212.211.132.127: villa
E: 212.211.132.128-212.211.132.255: lobos
F: 212.211.133.000-255.255.255.255: villa, lobos

Class A is pure round-robin, so we can ignore rule9 and assign 1/3 of its
traffic to each host.

The difference between villa and lobos is aiui due not only to the difference
between the D and E IP ranges, but also because the round-robin ordering of
the hosts is [lobos, steffani, villa], which means that since rule9 happens
after round-robin, you get orderings:

lobos, steffani, villa - [lobos, villa], steffani
steffani, villa, lobos - [villa, lobos], steffani
villa, lobos, steffani - [villa, lobos], steffani

A/3 + B   = 14.86 MB/s (steffani)
A/3 + 2C/3 + 2F/3 + D = 4.29 MB/s  (villa)
A/3 + C/3 + F/3 + E   = 3.91 MB/s  (lobos)

If you assumethe 212.211.132.0/24 traffic is negligible, and thus D = E = 0,
then subtracting lobos from villa gives:

   C/3 + F/3 = 4.29 MB/s - 3.91 MB/s = 0.38 MB/s

And thus filling in for lobos, we get A/3 = 3.91 MB/s - 0.38 MB/s =
3.53 MB/s.

Going back to steffani, that gives B = 14.86 MB/s - 3.53 MB/s = 11.33 MB/s,
and we thus have:

A = 10.59 MB/s
B = 11.33 MB/s
C + F =  1.14 MB/s
D =  0MB/s (by assumption)
E =  0MB/s (by assumption)

Which gives us 23.06 MB/s which was the total of what we started with, yay.

Note that 192.168.*.* addresses are in class C, so can only possibly make
up just under 5% of our traffic, which seems pretty negligible. 10.*.*.*
addresses are in class A, and 172.16... class addresses are in class B. I
would've thought there wouldn't be significantly more of those than for
the 192.168.*.* private addresses though.

Anyway, hope that's of some use.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical wish

[Anthony Towns]

On Sat, Dec 15, 2007 at 03:43:22PM +0100, Josip Rodin wrote:
 On Sat, Dec 15, 2007 at 03:38:01PM +0100, Josip Rodin wrote:
  Steve pointed me to [...]
 BTW, if anyone reading has some time to do the math again (hi aj :)

Hrm. How do you generalise it?

...

Ah, like that. Attached.

$ ./rule9-prediction.py ftp.us.debian.org
000.000.000.000-063.255.255.255: 035.009.037.225
064.000.000.000-127.255.255.255: 064.050.236.052
128.000.000.000-191.255.255.255: 128.030.002.036
192.000.000.000-255.255.255.255: 204.152.191.039

$ ./rule9-prediction.py security.debian.org
000.000.000.000-127.255.255.255: 128.031.000.036, 212.211.132.032, 
 212.211.132.250
128.000.000.000-191.255.255.255: 128.031.000.036
192.000.000.000-212.211.131.255: 212.211.132.032, 212.211.132.250
212.211.132.000-212.211.132.127: 212.211.132.032
212.211.132.128-212.211.132.255: 212.211.132.250
212.211.133.000-255.255.255.255: 212.211.132.032, 212.211.132.250

You can specify multiple addresses, either by name or IP. If you get
non-IPv4 addresses it won't work though.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical wish

[Anthony Towns]

On Sun, Dec 16, 2007 at 06:07:24PM +1000, Anthony Towns wrote:
 Ah, like that. Attached.
 $ ./rule9-prediction.py ftp.us.debian.org

No, really.

Cheers,
aj

#!/usr/bin/env python

import socket, sys

def ip2bits(ip):
return .join(
[ .join(
		[ (%d % (int(x*(2**-y)) % 2)) for y in range(7,-1,-1) ] )
for x in [ int(x,10) for x in ip.split(.) ] ] )

def bits2ip(bits):
return ..join([ %03d % (int(bits[x*8:x*8+8],2)) for x in range(4) ])

def iprange(prefix):
lo = bits2ip( (prefix + 0*32)[:32] )
hi = bits2ip( (prefix + 1*32)[:32] )
if hi == 255.255.255.255:
  nx = 
else:
  nx = bits2ip( (prefix[:prefix.rfind(0)] + 1 + 0 * 31)[:32] )
return (lo, hi, nx)

ips = []
for arg in sys.argv[1:]:
ips.extend( [ (x[4][0], ip2bits(x[4][0]))
		 for x in socket.getaddrinfo(arg, http) ] )
ips.sort( lambda x,y: cmp(x[1], y[1]) )

if ips == []:
print Usage: %s host|address host|address... % sys.argv[0]
sys.exit(1)

working = [ (, [b for ip,b in ips]) ]
result = []
while len(working)  0:
newworking = []
for (prefix, ips) in working:
if len(ips) == 1: 
result.append( (prefix, ips) )
continue
prefixL = prefix + 0
prefixR = prefix + 1
ipsL = []
ipsR = []
for ip in ips:
if ip.startswith(prefixL): 
   ipsL.append(ip)
else:
   ipsR.append(ip)

if ipsL == []:
result.append( (prefixL, ips) )
else:
newworking.append( (prefixL, ipsL) )

if ipsR == []:
result.append( (prefixR, ips) )
else:
newworking.append( (prefixR, ipsR) )
working = newworking 

result.sort(lambda x,y: cmp(x[0], y[0]))

prefix, ips = result[0]
lo, hi, nx = iprange(prefix)
for p2, ips2 in result[1:]:
l2, h2, n2 = iprange(p2)
if nx != l2:
print OUT OF ORDER
sys.exit(1)
if ips != ips2:
print %15s-%15s: %s % (lo, hi, , .join([bits2ip(b) for b in ips]))
lo, hi, nx, ips = l2, h2, n2, ips2
else:
hi, nx = h2, n2

print %15s-%15s: %s % (lo, hi, , .join([bits2ip(b) for b in ips]))



signature.asc
Description: Digital signature

Re: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical wish

[Anthony Towns]

On Sun, Dec 16, 2007 at 06:28:39PM +1000, Anthony Towns wrote:
 Going back to steffani, that gives B = 14.86 MB/s - 3.53 MB/s = 11.33 MB/s,
 and we thus have:
 A = 10.59 MB/s
 B = 11.33 MB/s
 C + F =  1.14 MB/s
 D =  0MB/s (by assumption)
 E =  0MB/s (by assumption)

Hrm, presuming the change in glibc 2.7-4 worked as expected, all the
users of unstable hitting security.debian.org should be included in
the A count, above. I presume there's a good chance glibc 2.7-4 will
hit testing tomorrow sometime, which will mean testing users in other
categories will get moved into A too, and might result in a noticable
change in the balance.

Cheers,
aj


signature.asc
Description: Digital signature

Re: Call for Votes (getaddrinfo)

[Anthony Towns]

On Sat, Dec 08, 2007 at 10:09:37AM +0100, Peter Palfrader wrote:
   [0] http://lists.debian.org/debian-ctte/2007/09/msg00049.html
 I'm a bit confused by this code or rather its result, mainly because it
 seems that on all the etch hosts I tried it the results are distributed
 (even if not evenly) over the set of IP addresses, yet this discussion
 suggests that etch is affected by the Rule 9 issue.  
 |  [EMAIL PROTECTED]:~$ python
 |  print dict([ (l, k.count(l)) for l in k ])
 | {'144.144.144.144': 66, '64.64.64.64': 67, '160.160.160.160': 66,
 | '224.224.224.224': 134, '208.208.208.208': 67, '96.96.96.96': 67,
 | '112.112.112.112': 66, '128.128.128.128': 67, '176.176.176.176': 67,
 | '80.80.80.80': 66, '48.48.48.48': 67, '192.192.192.192': 66,
 | '16.16.16.16': 67, '32.32.32.32': 67}

That looks like you're getting the 224 address showing up twice, which seems
odd too. On an etch system with a 192.168 address, I get:

python EOF
import socket
k = [ socket.getaddrinfo(rule9.erisian.com.au, http)[0][4][0]   
 for blah in range(1000) ]
print dict([ (l, k.count(l)) for l in k ])
EOF
{'192.192.192.192': 1000}

It's 64 bit, with:

ii  libc6  2.3.6.ds1-13etch4
ii  python 2.4.4-2
ii  python2.4  2.4.4-3

and afaik no special configuration otherwise.

(If rule9 weren't affecting a majority of etch systems, it certainly
wouldn't have been affecting Debian system's choice of OFTC servers in
early 2006 afaics...)

Cheers,
aj



signature.asc
Description: Digital signature

Re: Call for Votes (getaddrinfo)

[Anthony Towns]

On Fri, Dec 07, 2007 at 01:55:28AM -0800, Steve Langasek wrote:
  I haven't seen any concrete reports we could pass on, or any indication
  we're likely to come up with a better mechanism, though, which leaves us
  as doing nothing by default.
 I've previously argued that there are at least two mechanisms that would be
 an improvement:
 - drop rule 9 altogether, passing through the sorting supplied by the DNS
   server (whether that's round-robin, or sorted by some other server-side
   rule)

From my search earlier in this thread, I believe rule9 is specifically
relied upon by one of the RFCs talking about multi-homing in IPv6, though
I'm afraid I don't have a reference. I don't think it's reasonable to
just drop it without some alternative way of addressing:

- stability of results in the face of round-robin, in order to give
  apps repeatable results

- more fine-grained (and use specific) scoping than the
  global/site/local scoping that's already defined

- traffic-path optimising address selection

Of course, those could be addressed by:

- providing apps with an explicit sorting function that will sort
  addresses according to the above requirements, no matter how
  they're obtained
- having apps specify when they want them taken into account
  when asking for address resolution (cf rfc5014)
- having libc's resolver take them into account on instruction
  by the admin
- having the site DNS server take them into account when deciding
  how to order multiple A records
- having the service provider use mechanisms other than DNS
  round-robin to present the right address to whoever's asking

Replacing rule9 with a statement that implementors MAY re-order
addresses according to site policies but SHOULD NOT do so unless
they can do better than random round-robin selection, and providing an
IPV6_PREFER_DST_PREFIXMATCH setsockopt option for applications that desire
the rule9 behaviour would be pretty straightforward and fairly compatible,
afaics. Providing an IPV6_PREFER_DST_STABLE option that ensures a stable
result per-host while still being globally random would be possible too,
I think.

 - apply rule 9 only in the case that the common prefix is longer than the
   prefix length of the natural unit network for the address family (/32
   for IPv6, /22 for IPv4)

AFAICS that doesn't actually achieve anything much over just dropping
the rule.

 Do you disagree with the proposition of one of these being preferable to the
 current behavior?

I don't think I'm informed enough on what's made assumptions relying on
rule9 to get rid of it entirely, and afaics no one else here is actually
any better informed. Which is why I keep complaing about how little
evidence I've seen...

  I could be convinced it's RC, but I've seen precious little *actual*
  impact -- certainly people are surprised by the change in behaviour,
  and it does change traffic characteristics, but ... that seems to be it,
  so far. Where's the actual damage and problems?
 The changed traffic characteristics are certainly damaging, at least
 potentially.  

Come on, there's no such think as certainly damaging, at least
potentially. It's either potentially damaging, or certainly damaging.

 It can have financial consequences for anyone that's invested
 in infrastructure with the expectation that round robin will continue to
 work, and find that they have to choose between completely revamping their
 DNS infrastructure to feed clients targetted results, or renegotiating
 hosting/bandwidth contracts to accomodate client selectivity that's outside
 of the server's control.  

Then it's a good thing that behaviour's documented in a standards-track
RFC so they know what to expect before doing the roll-out. And as far
as I can see, the actual impact in practice has turned out not to be
even serious enough to be able to be demonstrated...

 Obviously in the general case Debian doesn't have
 enough market share to be able to fix this on our own, but that doesn't stop
 us from ensuring that Debian behaves as a good citizen.

Huh? For the case of apt-get we certainly have enough market share to
make a difference; yet we haven't even got to the point of having a
documented problem report for it to fix yet.

 In terms of how the behavior of Debian clients makes a difference, Debian
 systems are certainly the primary consumers of the Debian mirror network.  I
 think that losing a mirror sponsor due to the uneven load distribution, ...

Sure, but where's the evidence that this is even resulting in uneven
load distribution? If ike did crash or similar at some point (which,
personally I can't even verify), where's the evidence that was because
of getaddrinfo behaviour on clients accessing it, and not unrelated
problems on that machine or network?

To give a counter-example: if rule9 behaviour can be relied on, and you're
running host 

Re: Call for Votes (getaddrinfo)

[Anthony Towns]

On Fri, Dec 07, 2007 at 09:17:02PM +0100, Peter Palfrader wrote:
 We had servers that ended up with twice or three times the number of
 users than other servers in the rotation, and explaining it all away
 with well, the network of the less loaded server simply must suck, so
 clients cannot stay connected for long didn't work out all that well.

 Now that I read this thread this Rule 9 thing probably explains it all,
 and assuming I'm right with that there was clear, demonstrable impact.

Do you know when this was? The only data for other OSes we've seen [0]
seems to indicate that most of them don't actually use rule9. Unless
we can assume Debian and Ubuntu users made up a significant proportion
of OFTC users, and that the versions of Debian and Ubuntu in use at the
time implemented rule9.

 [0] http://lists.debian.org/debian-ctte/2007/09/msg00049.html

 In the end OFTC decided to move more intelligence into the nameservers
 and we now have geolocating, load balancing DNS*, courtesy of Luca.

Intelligent load-balancing from the DNS server makes rule9 fairly
redundant of course.

TBH, from the anecdotes I've heard, both here and in relation to
mirrors.kernel.org, I have a nasty suspicion that there's some other
behaviour being implemented by either Windows hosts or some common DNS
proxies that re-orders DNS addresses in a non-rule9 manner, but with
similar or worse resulting biasses.

Cheers,
aj


signature.asc
Description: Digital signature

Re: Call for Votes (getaddrinfo)

[Anthony Towns]

On Thu, Dec 06, 2007 at 01:58:47AM -0800, Steve Langasek wrote:
 I do think that this bug warrants fixing in stable, I just don't agree that
 RCness is the relevant and appropriate standard for whether the TC should
 override a maintainer.  You seem to be ok with overriding the libconfig
 maintainer's choice of source package name, but I haven't seen it suggested
 that the libconfig package needs to be renamed in stable?

The rationale given for overriding the maintainer is that this is a
horrible bug that's breaking Internet servers everywhere, including our
own. I haven't seen any evidence of that, but if it's the case, or at
least the basis for us to overrule the maintainer, then in order to stop
it from happening we should be ensuring it's fixed in stable as well.

It seems to me absolutely irresponsible to say an issue's a blight on
the Internet, and then not worry about what happens for stable. Well,
either that, or dishonest, in that we're not worrying about fixing it in
stable because it isn't a major problem, even though we're saying it is.

If that's not our rationale, the only other one I've seen is essentially
this is daft behaviour that doesn't do any one any good and shouldn't be
in the RFC, which I agree with, but don't think warrants overruling the
maintainer's decision that it's not important enough to warrant changing
the default behaviour versus upstream.

 I'm amenable to including a statement about RCness in the resolution if
 that's relevant to getting it passed, I just don't believe it's necessary
 for getting the bug fixed in etch.

If we're saying this is a major issue that needs to be fixed throughout
Debian, and we trust the maintainers and release team to give that
appropriate priority, without explicitly saying release critical,
that's fine, but TBH I don't see any practical difference between saying
the above and saying this is RC, at all.

I'm pretty sure I dislike the idea of being eager to dive into issues
where we're looking at overruling package maintainers (mixmaster,
libconfig and exim, atm eg) and extremely reluctant to even make
suggestions about release policy. Particularly when there're plenty of
ways of overruling package maintainers (uploading a differently named
version of the same software, NMUs, ftpmaster NEW/REJECT handling,
peer pressure on -devel, QA monitoring and removal requests, policy
guidelines from -policy, RMs setting RC severities, tech-ctte, and GR)
and very few of overruling RM decisions (tech-ctte, GR, and conceivably
DPL redelegation).

 Josip was not the first or only person that I heard say this, but I think
 the other comments were made on IRC.  I'll try to track down some hard data
 on this.  From memory, the server in the http.us.debian.org rotation that
 was being hit out of proportion was ike.egr.msu.edu, but I don't know yet
 that this was confirmed as being a jump in relative traffic as opposed to a
 jump in absolute traffic.  It would be consistent with RFC3484 behavior on
 the part of hosts on 10.x.x.x intranets, though.

Well, okay... but shouldn't it still be happening if that's the case?
Unless we've somehow lost a significant number of 10.0.0.0/8 hosts that
were pointing at ftp/http.us.d.o at that point and now aren't, ike is
still the host that they should be all hitting so demonstrating the
load imbalance caused by 10.0.0.0 hosts should be trivial if we have
any access to ike's logs.

Actually, almost every apt host hitting ike via an address above 64.0.0.0
ought to be a NATed 10.0.0.0/0 host (unless it's being proxied from
a 64.0.0.0 by a 64.0.0.0 address, or has a real IP 64.0.0.0 but is
being NATed to 64.0.0.0 anyway for some reason). If we had logs from
ike, that should be enough to give us an estimate on how many 10.0.0.0
hosts we have (x = real hosts for ike, y = 10.0.0.0 hosts; a = 64.0.0.0
address hitting ike, b = 64.0.0.0 addresses hitting ike; b ~= 3/4y;
a+b = x+y; y ~= 4b/3; x = a+b-y ~= a+b/4; proportion of 10.0.0.0 hosts
to all real addresses ~= y / 4x ~= 4b / (12a+3b)).

At some point ftp.us.d.o was just one host, which could also have
(obviously) caused one host to get more traffic than the others; but I
don't recall when that was, or which host it was though.

Cheers,
aj



signature.asc
Description: Digital signature

Re: RFC3484 s6 rule 9 should not apply

[Anthony Towns]

reassign 438179 tech-ctte
thanks

On Thu, Dec 06, 2007 at 08:11:51PM +, Ian Jackson wrote:
 The Technical Committee has decided as follows:

This is incorrect. The supermajority requirement was not met, see:

http://lists.debian.org/debian-ctte/2007/12/msg00067.html

As such, no decision's been made. The Glibc team may, of course, decide
to change the default behaviour themselves in the meantime while the
ctte continues to go round in circles.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Call for Votes (getaddrinfo)

[Anthony Towns]

On Fri, Dec 07, 2007 at 01:25:29AM +0100, Kurt Roeckx wrote:
  7-day period, which has just expired:
  X F S M Ian, Manoj
  X F M S Andi
  M F AJ
  F defeats S by 4:0, so S is eliminated.
  F defeats M by 3:1, so M is eliminated.
  The remaining non-default option is X.  It has a 3:1 supermajority
  requirement.  X defeats F by 3:1, which is exactly sufficient.
 I may wish this was true, but when reading the constitution again, I'm
 not sure at all we have a 3:1 ratio.

We don't. See also 

http://lists.debian.org/debian-ctte/2004/05/msg00027.html

Cheers,
aj


signature.asc
Description: Digital signature

Re: Call for Votes (Re: mixmaster /etc/default/*)

[Anthony Towns]

On Sun, Dec 02, 2007 at 10:13:38PM +, Ian Jackson wrote:
  (1) The REMAIL option should not be supplanted or supplemented by
  anything in an /etc/default file.  The current behaviour of the
  mixmaster init script, to examine /etc/mixmaster/remailer.conf's
  REMAIL option, is correct.
 
  (2) Policy is clear and correct, and need not be changed.

   [2] Choice K: Keep current behaviour and existing policy, as above.
   [1] Choice F: Further discussion

This bug hasn't been reassigned to the committee so we don't have any
business ruling on it. 

Voting for further discussion to ensure that a positive result gets
treated as advice rather than overruling to avoid the maintainer being
forced to go through the ctte to review this behaviour in future.

Cheers,
aj



signature.asc
Description: Digital signature

Re: TC voting and amendment procedure

[Anthony Towns]

On Tue, Dec 04, 2007 at 07:52:10PM +, Ian Jackson wrote:
 Perhaps we have different ideas about the proper way for TC members to
 behave after our positions have become clear on the main question at
 hand, and the main substantive questions have been fully explored. 

The substantive questions haven't been explored. I've been the only one
doing that, and we _remain_ with absolutely no evidence this is causing
any sort of problem beyond it does something different to gethostbyname.

 I think there comes a point where we should all accept that we aren't
 going to convince each other, 

You haven't tried convincing me; you've gathered absolutely no evidence,
nor tried to find a compromise position that might not be what either
of us would prefer, but that we'd both accept. You've just stood on a
soap box and spouted on about how as someone who's implemented a DNS
library you know how DNS should work, when and how to ignore standards
track RFCs in favour of your views, and how the tech committee must
operate. You've claimed that stable isn't affected by the issue in
response to mails explicitly noting it is, claimed without evidence
that this has been proven to cause significant operational problems in
practice, claimed without evidence that it broke our own ftp site
in spite of ftp.debian.org having a single address.

Combining that eagerness to overrule the maintainers here without
providing any reason for the maintainers, upstream, or IETF to review
their take on the matter, with your declaration the committee's job is
to review every disagreement in Debian and insistance on issuing a
ruling even when the dispute has already been dealt with properly by
themaintainer leaves this is a naked grab for power.

Decisions in Debian are meant to be made by maintainers, not some core
team. If your time with Canonical has made you come to another view,
that's fine, but it's not the way Debian does or should work. If your
lifestyle changes mean you've just got too much time on your hands, you
should be spending it hacking on Debian, not bossing other developers
around.

But anyway, we've discussed this enough. If we end up with some actual
evidence of problems to analyse I'll be happy to post about that,
but otherwise I'll just be voting for further discussion ahead of any
resolutions that don't specify why the maintainer isn't already handling
this successfully and thus why the tech-ctte needs to be involved, which
sadly seems to be everything you're proposing.

At least that means there need to be four other members of the ctte
voting in favour before the resolution can actually get in the way of
the maintainer doing what they think is right.

 Thus further argumentation to try to change each others' minds is both
 rude and unproductive.  I haven't been trying to convince you to
 change your mind because I feel that everything useful on both sides
 has already been said plenty of times already.  Would you please do
 the same, for all of our sakes ?

Por que no te callas, eh?

 There is nothing wrong with agreeing to disagree in that sense.  After
 all, we have a supposedly civilised and functional voting system so
 that we can reach decisions even when not everyone is of one mind.

I suspect somehow that the reason we need a strong consensus for
overruling a maintainer is precisely so that we do have to discuss the
issue and potential change each others' minds before doing so.

Cheers,
aj



signature.asc
Description: Digital signature

Re: TC voting and amendment procedure

[Anthony Towns]

On Sun, Dec 02, 2007 at 11:11:43PM -0800, Steve Langasek wrote:
 In what way are the reports that this has adversely affected Debian mirrors
 unsatisfactory?  

Have there been any reports? I've only seen Josip's second hand comments:

] I'm told that this bug also broke round-robin DNS functionality for
] ftp.us.debian.org/http.us.debian.org.
-- http://lists.debian.org/debian-ctte/2007/09/msg6.html

] I've noticed that security.debian.org, which is composed of three hosts,
] appears to be resolved by apts so that only one of them, steffani, gets
] picked. I can't substantiate this with exact log evidence yet (there's an
] outstanding RT ticket for that), but the system load on that machine is
] consistently high and network speed low, whereas the other two machines
] are practically idling in comparison.
]
] I've also previously noticed that ftp.us.debian.org traffic seems to
] concentrate too much on one host, too, ike.egr.msu.edu, but I've got even
] less evidence there (that and other machines aren't under our control).
-- http://lists.debian.org/debian-ctte/2007/11/msg00031.html

I'm told, I can't substantiate this, and I've got even less
evidence there...

But hey, you can always do an on-paper analysis even without actual data.

The names resolve to:

http.us/ftp.us:
  34.9.37.225 00100010 1001
  64.50.236.520100 00110010
security:
  128.31.0.36 1000 0001
  212.211.132.32  11010100 11010011
  212.211.132.250 11010100 11010011

Those compare with the private ranges:
  10.0.0.0/32 1010 ...
  172.16.0.0/12   10101100 0001...
  192.168.0.0/16  1100 10101000

The rule9/rule10 ordering means that we take the longest common prefix,
then do round-robin.

For http.us that would lead to:
  RR for addresses above 128.0.0.0 (including 192.168/172.16)
  100%/0% split for 10.0.0 addresses
  100%/0% split for addresses below 64.0.0.0
  0%/100% split for addresses above 64.0.0.0 but below 128.0.0.0

For security it gives:
  RR for addresses below 128.0.0.0
  RR for 10.0.0.0 addresses
  100%/0%/0% split for addresses below 192.0.0.0 but above 128.0.0.0
  100%/0%/0% split for 172.16..
  0%/50%/50% RR split for addresses above 192.0.0.0
  0%/50%/50% RR split for 192.168/16

So http.us would be biassed by 10.0.0.0 addresses, but everything else
seems fairly balanced, and afaics 10.0.0.0 addresses alone, while, likely
to be significant shouldn't be completely dominating. And security.d.o
looks like it should be fairly well balanced, though the 212.211.. hosts
are sharing each other's load more than 128.31's, so you'd expect a load
distribution somewhere between 33%/33%/33% and 50%/25%/25%.

Which leaves as conclusions:
  - there's no available evidence of a problem from Debian server logs
  - ftp.us, http.us and security.d.o all seem to still be functioning
from a user's perspective
  - the understanding of the issue we've got so far implies that this
would only cause fairly minor load balancing problems for the current
Debian hosts

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#441200: libconfig name clash

[Anthony Towns]

On Thu, Nov 29, 2007 at 08:15:47PM +, Ian Jackson wrote:
 So just to be clear, you conclude as I did that both packages should
 be required to select new names ?

Yes. I can't see any technical reason whatsoever not to do that.

  If either maintainer *wants* to use a different package name, they should
  just upload it to NEW, and the technical committee shouldn't even consider
  being involved unless there's an actual dispute about that name. 
 The problem is that without at least some controls the maintainers are
 quite likely to pick poor replacement names.  We've had at least one
 of them propose `libconfig1' which I'm sure you'd agree is bad.

Huh? That just seems daft -- it's not a different name at all, it's
just the package name for libconfig with a .so version of 1...

I can't see any record of anyone suggesting that though, and I'd really
hope that it wouldn't be accepted at NEW.

Abraham, Julien, do you have sensible alternative names for your packages
(eg, incorporating the existing libconfig into the libabz package,
or renaming the new libconfig package to libconfig-hyperrealm)? If so,
what are they?

 One option would be for the TC to explicitly ask the ftpmasters to be
 especially fussy with the replacement names.  For example:
N. The Committee asks the ftpmasters, when they process the
   resulting packages from either maintainer through NEW, to ensure
   that the new names are clear, descriptive, and unlikely to cause
   further clashes.

I would have thought this was already the case for _all_ packages, and
that libdebug and libconfig being accepted in the first place under those
names was a mistake. It's a bit long ago to really review now though.

  I don't support the technical committee being involved unless there's
  a clear lead; and even if I'd otherwise support the resolution, I'll
  vote against it if it tries to expand the technical committees influence
  where it's not clearly needed.
 I'm not sure what you mean by `clear lead'.  Perhaps you mean `clear
 need'.  

Yes.

 I don't have a problem with restricting the scope of the
 decisive part of the TC's formal ruling, provided that we can come up
 with some way to avoid the substitute names being just as poor.

I'm afraid I'm struggling with incredulity that we even need to deal with
that... NEW processing should deal with it, and the maintainers involved
should be able to figure out that libconfig1 isn't going to work...

  In any event, the way I currently see this is:
  (2) The existing libdebug in Debian must be renamed or removed.
 You're suggesting overruling the maintainer of this package, I take
 it.  

Sorry, I meant this is what I think, not this is what I think the
tech ctte should rule.The libdebug package has way too general a name.

  (3) The existing libconfig and libdebug should be incorporated into
  libabz.
 I would be happy to recommend this as formal part of our decision but
 I don't think we would want to overrule the maintainer.

No, hence the should instead of must.

  (4) The proposed libconfig should be called libconfig-hyperrealm or
  similar to distinguish it from other libconfigs.
 I agree with this.  How do you think we should word this part of our
 decision to make it clear what we mean ?  See above.

If we have to choose a name (and can't rely on NEW processing or the
maintainers to work how they're supposed to), I'm inclined to think we
should just pick some ourselves.

Cheers,
aj



signature.asc
Description: Digital signature

Old tech-ctte bugs

[Anthony Towns]

Hey all,

No one on the ctte seems to have taken any interest in:

  * #429671: exim4 username
  * #436093: Please decide on the ownership of the developers reference
  * #439006: tech-ctte: Efika and sony PS3 patches in linux-2.6 

They're all requests for dispute resolution, though 429671 also
includes a request from the exim4 maintainer for a final decision
on namespacing policy for packages that need usernames from the package
maintainer. They're all between three and five months old.

I think it's better to send a response to the submitter and maintainers
involved than just leave them hanging; so unless someone on the ctte
thinks there's something that warrants ctte's review in any of those
reports and wants to take ownership of making that happen over the next
week or so, I'll close them under the assumption we're going to let the
maintainers' decisions stand, at least for the forseeable future.

(If you do want to take ownership of one, tagging it confirmed seems
a useful way to distinguish reports that the ctte hasn't indicated an
interest in. Please don't take ownership of something and let it just
continue to sit there, at least an independent analysis for the rest of
us would be a good start...)

Cheers,
aj



signature.asc
Description: Digital signature

Re: TC voting and amendment procedure

[Anthony Towns]

On Sun, Dec 02, 2007 at 09:49:54PM +, Ian Jackson wrote:
 Everyone (even AJ, it seems) agrees that glibc in sid and lenny should
 be changed immediately.  

No, I have not seen any reason to overrule the maintainers in this
entire thread. I don't see how I could have indicated that any more
clearly than I already have. Despite repeatedly suggesting that some
actual reports from admins who've been affected might sway my view,
I haven't seen anyone even trying to come up with any.

 Our current rate of progress is approximately zero.

Better than heading speedily in the wrong direction.

Cheers,
aj



signature.asc
Description: Digital signature

Re: mixmaster /etc/default/*

[Anthony Towns]

On Sat, Dec 01, 2007 at 06:19:00PM +, Ian Jackson wrote:
 Anthony Towns writes (Re: mixmaster /etc/default/*):
  This is exactly the sort of thing I think we should simply ignore rather
  than issue any sort of ruling on. It's simply not important enough to
  be an issue. ie, unless someone on the tech ctte wants to champion the
  submitter's cause, I think we should simply reassign the bug back to
  mixmaster and close it. Err, if it's actually been assigned to the ctte
  by now.
 I find it hard to understand this suggestion of yours.  Are you saying
 that in general, if we disagree with the submitter of a bug, 

No, I'm saying that we shouldn't be in the business of reviewing every
disagreement in Debian. And we certainly shouldn't leave the decision
as to whether we'll review any particular decision solely up to whether
whoever was disagreed with is unwilling to let the matter drop.

 we should
 not issue a formal decision saying so, but instead just sit on our
 hands ?

If the issue doesn't really matter either way -- sufficient for at least
one of us to say this is worth reviewing, eg -- one of us should thank
the submitter for the chance to consider the matter, decline to do so,
and let the maintainer's decision stand, without having a vote.

Have it be someone files/reassigns a bug to tech-ctte, tech-ctte member
marks it as `confirmed' if review seems worthwhile, any bugs that've
been against the tech-ctte pseudopackage for more than a week without
being marked confirmed by some ctte member get closed, eg.

 But I don't think anyone is suggesting that in this case.  We just
 think the submitter is wrong.  It seems to me that we should say so.

The submitter's not wrong in any important way -- if he were the
maintainer and had decided to take the course of action, that'd be
fine too.

On Sat, Dec 01, 2007 at 06:30:04PM +, Ian Jackson wrote:
 Also, another question I forgot to ask.  Are the ballot options on my
 draft ballot (K explicitly approving of the existing policy and the
 existing package behaviour as laid out between my -8- cut marks, and
 FD as the alternative) sufficient to express your view ?

You can't have a ballot option to say this isn't worth having a ballot
about...

 If you want to propose an alternative resolution please do so ASAP
 because as I say I would like to call for a vote.  

Uh, the bug never actually got reopened or reassigned to the ctte, and
the submitter's most recent mail said I'm fine with the result. What's
the point of a vote?

Cheers,
aj



signature.asc
Description: Digital signature

Re: Call for Votes (was Re: glibc's getaddrinfo() sort order)

[Anthony Towns]

On Sat, Dec 01, 2007 at 01:16:05PM -0800, Steve Langasek wrote:
 On Sat, Nov 17, 2007 at 11:20:22AM +1000, Anthony Towns wrote:
  Given the discussion we've had it's clear we're not willing to consider
  this RC, which means stable will remain with its existing behaviour.
 I do think it warrants an update for stable; I only disagree that it's
 relevant to overriding the maintainer.  I would be fine with recommending
 that the SRMs accept an update for etch, but overriding the SRMs decision
 making process should surely be contingent on them having a chance to make
 that decision?

As well as overruling maintainers, we can decide on any matter
of technical policy, or offer advice, without needing to overrule
anyone. Serious severity is defined by the maintainer's opinion as
well as the release team's, so afaics we could make it RC by overruling
the maintainer too.

For that matter, our power to overrule a developer only says that we
may ask a Developer to take a particular technical course of action even
if the Developer does not wish to -- there's no need for the developer
to have already made a different decision.

Making a resolution like:

The technical committee finds the behaviour specified in RFC3484 s6
rule 9 to violate the expectations of people using round-robin DNS
and Debian machines implementing that rule cause significant load
imbalances on such servers as a result.

The technical committee overrules the maintainers of glibc as to the
validity of Bug#438179 and determines that the proposed solution of
making the gai.conf's sortv4 option default to yes be implemented.

The technical committee considers this behaviour to not meet Debian's
standards for released software, and recommends that the stable
release managers accept an update to stable to revert this behaviour.

would seem all that's needed to me. That's still dependent on us having
an opinion on whether this is RC though, and that load imbalances in
actual practice actually is the reason we're overruling.

Cheers,
aj



signature.asc
Description: Digital signature

Re: mixmaster /etc/default/*

[Anthony Towns]

On Fri, Nov 30, 2007 at 06:40:36PM -0800, Don Armstrong wrote:
 Deciding that an issue isn't important enough to make a decision
 requires making some sort of decision. 

No it doesn't, it just requires not noticing an issue -- eg, by it not
being brought to the tech ctte's attention at all (most decisions in
Debian), or by the tech ctte missing it when it is (429761, 439006),
or by the tech ctte leaving it lie (436096).

 I don't think the CTTE has any
 analogous process to a writ of certiorari,[1] so once an issue has
 been refered to the CTTE by an individual the issue should be resolved
 by considering the merits and making a decision.

It's easy to get in the habit of ignoring hard, important problems, and
bikeshedding easy, unimportant problems to death. We're very close to that
atm -- punting on whether the RFC3484 bug is RC, while going into copious
detail about whether a Proposed Standard is a standard or not, and
going into detail about which file under /etc some option should go to.

That's exactly wrong for the committee -- we should be around to work
on hard problems, and we shouldn't be spending any time at all on the
easy ones, which maintainers are already dealing with.

I think we can deal with that without introducing Latin terms or getting
too legalistic and process obsessed though. Ultimately it's something
the Chairman should probably be taking care of though, I guess.

Cheers,
aj



signature.asc
Description: Digital signature

Re: mixmaster /etc/default/*

[Anthony Towns]

On Fri, Nov 30, 2007 at 07:38:00PM +, Ian Jackson wrote:
 Having read the bug report I don't think there is very much to be said
 in favour of the submitter's point of view.

This is exactly the sort of thing I think we should simply ignore rather
than issue any sort of ruling on. It's simply not important enough to
be an issue. ie, unless someone on the tech ctte wants to champion the
submitter's cause, I think we should simply reassign the bug back to
mixmaster and close it. Err, if it's actually been assigned to the ctte
by now.

Cheers,
aj


signature.asc
Description: Digital signature

Bug#441200: libconfig name clash

[Anthony Towns]

On Tue, Nov 27, 2007 at 09:25:02PM +, Ian Jackson wrote:
   [Option D:]
 (1) The existing libconfig in Debian may retain its name.

The maintainer of that package writes:

] Here's my argument(s). I'll try to keep it short:
] 
]  a) First come, first serve. I'm both the upstream author and maintainer and
] the library is used by several of my programs (some Debian packages, some
] not). I would prefer not to spend all the effort to rename just to please
] another crowd that didn't do the research to check for name clashes to
] begin with.
] 
] I think it is definitely unfair to expect me to change the name, even if
] my version is less popular.
]
]  b) I agree that the name is perhaps a bit generic and a more specific name
] would have been a better choice.

  -- http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;bug=441200

As far as (a) goes, first-come-first-serve is reasonable to some extent,
which is why the git package doesn't contain the version control system.
Userbase is relevant too though, and afaics, libconfig doesn't have one. There
are no build-depends on libconfig0-dev in unstable, nor any dependencies on
libconfig0 or libconfig0-dev in unstable.

The libconfig author (Abraham vd Merwe, [EMAIL PROTECTED]) is also the 
maintainer
of libdebug (builds libdebug0 and libdebug0-dev) and libabz (builds
libabz0 and libabz0-dev). All the packages that use libabz are maintained
by Abraham, and all the packages that use libdebug also use libabz.

Both libconfig and libdebug have been unchanged since sarge's
release. libabz has been updated since sarge, but was not released with
etch due to bug 385881.

The extent of changes to libconfig since its initial inclusion in the
archive in June 2002 have been (according to the changelog):
   * Ported to library to FreeBSD.
   * Changed copyright notices to reflect my new preferred email address.
   * Updated feature wishlist.
   * Added a more descriptive description in control file (Closes: #151535)
   * Changed libconfig0-dev section.
   * Updated package dependencies.
   * Changed sections.

The changes to libdebug have been somewhat more substantial though not
massively so. libdebug was also first uploaded in June 2002. libabz
was first uploaded in November 2002 (according to the ftpmaster logs,
libconfig and libdebug were both accepted from NEW by Randall Donald;
libabz by James Troup).

AFAICS neither libdebug nor libconfig have any reason to be packaged
separately from libabz. I don't think they should have been accepted
with such generic package names in the first place.

   [Options X and N:]
 (1) The existing libconfig in Debian must be renamed or removed.

I'd say the libdebug0/libconfig0 binary package names should be reserved
for the existing libconfig/libdebug packages to ensure there aren't
any dependency breakages, but their source packages should definitely
be removed.

   [Option N:]
 (2) The newer library may use the name libconfig.
   [Options X and D:]
 (2) The newer library may not use the name libconfig.

I'd be inclined towards a name more like libconfig-hyperrealm to
avoid being unnecessarily generic, while still making it easy for people
searching for `libconfig'.

The first page of google gives the following results:

#1 hyperrealm libconfig by Mark A. Lindner (the one under ITP)
#2 gnuwin32 port of R. Keene's libconfig
#3 freshmeat page for R. Keene's libconfig
#4 homepage for R. Keene's libconfig
#5 sourceforge page for Zhange Le (ejoy)'s libconfig, a C++ port 
   of KDE's KConfig
#6 WAND libconfig
#7  #8 packages.d.o pages for libconfig-ini-perl
#9 this thread (!)
#10 libconfig for the Amaya web browser

Five different projects just called libconfig in the top ten results
seems to me to indicate libconfig alone isn't a distinctive enough
package name for any of them.

I don't see any way in which a more descriptive package name would
cause a problem. Actually, I see the Debian packaging included in the
upstream source already calls it libconfigduo. Renaming the library
itself from libconfig.so.5 would be more of a problem since it'd mean
binary incompatabilities with other distros. But I don't think that's
actually an issue, as long as the libconfig packagers make sure they
don't have .so name conflicts.

   [All options:]
 (4) If after that no member of the TC objects to a name within 7
 days (counted from the maintainer's suggestion), then the
 package is entitled to the name.
 (5) Even if a TC member objects, if the TC does not pass
 a resolution vetoing the new name within 28 days, the
 package is likewise entitled to the new name.

If either maintainer *wants* to use a different package name, they should
just upload it to NEW, and the technical committee shouldn't even consider
being involved unless there's an actual dispute about that name. 

I don't support the technical committee being involved 

Re: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical wish

[Anthony Towns]

severity 438179 wishlist
thanks

On Tue, Nov 27, 2007 at 07:09:04PM +, Debian Bug Tracking System wrote:
 Processing commands for [EMAIL PROTECTED]:
  severity 438179 serious
 Bug#438179: Please provide a way to override RFC3484
 Severity set to `serious' from `wishlist'

Josip, there's been absolutely no evidence that our mirrors are
fucking up. If you've got some, please share it instead of taking your
frustration out by playing with BTS serverities.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Call for Votes (getaddrinfo)

[Anthony Towns]

On Thu, Nov 29, 2007 at 07:51:37PM +, Ian Jackson wrote:
  -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
  [ ] Choice X: Do not use rule 9, overrule maintainer, etc., as above.
  [ ] Choice S: Sort IPv4 addrs according to rule 9 in getaddrinfo
  [1] Choice M: Leave the choice up to the maintainers.
  [2] Choice F: Further discussion
  -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

The don't delete anything between these lines seems pointless since we're
not using a program to tally votes...

Again, if we don't think this bug is severe enough to need to be fixed
in stable (and thus qualifies as RC), I don't think we should be overruling
the maintainer.

If Josip's correct in saying that this is screwing over the Debian
apt round-robin hosts, it seems like we should be saying this is RC, but
nobody seemed willing to do that when I brought it up earlier.

  4. Prior to the publication and implementation of RFC3484, and prior
 to the introduction of getaddrinfo, most hosts would use an
 implementation of gethostbyname to find IPv4 addresses to use for
 a peer, given its hostname.  gethostbyname has almost universally
 returned the addresses in the order supplied by whatever DNS
 nameserver it was using.

getaddrinfo() also almost universally behaved that way until very
recently.

  IPv6 transition
  7. The primary use of getaddrinfo is to replace gethostbyname when an
 application is converted to support IPv6.  

I would say the primary use of getaddrinfo is to resolve a domain name
in a useful way. I don't think replacing gethostbyname is relevant --
if it behaves differently to gethostbyname that's a win if it's more
useful and a loss if it's less useful; it's not always a loss merely
because it's different.

  9. There are no known applications which specifically desire the
 rule 9 behaviour; we know of no case where an application uses
 getaddrinfo specifically to get rule 9.

RFC3484 specifically allows rule 9 to be overriden if the implementation
has a better process, so it's not reasonable for an application to rely
on rule 9, afaics.

  10. There is therefore no rational reason for the difference
 between the behaviour of gethostbyname and getaddrinfo, other than
 perhaps implementation convenience.

Consistency between IPv4 and IPv6 behaviours seems a perfectly rational
desire, even if it doesn't warrant the cost of changing the application
behaviour.

  11. Rule 9 is incompatible with the DNS Round Robin.  

It's perfectly compatible, it just overrides it.

  12. When Debian's apt changed its behaviour to follow rule 9,
 it broke ftp.us.debian.org because the load suddenly became very
 unbalanced.  Thus this incompatibility causes actual operational
 problems.

I've seen no evidence that that actually happened. There's some
hearsay from Josip (I'm told that thisbug also broke round-robin DNS
functionality for ftp.us.debian.org/http.us.debian.org), but that's it.

  Standards
  18. The purpose of standards is interoperability.  Where following a
 standard makes us less interoperable we should not follow the
 standard.  Debian is entitled to deviate from standards, including
 published documents, if we consider it appropriate to do so.

This doesn't affect interoperability either way, though.

It changes the impact of Debian systems on services provided by
round-robin hosts (ie, to possibly impact some servers more than
others, depending on the distribution of clients, rather than
doing equal balancing), and it results in changed expectations of
users/developers/admins as to how host resolution on round-robin addresses
will work.

  23. It appears that RFC3484 is also unhelpful for IPv6.  However,
 since there is no existing de-facto standard for IPv6, this
 conclusion is arguable.

RFC3484 is relied upon by other IPv6 drafts/standards in order to choose
the correct class of address for a service (a roaming address versus
a static one, a site-local address versus a global one, etc). Some of
those can be dealt with by earlier rules (particularly site-local versus
global), but that leaves many RFCs that do rely on the rule for IPv6.

  Backporting to current stable
  26. In my opinion this change should be backported to current
 stable.  However, this decision does not need to be taken now.  We

I think this should be the maintainers' call.

The call I think we should be making is whether this is an issue that
needs to be corrected in stable, whether by the patch we've seen, or by
some other means. If that fix doesn't happen immediately, but waits for
further testing in unstable and lenny, that's fine -- it'll be waiting
for the next point release in any case.

Again, if we don't think this is sufficiently serious to need to be
fixed in stable, afaics that means we're ignoring the impact of Debian
machines on round-robin services as an important consideration --
including 

Re: Call for Votes (was Re: glibc's getaddrinfo() sort order)

[Anthony Towns]

On Thu, Nov 15, 2007 at 07:16:17PM +, Ian Jackson wrote:
  -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
  [ ] Choice X: Do not use rule 9, overrule maintainer, etc., as above.
  [ ] Choice S: Sort IPv4 addrs according to rule 9 in getaddrinfo
  [ ] Choice F: Further discussion
  -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

[1] Choice M: Leave the choice up to the maintainers.
[2] Choice F: Further discussion
[ ] Choice X: Do not use rule 9, overrule maintainer, etc., as above.
[ ] Choice S: Sort IPv4 addrs according to rule 9 in getaddrinfo

Given the discussion we've had it's clear we're not willing to consider
this RC, which means stable will remain with its existing behaviour. Given
that, I'm not willing to support overriding the maintainers, upstream
and the relevant standard.

Cheers,
aj



signature.asc
Description: Digital signature

Re: getaddrinfo() behaviour

[Anthony Towns]

On Mon, Oct 01, 2007 at 10:44:48AM +0200, Andreas Barth wrote:
 * Anthony Towns ([EMAIL PROTECTED]) [071001 03:46]:
  One of the rules for RCness is in the package maintainer's opinion,
  makes the package unsuitable for release. Not quite the same, but
  not very different is in the technical committee's opinion, makes the
  package unsuitable for release -- is that what we think of this issue?
 I don't see which advantage we will get from introducing the concept RC
 ness into this decision. AFAICS, we can perfectly well make a decision
 only about the topic in question.

In my opinion, if this isn't an RC issue, there's no urgency to having
glibc changed prior to the standards changing, and as such, this isn't
the last resort so the tech ctte shouldn't be deciding the issue, let
alone overruling the maintainer.

In my opinion, if this issue isn't severe enough to warrant a change to
stable, it's also not severe enough to warrant overruling the maintainer
wrt unstable -- if we're trying to stop Debian machines behaving badly
on the Internet, that applies to stable at least as much as unstable.

I don't see why stable would be changed for a non-RC issue in this case,
nor why this being RC wouldn't warrant stable being changed, so I consider
those to be equivalent.

OTOH, if we're not that worried about Debian machines behaving badly, but
we're trying to influence the future of the Internet, changing the RFC
is the way to go, and there's no need to overrule our glibc maintainers
or keep more patches from glibc until our concerns have been passed on
to the IETF.

 If the decision is right, why should we wait for a new document?

Because the maintainers, upstream and IETF all currently agree that the
other way of approaching things is right.

 Especially as the current document isn't a standard either, but the old
 behaviour is.

I don't believe the old behaviour has even reached the level of
proposed standard in the IETF nomenclature -- certainly I haven't
seen any evidence of it up 'til now. If you're claiming it's a de facto
standard, well, this is how de facto standards change -- with upstream
implemented preferred behaviours, and us releasing them as part of stable.
And I realise dismissing RFC3484 as not a standard is all the rage, but
personally I still give quite a bit of weight to IETF proposed standards.

It's possible we've reached the end of the discussion; if other members
of the TC don't consider this severe enough to make glibc unsuitable
for release and all that entails, then I don't see any way to support
overruling the maintainers on the issue -- but that doesn't mean we
can't decide to overrule the maintainers anyway: it just means three
people need to vote for it, and no one else can vote against it.

I have absolutely no qualms putting my name to something saying RFC3484
is lame, just the bit that says and it doesn't matter what the glibc
maintainers think, this is the way it should be done in Debian.

Cheers,
aj



signature.asc
Description: Digital signature

Re: getaddrinfo() behaviour

[Anthony Towns]

On Mon, Oct 01, 2007 at 04:30:17PM +0100, Ian Jackson wrote:
 Ian Jackson writes (Re: getaddrinfo() behaviour):
  Limiting the TC's power to overrule a technical decision to only cases
  where the TC believes that the wrong behaviour makes the package
  unsuitable for release would eviscerate the only mechanism we have for
  dealing with errors by maintainers.
 I should have said, for dealing with errors by maintainers which
 persist after persuasion has been tried.

Updating the proposed standard has not been tried. If it had, and failed,
and did so without addressing the concerns we've had with the current rfc,
it'd be appropriate for the tech ctte to rule -- we would have exhausted
all other means of obtaining a consensus, and it would be the last resort.

If there hadn't been a proposed standard in the first place documenting
the existing behaviour, I doubt we'd have a problem in the first place,
and there certainly wouldn't be an issue with us overruling the maintainer
if there somehow was.

The only reason suitability for release is relevant is in overriding the
directive that we'll not make a technical decision until efforts to
resolve it via consensus have been tried and failed. We haven't made
efforts to get a consensus with the IETF working group and change the
standard that all this stems from, so making a decision before that's
happened requires further justification in my view.

I can't say I'd noticed much effort from the ctte to persuade the glibc
maintainers of anything, to be honest.

Cheers,
aj



signature.asc
Description: Digital signature

getaddrinfo() behaviour

[Anthony Towns]

So here's my understanding of where we're at.

First, fact finding. Everything here should be able to be agreed by
everyone.

getaddrinfo() is a new interface that replaces gethostbyname(). It
hasn't different semantics that are intended to make it superior
to gethostbyname() and other functions, both in supporting IPv6 and
potentially other ways (such as resolving foo.bar.com:http differently
to foo.bar.com:https).

The most authoritative document for how getaddrinfo() will order
its results is RFC3484, which is a Proposed Standard on the Internet
Standards Track and seems to be being implemented by the major vendors
including glibc and Windows.

The sorting behaviour of getaddrinfo() cannot be relied on in today's
Internet, and it behaves differently in different implementations --
particularly due to RFC3484 having been proposed only after getaddrinfo()
had already been in wide use. Further, RFC3484 specifically indicates
that the sorting behaviour may be overridden if a better order can be
determined locally (see the last paragraph of section 6). Beyond that,
determining optimal address selection appears to be an open area of
research, and modifications to RFC3484 are still being discussed and
proposed both within and outside of the RFC context [0].

Note that RFC4294 (IPv6 Node Requirements) indicates RFC3484 MUST be
implemented, at least in the context of dealing with multiple addresses.

The sorting behaviour specified in RFC3484 has not been in common
use within the IPv4-based Internet. Instead, by far the most common
behaviour has been to use the ordering presented by the DNS, usually
simply selecting the first returned result. This behaviour has allowed
client address selection to be influenced by the DNS system and thus the
provider of the service being addressed, as described in RFC 1794. This
has most commonly been implemented by having the DNS servers provide a
cyclic, round-robin selection of addresses, such that each address is
returned as the first result equally often.

This is not the only method for load balancing, though it is one of the
simplest and most easily deployed on today's Internet. Others include
giving entirely different results to different people doing DNS queries
such as described in the supersparrow architecture [1], or doing dynamic
load balancing of http queries via the 302 redirect response.

The primary expectations for load balancing are generally one or more of:
- that load be evenly distributed across hosts
- that load be biassed to the closest/cheapest host for the client
- that load distribution be controllable by the service provider

The prefix-matching procedure described in RFC3484 does not meet those
expectations in a number of cases.

First, responsibility for destination selection is assumed entirely by the
client, so that the only choice the service provider has is to list or
not list a host. As such the service provider is faced with a choice of
providing only the best servers to the client, and not giving the client
the possibility to failover to other servers that might be available;
or having the client select a server entirely on its own judgement.

Second, when NAT is in use, a relatively small range of prefixes (10/8,
192.168/16, 172.16/12 and potentially 169.254/16) will have a high
number of users, thus leading to a bias towards servers matching those
prefixes. Further, those prefixes by design do not bear any relationship
to their actual position in the network, removing the possibility of
the bias being towards close/cheap servers.

Third, when round-robin DNS is in use, the ordering procedure described
by RFC3484 will not ensure that all servers with the best matching
prefix are given equal time as the first address returned, but instead
may be biassed towards one address depending on the exact ordering of
the addresses presented by the server [2].

Each of these objections apply to the mechanism described in RFC3484
whether applied to IPv4 or IPv6 addresses.

In addition, with particular regard to IPv4 addresses, in the present
day Internet:

- round-robin DNS is normal
- NAT is extremely common
- the average prefix length in BGP tables is 22 [3], and
  matches on shorter prefixes do not provide a strong correlation
  with locality

...

Is the above all reasonable and uncontroversial?

If so, conclusions that could potentially be drawn:

(a) Using prefix matching to select IPv4 addresses isn't useful
(b) Using prefix matching to select IPv4 addresses is harmful
(c) Using prefix matching to select IPv4 addresses is harmful enough to
be an RC issue for Debian
(d) Prefix matching IPv4 addresses provided the match is at least 22 bits
(or similar) might be reasonable
(e) Choosing the best address isn't a job for the client, and is better
left to the service provider and DNS system
(f) Given the existance of round-robin DNS, if prefix 

Re: getaddrinfo: DNS round robin vs RFC3484 s6 rule 9, for etch

[Anthony Towns]

On Fri, Sep 28, 2007 at 04:56:31PM +0100, Ian Jackson wrote:
 We have to decide whether we want to make the same change to etch.
 The main upside would be that the ftpmasters would once again be able
 to use round robin DNS for eg ftp.us.debian.org.  

$ host ftp.us.debian.org
ftp.us.debian.org has address 35.9.37.225
ftp.us.debian.org has address 204.152.191.7
$ host http.us.debian.org
http.us.debian.org has address 64.50.238.52
http.us.debian.org has address 128.101.240.212
http.us.debian.org has address 204.152.191.7
http.us.debian.org has address 35.9.37.225

Cheers,
aj



signature.asc
Description: Digital signature

Re: getaddrinfo: DNS round robin vs RFC3484 s6 rule 9, for etch

[Anthony Towns]

On Fri, Sep 28, 2007 at 05:12:57PM +, Pierre Habouzit wrote:
   This argument is pure crap and prevent anyone interested to post to
 the TC list. This has pissed me beyond repair on this problem, and I
 believe I wasn't the only one. IMHO, the TC isn't functional with a
 restricted mailing list. debian-release is not under the same
 censorship, and looks though pretty functional to me.

For the record I'd be happier with the -ctte list behaving similarly
to -release.

Cheers,
aj



signature.asc
Description: Digital signature

Re: getaddrinfo() behaviour

[Anthony Towns]

On Fri, Sep 28, 2007 at 04:47:34PM +0100, Ian Jackson wrote:
 Since I did the backport for Ubuntu I'm probably the right person to
 prepare the update for etch (not that it's very hard).

For concreteness, thanks to Aurelien's original addition to gai.conf
before this was brought to the ctte, the patch is as simple as:

diff -urb glibc-2.6.1-5/debian/patches/any/submitted-rfc3484-sortv4.diff 
glibc-2.6.1/debian/patches/any/submitted-rfc3484-sortv4.diff
--- glibc-2.6.1-5/debian/patches/any/submitted-rfc3484-sortv4.diff  
2007-09-29 12:36:14.0 +1000
+++ glibc-2.6.1/debian/patches/any/submitted-rfc3484-sortv4.diff
2007-09-29 12:38:50.0 +1000
@@ -18,9 +18,9 @@
  #used.  There are possible runtime problems.  The default is no.
  #
 +# sortv4  yes|no
-+#If set to no, getaddrinfo(3) will ignore IPv4 adresses in rule 9.  See
-+#section 6 in RFC 3484.  The default is yes.  Setting this option to 
-+#no breaks conformance to RFC 3484.
++#If set to yes, getaddrinfo(3) will sort IPv4 adresses in rule 9.  See
++#section 6 in RFC 3484.  The default is no.  Setting this option to 
++#yes enables stricter conformance to RFC 3484.
 +#
  # label   mask   value
  #Add another rule to the RFC 3484 label table.  See section 2.1 in
@@ -36,7 +36,7 @@
 +static int gaiconf_reload_flag;
 +
 +/* Zero if we are supposed to ignore rule 9 for IPv4 addresses */
-+static int gaiconf_sortv4_flag = 1;
++static int gaiconf_sortv4_flag = 0;
 +
 +/* Last modification time.  */
 +static struct timespec gaiconf_mtime;
@@ -73,7 +73,7 @@
  if (strcmp (cmd, reload) == 0)
gaiconf_reload_flag = strcmp (val1, yes) == 0;
 +else if (strcmp (cmd, sortv4) == 0)
-+  gaiconf_sortv4_flag = strcmp (val1, no) != 0;
++  gaiconf_sortv4_flag = strcmp (val1, yes) == 0;
  break;
  
case 10:

I still can't see any reason why the right person to apply the patch
is anyone other than the maintainer.

  If so, conclusions that could potentially be drawn:
  (a) Using prefix matching to select IPv4 addresses isn't useful
  (b) Using prefix matching to select IPv4 addresses is harmful
  (c) Using prefix matching to select IPv4 addresses is harmful enough to
  be an RC issue for Debian
   If so, declaring this to be an RC issue justifies both an update to
  etch and (if necessary, which I don't expect) an NMU for sid/lenny,
  which seems all that's needed.
 I don't see why RCness is relevant for updating sid.

 Surely the TC should ensure that its decisions are implemented even if
 we consider the issue non-RC ?

If it's not an RC issue -- thus qualifying for a stable update as well
-- I don't see why it's important enough to overrule the maintainer for
sid, rather than simply leaving it as is while we provide the IETF with
comments on why the RFC's recommendations need changing.

The TC should only make decisions as a last resort; if this isn't an
RC issue, I just don't think we're at that point: we haven't contacted
either upstream or the IETF for example, and living with non-RC bugs,
including this one, isn't difficult.

  I'm not sure if any or all of (d)-(f) would be sufficient recommendations
  to close the issue for IPv6 as well, or if there's something else that
  would make sense.
 I think we should avoid getting too bogged down with IPv6.  We can
 safely leave that to the IETF to reconsider since we're evidently not
 going to overrule the libc maintainer on that point.

If, as an implementor, the Debian technical committee has a problem with
the IETF's proposed standard, it's our job to fully explain what the
problem is and suggest ways of avoiding the problem. If we're going to
shirk that task, I don't believe we should be overruling the maintainer
or upstream on the issue of complying with the proposed standard.

Cheers,
aj



signature.asc
Description: Digital signature

Re: glibc's getaddrinfo() sort order

[Anthony Towns]

On Sun, Sep 23, 2007 at 04:21:58AM -0700, Steve Langasek wrote:
 On Fri, Sep 21, 2007 at 01:07:49PM +1000, Anthony Towns wrote:
  On Thu, Sep 20, 2007 at 06:19:10PM -0700, Steve Langasek wrote:
   So do you have a use case where you think the behavior described in rule 9
   *is* desirable?
  Any application written assuming this behaviour, works correctly on
  Windows, Solaris, *BSD and glibc based systems in general, but not
  on Debian.
 So my argument here is that I don't believe there *are* any applications
 being written that assume this behavior; and that even if there were, such
 applications would either work just fine with the previous getaddrinfo()
 behavior, or be too pathological to live.

There's two aspects to RFC3484's behaviour: first that it creates a
much more stable ordering of its results than could have been expected
otherwise, and second it tries to make that ordering more optimal than
a random ordering would be wrt routing.

Stability is useful for any case where the servers hosting a particular
might be out of sync with each other; eg, if stability could be assumed
we'd have less errors where an invocation of apt-get update chooses one
mirror, and a subsequent apt-get upgrade chooses a different server
that hasn't finished syncing. Hopefully apt-get isn't considered
too pathological to live...

Better routing has less direct benefits to the client, probably limited
to slightly better ping times, with a small chance of somewhat cheaper
bandwidth costs. For the people providing the service, it lets you make
better assumptions as to load balancing -- you can expect the servers
based in a particular area to be serving a load proportional to the
number of users in that area, rather than having the load fairly evenly
distributed globally. Of course, there are other ways of doing this
that don't rely on how the client's resolver is implemented. Of course,
if the routing is worse, those turn into drawbacks instead of benefits.

 Instead, taken over the whole Internet rule 9 is statistically a
 pseudo-randomization relative to the *correct* sorting[1],

If that were the case it would be no worse than round-robin selection of
preferred address.

You can only take it over the whole Internet if you're assuming an equal
distribution across all IPs, which isn't valid for IPv4 (where there's
presumably a significant bias to private IPs), and presumably isn't valid
for any particular service, which will be heavily biassed to particular
IP ranges by correlation with location or language...

 One of the existing use cases that breaks is round-robin DNS.  

Round-robin DNS isn't broken; the expectation of (approximately) equal
load-distribution across all servers in a round-robin is broken.

 They might be reasons why RR DNS would be
 an acceptable sacrifice in favor of other beneficial features, but rule 9 as
 written offers *no* benefits in the general case!

Even without the possibility of applications like apt-get benefiting
from stability of results, I don't think we've done anywhere enough of
a review to be declaring that there aren't any benefits to rule 9.

 So I don't see that much weight should be given to whether other operating
 system vendors choose to comply with a rule which is, fundamentally,
 misguided and broken.

As far as I can see, for rule 9 to be fundamentally misguided and
broken, the concept of providing a stable answer, or a better than random
ordering, would need to be harmful. If they're beneficial, even in some
cases, then we've got a problem in the details of the specification,
not a fundamental issue.

(Note that prefix matching is the only reordering rule that has any
effect in almost all actual cases, so without that rule or a replacement,
both stability and any improvements in routing disappear)

Note that stability isn't definitively a good thing -- if the first
server you connect to happens to be the only one that's down/unreachable,
then with a stable resolver you need to have specific failover code
to use a different address; whereas if you can expect gethostbyname()
to return a different first result, you can just rerun the program.

 Furthermore, even if gethostbyname() has been deprecated in POSIX, it's
 relevant that there is still plenty of software in Debian that uses this
 interface[1].  Almost all of this software is going to be IPv4-only; if we
 want Debian to be fully IPv6-capable, these are programs that will need to
 be updated to use the getaddrinfo() interface, at which point they will
 cease to work correctly with round-robin DNS in the absence of additional
 code to re-randomize addresses(!).  

Uh, round-robin DNS isn't a guarantee that any individual client will
get different or randomised results -- and the argument that round-robin
won't break anything that relies on rule 9 goes the other way too.

Further, having getaddrinfo() behave differently for IPv4 and IPv6
isn't completely helpful in making Debian support IPv6 -- if we change
a program

Re: glibc's getaddrinfo() sort order

[Anthony Towns]

On Thu, Sep 20, 2007 at 06:19:10PM -0700, Steve Langasek wrote:
 So do you have a use case where you think the behavior described in rule 9
 *is* desirable?

Any application written assuming this behaviour, works correctly on
Windows, Solaris, *BSD and glibc based systems in general, but not
on Debian.

In the bug log, Pierre reported this behaviour is already supported on
most of those sytems:

] On that matter, according to Aurelien, Vista (maybe XP),
] {Open,Net,Free}BSD follow the RFC. Other OSes could be tested (MacOS X
] and solaris come to mind). So it's kind of a decision of Debian vs. the
] rest of the world. And if I don't really care about the issue of the
] decision technically, this aspect worries me.

Hrm, I see RFC5014 (from this month) provides some socket options for
changing the way RFC3484 source address selection works, and envisages
the possibility of doing the same for destination address selection. It
assumes prefix matching is undertaken in getaddrinfo in order to achieve
one of its aims.

 Even if you do have one, I still don't see any reason to think this is a
 reasonable default behavior on the real-world Internet.

As it happens I largely agree with that. I don't agree with making a
decision to go against an IETF standard and glibc upstream lightly,
though, no matter how many caps Ian expends repeating that it's at the
least mature level of Internet standard. If it's also the case that
the RFC-specified behaviour is a de facto standard amongst other OSes,
as the above seems to indicate, then that's even more reason to make
sure we have a clear decision backed up by good, clear reasoning.

Cheers,
aj



signature.asc
Description: Digital signature

Re: glibc's getaddrinfo() sort order

[Anthony Towns]

On Tue, Sep 18, 2007 at 03:33:51PM +0100, Ian Jackson wrote:
 Anthony Towns writes (Re: glibc's getaddrinfo() sort order):
  I'm not familiar with how getaddrinfo() has been implemented in the
  past
 I think this is an important point.  If you're not familiar with the
 history then perhaps I can help explain.
 hostname-to-address lookups have up to recently generally been done
 with gethostbyname.

Right, gethostbyname I am familiar with (along with the corresponding
DNS round-robin behaviour), and changing its behaviour is certainly
unreasonable.

 [...]

 So far so good.  (For clarify, it is the above round-robin
 functionality that I am arguing ought to be preserved.)

 [...]

 However, additionally, it was realised that if getaddrinfo can return
 a mixture of IPv4 and v6 addresses it was necessary to specify in what
 order they ought to be returned.
 
 When RFC3484 was written its authors evidently felt that the best way
 to do this was to define a comparison function over all addresses,
 which would define which address was to be preferred.
 
 Heedless of the effect on the DNS round-robin functionality I describe
 above, the authors of RFC3484 specified (s6 rule 9) that all addresses
 should be sorted by proximity to the host making the choice - where
 proximity is defined as the length of the common initial address
 prefix.

So if getaddrinfo() has always behaved in this way, I don't see a great
deal of justification in changing it. The bug log indicated that there
were pre-rfc implementations of getaddrinfo() that behaved more like
gethostbyname() at least wrt round-robin DNS; but I've got no way of
verifying that.

 This may have been a disputed but arguable definition of real network
 proximity for IPv6 in at the time 3484 was written.  But it is clear
 now that it is not such a measure in the real IPv6 internet, and it
 has never been such a measure in the IPv4 internet.

I hadn't seen any indication it was disputed for IPv6 prior to your mail.
The patch in glibc only affected IPv4 addresses, for that matter.

 So RFC3484 s6 rule 9 is just wrong, because the reasons behind it do
 not apply any more if they ever did.

To give an analogy to the lines I'm thinking along: the definition of
tm_year in the tm struct in time.h is wrong, years since 1900 should be
years since 0 AD, but the spec says otherwise, so programs simply need
to deal with that historical craziness.

That's not quite the same here, in that the spec does (by my reading)
explicitly allow implementors to not behave in that way, but if you're
coding to the spec you certainly can't rely on DNS round-robin being passed
through an invocation of getaddrinfo().

 However, it's worse than that: rule 9 is trying to change the
 behaviour of existing systems.  If we agree with rule 9 it ought to
 apply just as well to applications using gethostbyname.

 All existing applications using gethostbyname are not in compliance
 with rule 9.  

The RFC specifies the behaviour of getaddrinfo(), not gethostbyname(),
so doesn't affect any apps that solely use gethostbyname(). So no, it
shouldn't be applied to other functions anymore than the definition of
tm_year should mean we count from 1900 in every year related function.

I think we can safely say that Rule 9 isn't useful for IPv4 addresses.
I'm not sure that's true or not for IPv6 addresses -- it certainly seems
an inappropriately hierarchial way of viewing a network that's connected
much more ... fluidly than that, at any rate. But even if Rule 9 is
completely useless and counterproductive, it's still the standard for
that function, which, afaics, we should be meeting.

 What about getaddrinfo ?  Well, there is no reason why a change in API
 (to add additional richness needed for new functionality) should so
 radically change the behaviour.

Agreed in principle, but this is a rule the RFC should've followed;
since they haven't, I'm not convinced we should.

 It is not reasonable for the RFC to attempt to specify that the
 addresses be returned in a predictable ordering when the established
 behaviour, relied on throughout the internet for decades, has been
 that the addresses are _not_ returned in a predictable order.

Again, I agree with that, but the RFC *has* done that.

  I'd say it's more important that getaddrinfo() on Debian behave the same
  as on other operating systems, than that it behave in the same way as
  other functions. I can only take the RFC's assertion as to getaddrinfo()'s
  proper behaviour though; I don't have a more direct idea how getaddrinfo()
  behaves in previous versions of Debian, other Linux distros, other libcs,
  Windows, etc.
 This argument is an argument for accepting any crap that comes out of
 glibc upstream.

No, it's an argument for accepting any crap that comes out of the Internet
standards process. :-/

 As I have demonstrated above, the RFC is wrong, inconsistent with
 existing practice, 

It's certainly inconsistent with gethostbyname()'s existing

Re: glibc's getaddrinfo() sort order

[Anthony Towns]

On Tue, Sep 18, 2007 at 07:18:40PM +0100, Ian Jackson wrote:
 There are only three possibilities:
 (a) It is correct that the behaviour of applications (and hence of
 hosts) should be changed to comply with rule 9.
 (b) Application behaviour should not change; getaddrinfo should
 behave the same way as gethostbyname.
 (c) Application behaviour should not change but getaddrinfo should
 comply with rule 9.  Applications should therefore not be changed
 to use getaddrinfo instead of gethostbyname.

No, there aren't. A fourth possibility is:

  (d) Applications should use getaddrinfo(), and if the ordering behaviour
  it uses is not desired, they should use an ordering that is desired.

Since we're at the point where you're yelling at me about how I'm not
listening, I won't reply further.

Cheers,
aj



signature.asc
Description: Digital signature

Re: glibc's getaddrinfo() sort order

[Anthony Towns]

On Tue, Sep 18, 2007 at 08:41:45PM +0200, Kurt Roeckx wrote:
 On Wed, Sep 19, 2007 at 03:03:51AM +1000, Anthony Towns wrote:
  So if getaddrinfo() has always behaved in this way, I don't see a great
  deal of justification in changing it. [...]
 glibc is the only implementation I know of that does this.

Windows implementations would seem like the other candidate, given the
Microsoft Research at the top of that RFC.

Cheers,
aj



signature.asc
Description: Digital signature

Re: glibc's getaddrinfo() sort order

[Anthony Towns]

On Wed, Sep 19, 2007 at 04:52:35AM +1000, Anthony Towns wrote:
 Ah, that'll be because the ordering's simply rotating, rather than being
 random: so we're assuming from A  B,C,D  E and getting:
   ABCDE - ABCDE
   BCDEA - ABCDE
   CDEAB - ACDBE
   DEABC - ADBCE
   EABCD - ABCDE
 which biasses B to being in second place, C in third, and D in fourth,
 simply because all but twice, B is ahead of C and D in the input because
 it's just being rotated, not shuffled.

In fact you can take this further, to the point where getaddrinfo()
is actively unbalancing the load. Suppose you have addresses:

F1.00.00.02 (a)
F1.00.00.03 (b)
01.00.00.02 (c)
01.00.00.03 (d)

Then your longest matching prefix will be either with a and b or c and d.
In that case, you get:

DNS   a/b match  c/d match
  ~  ~
abcd  abcd   cdab
bcda  bacd   cdba
cdab  abcd   cdab
dabc  abdc   dcab

Which will give three times the load to a and c compared to b and d.

And note that applies to IPv6 as well as IPv4, presuming the DNS presents
IPs in the simplest round-robin fashion.

Cheers,
aj



signature.asc
Description: Digital signature

Re: glibc's getaddrinfo() sort order

[Anthony Towns]

On Fri, Sep 07, 2007 at 01:06:06AM +0200, Kurt Roeckx wrote:
 It's atleast in the spirit of the rfc to prefer one that's on the local
 network.  It might be the intention of rule 9, but then rule 9 isn't
 very well written.

Rule 9 seems perfectly well written, it just does something you
(reasonably) consider undesirable.

The RFC says:

]   Rule 9:  Use longest matching prefix.
]   When DA and DB belong to the same address family (both are IPv6 or
]   both are IPv4): If CommonPrefixLen(DA, Source(DA)) 
]   CommonPrefixLen(DB, Source(DB)), then prefer DA.  Similarly, if
]   CommonPrefixLen(DA, Source(DA))  CommonPrefixLen(DB, Source(DB)),
]   then prefer DB.
]
]   Rule 10:  Otherwise, leave the order unchanged.
]   If DA preceded DB in the original list, prefer DA.  Otherwise prefer
]   DB.
]
]   Rules 9 and 10 may be superseded if the implementation has other
]   means of sorting destination addresses.  For example, if the
]   implementation somehow knows which destination addresses will result
]   in the best communications performance.

The admin says that rule 9 isn't appropriate seems to fit somehow
knows which destination address will result in the best communications
performance, so afaict, the description in the new gai.conf,

# sortv4  yes|no
#If set to no, getaddrinfo(3) will ignore IPv4 adresses in rule 9.  See
#section 6 in RFC 3484.  The default is yes.  Setting this option to 
#no breaks conformance to RFC 3484.

is incorrect, in that that the implementation is still in conformance
with the RFC.

In addition, I think there's two different aspects here: the first is
should getaddrinfo() return results in random order to aid in load
distribution? and the second is is prefix matching a reasonable way
to determine a good host to use?

AFAICS, the answer to the first question is simply no, it shouldn't --
randomised load balancing like that needs to be done at the application
level, or by giving different sets of IPs in response to DNS queries by
different hosts, such as using BGP or similar. As far as pool.ntp.org
is concerned, that looks like the end of the story, afaics: ntp can't
rely in getaddrinfo to give a suitably random answer.

OTOH, getaddrinfo is meant to give a close answer, and doing prefix
matching on NATed addresses isn't the Right Thing. For IPv6, that's fine
because it's handled by earlier scoping rules. For NATed IPv4 though the
prefix we should be using is whatever the host is going to be NATed *to*.
And that would imply that the Right Thing would be to have an option
more like:

pretend-that 10/8 is-really 1.2.3.4/32

That doesn't seem likely to work though because it requires extra
manual configuration, which won't happen.

Giving up on actually getting getaddrinfo to give close answers for
NATed boxes leaves the option of trying to avoid getaddrinfo going out
of its way to give far answers instead, which would mean turning off
prefix-matching for NATed boxes; which could be done by ignoring rule
9 by default for private IPv4 addresses.

Actually, it might also be reasonable to ignore rule 9 if

scope(DA)  scope(source(DA)) and scope(DB)  scope(source(DB))

which seems reasonably equivalent to DA and DB are only reachable through
a NAT for both IPv4 and IPv6. The corner case is if the destination
is in a DMZ and can access both the Internet and local boxes directly,
but I don't think you can get the right answer for that atm anyway.

Doing it by changing Rule 9 to:

   Rule 9:  Use longest matching prefix.
   When DA and DB belong to the same address family (both are IPv6 or
   both are IPv4): If xCommonPrefixLen(DA, Source(DA)) 
   xCommonPrefixLen(DB, Source(DB)), then prefer DA.  Similarly, if
   xCommonPrefixLen(DA, Source(DA))  xCommonPrefixLen(DB, Source(DB)),
   then prefer DB.

   If scope(X)  scope(Y) then
xCommonPrefixLen(X,Y) = 0
   Else:
xCommonPrefixLen(X,Y) = CommonPrefixLen(X,Y)

would give reasonable behaviour, I think (preferring addresses that can
be reached without NAT first, then leaving addresses that require NAT
in the order received).

In essence, the problem is that comparing prefixes of real addresses
against addresses that will be NATed is not adding information, and is
possibly losing information -- eg, if your site DNS already orders A
addresses by prefix matching on your actual IP range.

 I already suggested that maybe rule 9 should be limited to the common
 prefix length of the netmask you're using.  An other option is that you
 extend rule 2 to have the same behaviour with ipv4, and that 10/8,
 172.16/12 and 192.168/16 should be considered organization-local.

Those are specified as having site-local scope in 3.2; but Rule 2 only
comes into play if one of the IPs returned by the nameserver is also
site-local anyway which isn't particularly useful.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#436093: Please decide on the ownership of the developers reference

[Anthony Towns]

On Mon, Aug 06, 2007 at 10:35:30AM +0200, Andreas Barth wrote:
 * Anthony Towns ([EMAIL PROTECTED]) [070806 10:18]:
  On Mon, Aug 06, 2007 at 09:16:23AM +0200, Andreas Barth wrote:
   1. at the moment something is commited to CVS, the changes are already
   active on the website;
  That seems an important point to me -- if that's the case, then committing
  is publishing, so changes simply shouldn't be committed until they've
  been reviewed.
 If it would be otherwise, I probably wouldn't care half as much.

So from other mails it looks like Raphael accepts that, and can come
to a reasonable procedure for contributing with you remaining as lead
maintainer with all that implies.

The only thing I don't recall having seen is what's the deal with
the rewrite into some other format? Is it in some other repository,
or...? Should patches be done against it, or the current cvs, or...?

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#367709: Call for vote: gcc: requesting libstdc++.udeb

[Anthony Towns]

On Fri, Jun 22, 2007 at 12:09:46AM +0100, Bdale Garbee wrote:
 The udeb structure was invented for debian-installer, and to date 
 Debian has not supported the use of udebs for any other purpose.

(With ftpmaster hat: I would expect non d-i uses of udebs to be in a
different section of the archive than main/debian-installer; it would
require some development work for that to be possible. I don't believe
there's been sufficient justification for non d-i udebs to warrant that
effort or the ongoing support of an additional udeb section)

 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
 [ 2 ] Choice 1: a libstdc++ udeb should be created as per bug #367709
 [ 1 ] Choice 2: a libstdc++ udeb should not be created despite bug #367709
 [ 3 ] Choice 3: Further discussion
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#341839: Call for vote: coreutils: md5sum output format

[Anthony Towns]

On Thu, Jun 14, 2007 at 12:45:16AM -0400, Bdale Garbee wrote:
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
 [ 3 ] Choice 1: the output of md5sum should be changed as per bug #341839
 [ 1 ] Choice 2: the output of md5sum should not change despite bug #341839
 [ 2 ] Choice 3: Further discussion
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

This horse has bolted already.

]   * Don't worry if md5sum from stdin adds a   - after the md5sum. Should
] make debootstrap more usable on non-Debian Linuxes.
] -- Anthony Towns [EMAIL PROTECTED]  Mon, 25 Jun 2001 18:38:35 +1000

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#353277: Call for vote: ndiswrapper: Move to contrib

[Anthony Towns]

On Thu, Mar 29, 2007 at 10:16:52AM -0600, Bdale Garbee wrote:
 - - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
 [ 2 ] Choice 1: ndiswrapper should move to contrib as per bugs #353277, 
 #353278
 [ 1 ] Choice 2: ndiswrapper should remain in main despite bugs #353277, 
 #353278
 [ 3 ] Choice 3: Further discussion
 - - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

Rationale: as per [0]:

The purpose of the ndiswrapper package is to provide an ABI layer on top
of the Linux kernel that is compatible with the interface for Windows
NDIS drivers, and that in order to provide this compatability layer,
no non-free software is required.

Cheers,
aj

[0] http://lists.debian.org/debian-ctte/2006/03/msg00037.html


signature.asc
Description: Digital signature

Bug#413926: Call for vote: wordpress: Should not ship with Etch

[Anthony Towns]

On Sun, Mar 25, 2007 at 07:27:13PM -0700, Steve Langasek wrote:
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
 [ 2 ] Choice 1: wordpress should not be included in etch due to bug #413269
 [ 1 ] Choice 2: wordpress should be included in etch in spite of bug #413269
 [ 3 ] Choice 3: Further discussion
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

Rationale: Neil McGovern [0] has indicated it should be supportable,
having already done testing-security support for it, and Kai Hendy as
the non-DD Debian maintainer has indicated both he and upstream [1]
are expecting to continue support the package. That seems sufficient to
count the package as security supportable for etch to me.

As far as advising versus overruling goes, I think inclusion in etch is
the RMs' decision, and without an opinion from them, we've got a case
of Developers' jurisdictions overlap so rather than trying to work
out whether it's fair to overrule the security team or the maintainer
(both of which I'd rather not), I'm just giving my opinion on what's
the best course of action.

Cheers,
aj

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413926;msg=99
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413926;msg=44


signature.asc
Description: Digital signature

Pending tech-ctte items

[Anthony Towns]

Hi all,

We've got the following items pending:

 - 353277, 353278: ndiswrapper should be in contrib
   Owned by Raul

   These were forwarded to the ctte on 20th Feb 2006, by Robert Millan.

   I proposed a resolution on this on 7th Mar 2006, in

 http://lists.debian.org/debian-ctte/2006/03/msg00037.html

   Steve Langasek (then ctte chair) proposed deferring a vote on that
   pending a version of Raul's proposal able to be voted on, which afaik
   still hasn't happened. There were four votes on my proposal at the
   time: in favour from me and Manoj, against from Ian and Raul.

 http://lists.debian.org/debian-ctte/2006/03/msg00039.html

   ndiswrapper currently remains in main.

 - 385665: fluidsynth needs non-free midi sound bank to function
   No owner

   Forwarded to the ctte on 20th Sep 2006, by Steinar H. Gunderson.

   Last response on 28th Sep 2006 by Guenter Geiger includes what appears
   to be instructions on how to create sound fonts using free tools. Do we
   consider that sufficient evidence that it doesn't need non-free stuff?

 - 341839: md5sum output format violates tech-ctte decision
   Owned by: Ian

   Forwarded to the ctte on 16th Dec 2005, by Peter Eisentraut

   echo | md5sum outputs 68b329da9893e34099c7d8ad5cb9c940  - instead
   of just 68b329da9893e34099c7d8ad5cb9c940. This matches the formats
   used by upstream, and by related tools such as sha1sum, sha256sum
   and sha512sum, as well as the output in current stable, testing and
   unstable. I think we should rescind the previous decision in favour of
   existing practice.

 - 366938: svn commit access to the d-i repo ...
   Owned by: Anthony

   Sent to the ctte on the 12th May 2006

   Andi proposed a resolution to endorse the d-i team's control over the
   repository:

   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366938;msg=145

   I suggest we vote on that.

 - 367709: requesting libstdc++ .udeb [for non-d-i use]
   Owned by: Anthony

   Sent to the ctte on 17th May 2006 by Sven Luther

   We have statements from the d-i team that they don't want non-d-i
   packages building udebs for the debian-installer/main component,
   and and from the gcc maintainer that he doesn't want to build extra
   packages.

   Andi proposed a resolution to not use the d-i section of the archive
   for this, and to encourage embedded people to keep looking into good
   formats:

   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367709;msg=20

   I suggest we vote on that.

 - 402793: tech-ctte: gst-ffmpeg links with its own private ffmpeg copy
   Not owned

   Sent to the ctte on 12th Dec 2006 by Josselin Mouette

   Steve indicated that he didn't think the maintainer should be overriden
   without the security team or release team indicating it's unsupportable
   in its current state on 15th Dec. There's been no followup since.

   I suggest we form that into a proposal and vote on it.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Renewed appeal to the technical committee about the FransAndCo.Vs.Sven dispute

[Anthony Towns]

On Mon, Nov 27, 2006 at 11:40:14AM +, Ian Jackson wrote:
 We can't do anything else other
 than recommend that the DPL please please please Do Something.

I think I'm going to deliberately abstain on any resolution that does
something of that nature. I'd kind-of like to abstain from being involved
in the discussion regarding it too (I'd rather just listen).

Cheers,
aj



signature.asc
Description: Digital signature

Re: ndiswrapper

[Anthony Towns]

On Fri, Sep 15, 2006 at 01:17:07PM -0400, Raul Miller wrote:
 I don't see why ndiswrapper should be different, in this regard,
 than uae.  

UAE requires a Kickstart ROM to be an Amiga emulator; apparently there's a
minimal free build-in [sic] Kickstart replacement, but presumably the
maintainer doesn't think that's sufficient for real use.

Other similar things that are in main include coldfire, dosbox, fceu,
gngb, pcsx, wine -- the difference there is also that they don't require
a non-free ROM to actually provide their emulation.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#366938: svn commit access to the d-i repo ...

[Anthony Towns]

On Wed, Jun 07, 2006 at 11:13:10AM +0100, Ian Jackson wrote:
 I think these are all political decisions implemented through
 technical means.  I think we can review the mechanisms used for access
 control (eg, we could with insist on the use svn-over-ssh instead of
 svn-over-ssl or vice versa) but we can't review the access control
 list which specifies who gets the ability to do what.

FWIW, I think the ctte can choose whether to review the decision or not,
and should generally choose not to.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#366938: svn commit access to the d-i repo ...

[Anthony Towns]

On Sun, Jun 04, 2006 at 07:02:51PM +0200, Andreas Barth wrote:
 3. Access controls to source code repositories are not something in the
regular domain of the Technical Committee.  However, in this case the
decision was delegated by the Project Leader to the Technical
Committee as appeal instance of the Project Leader's decision.

Access controls to source code repos hosted on .debian.org seem a
technical decision to me, so plausibly within the committee's domain. We
can, of course, decline to consider the question anyway. I wasn't
intending to delegate anything.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Anthony Towns]

On Fri, Mar 24, 2006 at 04:22:32PM -0500, Raul Miller wrote:
 On 3/23/06, Anthony Towns aj@azure.humbug.org.au wrote:
  On Mon, Mar 13, 2006 at 03:28:50PM -0500, Raul Miller wrote:
   On 3/7/06, Ian Jackson [EMAIL PROTECTED] wrote:
Why does contrib exist ?
   [essay elided.]
  So is there an alternate proposal to
  http://lists.debian.org/debian-ctte/2006/03/msg00037.html
  so we can have a vote and make a decision? AFAICS we've discussed this
  pretty thoroughly.
 I think your proposal conflicts with published policy, and with the obvious
 purpose of Config. 
  ^^  (Contrib, presumably)

I don't agree with either of those claims, though. It seems to me that
the way to express that disagreement would be for you to have a proposal
you support and to vote for that.

Cheers,
aj


signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Anthony Towns]

On Mon, Mar 13, 2006 at 03:28:50PM -0500, Raul Miller wrote:
 On 3/7/06, Ian Jackson [EMAIL PROTECTED] wrote:
  Why does contrib exist ?
 [essay elided.]

So is there an alternate proposal to

http://lists.debian.org/debian-ctte/2006/03/msg00037.html

so we can have a vote and make a decision? AFAICS we've discussed this
pretty thoroughly.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Anthony Towns]

On Wed, Mar 08, 2006 at 11:35:23AM +, Ian Jackson wrote:
 Anthony Towns writes (Re: Bug#353277: ndiswrapper in main):
  On Tue, Mar 07, 2006 at 07:39:01PM +, Ian Jackson wrote:
   Anthony Towns writes (Re: Bug#353277: ndiswrapper in main):
[draft resolution]
   I'm afraid I think that that's quite out of order.
   Constitution s6.3(3):
 3. Public discussion and decision-making.
Discussion, draft resolutions and amendments, and votes by
members of the committee, are made public on the Technical
Committee public discussion list. There is no separate secretary
for the Committee.
  The tweaks stuff were draft resolutions too, though... I don't see how
  it's feasible to have the rule be we can't do drafting work here, rather
  than just be any drafting work we do here has no constitutional meaning.
 Our discussions, which include drafting work, are supposed to be
 public.  The Committee isn't supposed to hide in secret and then come
 out with decisions.  `Discussion  [is] made public ...'.
 The `tweaks' stuff is to do with how the committee operates, and was
 similar enough to the question of appointments (which we can discuss
 in secret) that I let it slide.

Hrm, alright. Then I guess in future I don't think we should let that
slide. And hey, if we're going to have a rotating chair, appointments
don't matter much either and we could drop the -private list entirely :)

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#345067: ide-generic on poweprc

[Anthony Towns]

On Tue, Mar 07, 2006 at 02:35:59PM -0500, Raul Miller wrote:
 On 3/7/06, Sven Luther [EMAIL PROTECTED] wrote:
  On Tue, Mar 07, 2006 at 07:20:31PM +0100, Jonas Smedegaard wrote:
   Please see http://wiki.debian.org/LinuxKernelIdeProblem that I created
   today and have invited the kernel team and udev developers to improve
   on.
  An assembly of patent ...
 It looks to me like that's a wiki page.
 In other words, you can fix problems on it directly without needing to ask
 for help or permission.  

Which Sven's since done, leading the page to begin with:

] The below is a pathetic attempt by Jonas to justify his inactivity on
] this bug, it is composed of patently false claims, and more insidious
] falsehood, together with some truhtfull information.
] 
] Jonas is furthemore wrong in this, because he refused to apply the
] patch, because claiming caution for some hypothetical case he never was
] able to pinpoint, but didn't actually excercice the same caution when
] applying the original hack which force-loaded the ide-generic module,
] not caring if it was actually built or not. -- SvenLuther
]
] Sven -- Please sign your ranting. I've gone back and retroactively signed
] it for you -- JoeyHess

Jonas's last revision, without Sven's comments, is available at:

  http://wiki.debian.org/LinuxKernelIdeProblem?action=recallrev=4

From what I can see of that, the maintainer seems on track to solve the
problem. I don't see any great reason to overrule that process.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Processed: Escalating #345067 to the technical comittee, as the maintainer asked me to do so, and is unable or unwilling to do his job without this.

[Anthony Towns]

On Tue, Mar 07, 2006 at 02:03:17AM -0800, Debian Bug Tracking System wrote:
 Subject: Re: Processed: Escalating #345067 to the technical comittee, as 
  the maintainer asked me to do so, and is unable or unwilling to 
  do his job without this.

  reassign 345067 tech-ctte
 Bug#345067: [powerpc] ide-generic is not built on powerpc, yaird tries to 
 include it and fails
 Bug#343427: linux-image-2.6.14-2-powerpc: Installation fails
 Bug reassigned from package `yaird' to `tech-ctte'.

I can see there's some sort of dispute over this bug, but I can't see a
precise explanation of exactly what it breaks. 

Jonas Smedegaard's comment in #343427, in response to Sven Luther:

  The ide-generic module is not built on powerpc,
 In the _current_ _official_ kernel package in Debian, or in any
 sysfs-supporting powerpc Linux kernel ever, locally built or not?

seems to be the important question; and I gather the answer is that the
official kernel packages don't use it, but that some can. Contents-powerpc
seems to bear this out, as does my config-2.6.15-1-powerpc:

# CONFIG_IDE_GENERIC is not set

Has anyone at all spoken to the via82cxxx upstream about getting the
dependency information fixed so that this hack isn't needed in the
first place?

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#345067: jonas, you are being dishonest.

[Anthony Towns]

On Tue, Mar 07, 2006 at 02:15:56PM +0100, Sven Luther wrote:
 I am severly disapointed with you, and you are a liar by claiming that i

Sven, there is no need to call anyone a liar.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Anthony Towns]

On Thu, Mar 02, 2006 at 07:42:42PM -0500, Raul Miller wrote:
 On 3/2/06, Anthony Towns aj@azure.humbug.org.au wrote:
  On Wed, Mar 01, 2006 at 10:15:04PM -0500, Raul Miller wrote:
   Ok, we should probably find a different word to describe this
   relationship.
   Perhaps it could be phrased that ndiswrapper has a need for the presence
   of some software which is not available in debian main.
  But it doesn't -- ndiswrapper will sit there quite beningly if the non-free
  driver isn't present. It'll do everything it's supposed to -- link with the
  kernel and provide an ABI for other software -- without any errors.
 Ok, but that's not everything it's supposed to do.
 If that's all it needed to do then the code implementing the ABI
 could do (*0)= dump core and that would be fine.

Eh? If I found something that claimed to implement the C string library
(strcpy, strcmp, strstr, etc) but just dumped core everytime it was
invoked, I wouldn't say it implemented the ABI at all. Some ABI's leave
some behaviour undefined (such as free(x); free(x);), but none leave
all of it undefined.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Anthony Towns]

On Thu, Mar 02, 2006 at 09:21:33PM -0500, Raul Miller wrote:
 On 3/2/06, Anthony Towns aj@azure.humbug.org.au wrote:
  On Thu, Mar 02, 2006 at 07:42:42PM -0500, Raul Miller wrote:
   On 3/2/06, Anthony Towns aj@azure.humbug.org.au wrote:
But it doesn't -- ndiswrapper will sit there quite beningly if the 
non-free
driver isn't present. It'll do everything it's supposed to -- link with 
the
kernel and provide an ABI for other software -- without any errors.
   Ok, but that's not everything it's supposed to do.
   If that's all it needed to do then the code implementing the ABI
   could do (*0)= dump core and that would be fine.
  Eh? If I found something that claimed to implement the C string library
  (strcpy, strcmp, strstr, etc) but just dumped core everytime it was
  invoked, I wouldn't say it implemented the ABI at all. Some ABI's leave
  some behaviour undefined (such as free(x); free(x);), but none leave
  all of it undefined.
 For the case you described, it would not dump core.

It wouldn't dump core if I didn't use it; as soon as I did, it would
dump core, which would mean it didn't implement the ABI it claimed to,
whether I was using it or not.

We're getting into if a tree fell in a forest... territory here though.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Anthony Towns]

On Tue, Feb 28, 2006 at 01:35:11PM -0500, Raul Miller wrote:
  After the discussions so far, I'm inclined towards the following two views
  of our policy on this:
  * first, that dependencies are one way -- programs depend on
libraries, but libraries don't depend on the programs that use
them;
 I don't think that can really be true in the general case.  For example,
 we have the base system where pretty much everything in base has
 a mutual dependency on pretty much everything else in base.

wget and netcat are in base, but nothing else in the base system depends on
them.

But anyway, as I said to Ian, I'm not trying to deny the existance of
mutual dependencies -- obviously they exist. What I'm getting at is that
not all dependencies are mutual; just because a library isn't useful
without some application that uses it (maybe one you write yourself),
that doesn't mean it depends on having some such application installed.

  * and second, that programs that only operate when interacting with
non-free programs, whether over the net or via data files, aren't
considered to depend on those non-free programs.
 The issue I thought was important in the context of ndiswrapper was: what
 software has to be installed on the debian system for people to use
 ndiswrapper?
 I'm not sure that this general statement really refutes that position.

The above is the other stem I think's necessary to cover programs
suitable for main that wouldn't be useful in a world where all the
non-free software suddenly disappeared.

I don't have any problem with non-free software must be involved, but needn't
be installed on the system as a restatement of the second principle
above. It's independent of the first one though, which is the one that
affects ndiswrapper.

 But I think this case -- where root privileges are needed, in order to
 install non-free software, in order to make the package work the way that
 people typically think of as using it... I think this case is on the wrong
 side of that line.

I don't think whether root has to be used is a good line to draw --
putting an installer package in main that automatically downloads
a separate copy of the non-free software for each user than runs it
wouldn't be right, imo.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Anthony Towns]

On Wed, Mar 01, 2006 at 10:15:04PM -0500, Raul Miller wrote:
 Ok, we should probably find a different word to describe this
 relationship.
 
 Perhaps it could be phrased that ndiswrapper has a need for the presence
 of some software which is not available in debian main.

But it doesn't -- ndiswrapper will sit there quite beningly if the non-free
driver isn't present. It'll do everything it's supposed to -- link with the
kernel and provide an ABI for other software -- without any errors.

The drivers, on the other hand won't function without ndiswrapper (or Windows).

Similarly, if we could package the windows driver, we would write:

Package: videoXYZ-driver
Section: non-free/drivers
Depends: ndiswrapper

not

Package: ndiswrapper
Depends: videoXYZ-driver | video123-driver | videoBLAH-driver

We already do the relationships this way for USB drivers that access
the USB ports via libusb, eg, which are all packaged and in main so skip
the complications ndiswrapper raises.

Basically, I think it's right to say that the user has a need for the
driver, and the driver has a need for ndiswrapper. It's only because
of the user's need for a driver that anything non-free is involved;
ndiswrapper itself is quite happy without one (or with one of the toy
free ones).

For comparison, installer packages normally have a need for the non-free
software: if they don't have it, they can't install it in the first place.

(And thanks, I do think has a need is a helpful way of describing this)

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Anthony Towns]

On Tue, Feb 28, 2006 at 11:14:22AM +, Ian Jackson wrote:
 Anthony Towns writes (Re: Bug#353277: ndiswrapper in main):
  After the discussions so far, I'm inclined towards the following two views
  of our policy on this: 
  * first, that dependencies are one way -- programs depend on
libraries, but libraries don't depend on the programs that use
them;
 What, then, is the intended meaning when the policy manual talks about
 `wrappers' for non-free programs ?  (Feel free to say that the wording
 is suboptimal and shouldn't be read so closely.)

I believe the intended meaning is to cover installer packages -- ie things
that take a given non-free package and install it on your system for you. Those
packages will break if you don't have the non-free package, and that's where
the dependency lies.

There's a nasty line there, in that if ndiswrapper didn't just provide
an interface for drivers, but actually helped you install them it would
belong in contrib by my reading.

 Also, I think this approach is likely to be a hostage to fortune.
 Software systems are becoming ever more complex and `vertical'
 layering is nowadays sometimes absent - sometimes you can't really say
 which piece of software is `above' or `below' (ie, which depends on
 the other).

If they both work without the other, then there's no dependency; if
neither works without the other, then they mutually depend. I don't think
there's a problem there, though I mightn't have been clear enough above.

  * and second, that programs that only operate when interacting with
non-free programs, whether over the net or via data files, aren't
considered to depend on those non-free programs.
 As I said, I think there is a fundamental distinction between the case
 where the decision to use non-free software is made my the Debian
 user, and where it is made by someone else.  Do you agree or
 disagree ?  Do you think that's not relevant at all ?

I'm not actually sure what you mean here?

  That means that:
  (a) libraries that aren't used by any DFSG-free programs are okay
  for main, so packages like libamstd-ruby1.8 that provide a library
  that no package happens to use are still fine
 I don't follow the argument here at all.  A library can still be
 useful even if nothing in Debian depends on it, either because some
 older Debian package still depends on it, or because a user's own
 software depends on it.

Right. How about if the user's own software is all non-free though? And
if they're the only developer who uses that library, because they wrote
it themselves, and it's not actually all that great? And they distribute
their software far and wide and it's very famous?

In that example, the library is effectively useless without non-free software;
perhaps there are free toys you can use with it, but otherwise, the only point
to it is to run whatever that non-free app is.

Should it go in main? I think yes is the only practical answer.

You could say no, and then we'd have to remove all the libraries no one
actually uses for free software from main -- and that might be a win in
that it'd mean everything in main was useful, but would be heaps more
trouble than it was worth.

Or you could say no, but only if we notice it's being used almost
entirely for non-free stuff, rather than just being used for non-Debian
stuff,  but I don't think that's a good distinction to draw.

 The purpose of a library is not just to run binaries provided by other
 people; it is also to allow a user to build and then run their own
 programs.
 This is quite different from ndiswrapper unless you're going to claim
 that people are using it for driver development.

No -- I'm going to claim the opposite: that people /aren't/ using a bunch of
the libraries we've got in main for application development.

 Are there any other packages which are in a similar state to
 ndiswrapper by _both_ the criteria I set out and by your asymmetric
 dependency criterion ?

I'm not sure -- I don't use much non-free stuff on Debian. I'd guess that
some of the old libraries we keep around might be in a similar state --
not used for development, and not needed for free software. libdb1-compat,
perhaps.

Cheers,
aj



signature.asc
Description: Digital signature

Re: voting for the chair

[Anthony Towns]

On Mon, Feb 27, 2006 at 03:04:40PM -0600, Manoj Srivastava wrote:
 Of course, a GR to disambiguate section 6.1.7 would be OK too :)

I think we should consider this -- the constitution talks about the technical
ctte proposing resolutions (4.2(2)(2)), but if we're going to, we probably 
should
make sure we're able to commit to rotating chairs or different vote handling or
whatever else we think's appropriate too.

Cheers,
aj


signature.asc
Description: Digital signature

Re: Technical committee chair rotation, draft resolution

[Anthony Towns]

On Tue, Feb 21, 2006 at 12:20:11PM +, Ian Jackson wrote:
 THE COMMITTEE AND ITS MEMBERS RESOLVE AS FOLLOWS
 3. The intent is that the Chairmanship should rotate through the
committee in the following order,
Ian Jackson[Feb / Aug]
Steve Langasek [Mar / Sep]
Raul Miller[Apr / Oct]
Manoj Srivastava---
Anthony Towns  [May / Nov]
Andreas Barth  [Jun / Dec]
Bdale Garbee   [Jul]

(dates added)

Augh, we just agreed on a rotation, why a new one now? Downside to the
above: it schedules newbies and oldbies together rather than interspersing
them (Me then Andy; Bdale then Ian). 

Each Committee member will server for one calendar month UTC, and
then the cycle will repeat (starting again with Ian Jackson).

I don't think we're able to come to a decision on an issue in that brief
a timespan, and handing over issues begun by one chair to a new one seems
a guaranteed way of making things more inefficient than they need to be.

In particular, the devmapper issue was brought to the ctte's attention
on the 7th Dec and remains outstanding today, 11 weeks later. I brought
this issue up on the ctte-private list a month ago today, and we've been
pretty unanimous about at least the rotating chair aspect, but we still
don't seem to have a consensus on what we want, let alone a decision yet.

 4. The rota starts with Ian Jackson for February 2006.

Didn't you just step down as chair? 

   http://lists.debian.org/debian-ctte/2006/02/msg00038.html

That was how I took it, and I understand that's how Steve took it?

Your resolution doesn't address the possibility a tech ctte member is
secretary or DPL as far as I can see, but presumably should.

Cheers,
aj


signature.asc
Description: Digital signature

Re: Tech ctte tweaks

[Anthony Towns]

On Wed, Feb 15, 2006 at 09:49:21AM +1000, Anthony Towns wrote:
 Okay, Steve's meant to start today (in 20 minutes if we go by UTC),
 so Ian are you happy to step down, and does everyone want to send in their
 vote for new chair?
 Mine's: 1. Steve, 2. Bdale, 3. Andy, 4. Raul, 5. Me, 6. Ian, 7. Further 
 discussion

So Ian's stepped down, and Steve has four votes, with three people not
(yet) voting.  Which either means we have a winner already, or will when
voting closes.

  (1) Rotating the tech ctte chair
  - Feb 14th  Ian Jackson
 Feb 15th - Mar 31st  Steve Langasek
 Apr  1st - May 31st  Bdale Garbee
 Jun  1st - Jul 31st  Andreas Barth
 Aug  1st - Sep 30th  Raul Miller
 Oct  1st - Nov 30th  Anthony Towns
 Dec  1st - Jan 31st  Ian Jackson
 I vote yes...

In favour: Steve, Ian, Anthony; no votes against -- so that's enough to pass
when voting closes.

  (2) Requiring an implementation of proposals
  So I propose we establish a rule that we won't make decisions on issues
  that aren't ready for an immediate NMU when we make that decision.
 Also yes...

In favour: Steve, Anthony; Against: Ian -- currently that will pass, though
won't be particularly binding.

  (3) Advisory opinions from the chair
  So I propose we establish that our procedure in addressing issues is
  for the chair to quickly issue an initial opinion; and to only vote on
  issues when an official ruling is needed (eg, to overrule a maintainer)
  or when members of the tech ctte disagree.
 Also yes...

Looks like we'll have an alternate mechanism from the incoming chair,
so I'll change my vote to against, which gives us three against, none
in favour.

Cheers,
aj


signature.asc
Description: Digital signature

Re: Tech ctte tweaks

[Anthony Towns]

On Wed, Feb 15, 2006 at 11:23:19AM +, Ian Jackson wrote:
 Anthony Towns writes (Re: Tech ctte tweaks):
  On Sun, Feb 05, 2006 at 10:50:10AM +1000, Anthony Towns wrote:
  Okay, Steve's meant to start today (in 20 minutes if we go by UTC),
  so Ian are you happy to step down, and does everyone want to send in their
  vote for new chair?
 Why don't we just do this instead:

If we do it as well, instead of instead, Steve's chair immediately (you
stepping down, means there's four votes in favour out of seven possible,
and the outcome's decided).

Otherwise, Raul's vote has to be excluded so we're still waiting on an
outcome; and it's not entirely clear that any of the votes are binding
in any way :(

   (2) Requiring an implementation of proposals
   So I propose we establish a rule that we won't make decisions on issues
   that aren't ready for an immediate NMU when we make that decision.
  Also yes...
 I disagree with this as prviously stated.

As per http://lists.debian.org/debian-ctte/2006/02/msg3.html ?

   (3) Advisory opinions from the chair
   So I propose we establish that our procedure in addressing issues is
   for the chair to quickly issue an initial opinion; and to only vote on
   issues when an official ruling is needed (eg, to overrule a maintainer)
   or when members of the tech ctte disagree.
  Also yes...
 And this doesn't need a formal process.  Why don't we just have the
 chair try it out ?

Depends whether other members of the ctte agree to raise any objections
they have early, or arbitrarily later, perhaps only when it comes to a
vote. If we reliably do it early, then in the absence of objections,
people can rely on the chair's opinion; if we don't, they probably
can't. That needs a commitment from all of us, not just the chair though.

But either way the proof's in the acting, so there's no real difference.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Tech ctte tweaks

[Anthony Towns]

On Sun, Feb 05, 2006 at 10:50:10AM +1000, Anthony Towns wrote:

Okay, Steve's meant to start today (in 20 minutes if we go by UTC),
so Ian are you happy to step down, and does everyone want to send in their
vote for new chair?

Mine's: 1. Steve, 2. Bdale, 3. Andy, 4. Raul, 5. Me, 6. Ian, 7. Further 
discussion

Can we also get a vote from folks on the other proposals:

 (1) Rotating the tech ctte chair

 Changing chairs every two months would mean everyone would be chair over
 the course of the year; helping ensure that we notice people who aren't
 active in a timely manner, and distributing the load a bit more fairly.
 I propose we do this, and for concreteness propose the following rotation:

 - Feb 14th  Ian Jackson
Feb 15th - Mar 31st  Steve Langasek
Apr  1st - May 31st  Bdale Garbee
Jun  1st - Jul 31st  Andreas Barth
Aug  1st - Sep 30th  Raul Miller
Oct  1st - Nov 30th  Anthony Towns
Dec  1st - Jan 31st  Ian Jackson

I vote yes...

 (2) Requiring an implementation of proposals
 
 So I propose we establish a rule that we won't make decisions on issues
 that aren't ready for an immediate NMU when we make that decision.

Also yes...

 (3) Advisory opinions from the chair
 
 So I propose we establish that our procedure in addressing issues is
 for the chair to quickly issue an initial opinion; and to only vote on
 issues when an official ruling is needed (eg, to overrule a maintainer)
 or when members of the tech ctte disagree.

Also yes...

Cheers,
aj



signature.asc
Description: Digital signature