Anthony Towns writes ("Re: glibc's getaddrinfo() sort order"):
> 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 o
at has brought this question to the TC.
In any case, if the libc maintainer doesn't like the details of my
patch they'd be free to add their own (incorrect, IMO) warnings of
incompatibilties and even to include a rant about how idiotic the TC
is, or whatever. Or they could upload a
Anthony Towns writes ("Re: Call for Votes (Re: glibc's getaddrinfo() sort
order)"):
> I don't think the tech ctte should be authorising themselves to do NMUs
> under any circumstances.
Steve Langasek writes ("Re: Call for Votes (Re: glibc's getaddrinfo() sort
order)"):
> I agree with Anthony tha
Anthony Towns writes ("Re: Call for Votes (Re: glibc's getaddrinfo() sort
order)"):
> AFAICS we should be making a definitive statement wrt both Rule 9 and
> IPv6 [...]
My proposal makes a definitive statement to our libc maintainer about
Rule 9 and IPv6: we disapprove of rule 9 but do not overru
Steve Langasek writes ("Re: glibc's getaddrinfo() sort order"):
> [In all my comments below, I am assuming that we are focused on rule 9 as
> pertains to sorting of IPv4 addresses. A strict sorting of IPv6 addresses
> by length of prefix match is also questionable, but not so much so that I
> beli
Anthony Towns writes ("Re: glibc's getaddrinfo() sort order"):
> 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, an
Clint Adams writes ("Bug#438179: glibc's getaddrinfo() sort order"):
> On Mon, Sep 24, 2007 at 11:18:00AM +0100, Ian Jackson wrote:
> > COMMON BEHAVIOUR ON TODAY'S INTERNET IS THAT IMPLEMENTED BY
> > GETHOSTBYNAME.
>
> Common behavior for gethostbyname()
Ian Jackson writes ("Call for Votes (Re: glibc's getaddrinfo() sort order)"):
> There is apparently no counterproposal, so I hereby propose and call
> for a vote on the following resolution:
The one-week voting period has now finished.
Result:
Further Discussion.
The cho
Ian Jackson writes ("Re: Call for Votes (Re: glibc's getaddrinfo() sort
order)"):
> Result:
> Further Discussion.
I'd like to understand what there is left to discuss.
On the substantive level it seems to me that we have comprehensively
demonstrated that rule 9 for
Ian Jackson writes ("Re: glibc's getaddrinfo() sort order"):
> Taken together these reasons make it impossible to conclude in favour
> of IPv4. As I said some weeks ago, I think the point about
^ rule 9 for
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a su
I don't know if you've been following the argument on the TC list
about bug #438179. I think the Technical Committee are probably going
to rule that sid's glibc ought to be changed so that it does not
implement RFC3484 section 6 rule 9 prefix-length based sorting for
IPv4. This will restore the t
Anthony Towns writes ("getaddrinfo() behaviour"):
> So here's my understanding of where we're at.
Thanks.
> First, fact finding. Everything here should be able to be agreed by
> everyone.
I'm afraid I don't agree with all of the things you claim as facts,
and I don't agree with the analytical ap
at you'd be following the discussion on debian-ctte.
I'm sorry you hadn't. I'll start CCing [EMAIL PROTECTED]
Will that help ?
> On Fri, Sep 28, 2007 at 03:56:31PM +, Ian Jackson wrote:
> > I don't know if you've been following the argument on the TC
addrs according to rule 9 in getaddrinfo
> [2] Choice F: Further discussion
> -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
From: Ian Jackson <[EMAIL PROTECTED]>
Subject: Call for Votes (Re: glibc's getaddrinfo() sort order)
Date: Thu, 20 Sep 2007
Steve Langasek writes ("Re: getaddrinfo: DNS round robin vs RFC3484 s6 rule 9,
for etch"):
> Well when it comes down to it, /I/ don't like the way our mailing list is
> run; I think mails sent to bugs assigned to the tech-ctte should be
> unconditionally allowed through to the list, and this seems
Don Armstrong writes ("testing that signed mails get through (ignore)"):
> Trying to make sure that I've fixed the issue with signed mails (by
> keys in the d.o keyring) going through to this list.
I don't know exactly what you've done but we seem to be getting a fair
amount of spam through the li
Anthony Towns writes ("Re: getaddrinfo() behaviour"):
> 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 ma
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
Don Armstrong writes ("Re: testing that signed mails get through (ignore)"):
> That's debian-ctte-private; listmasters have nothing to do with that
> distribution alias. To my knowledge there hasn't been any spam sent
> through [EMAIL PROTECTED] recently.
Oh, err, yes, sorry. Hrmm. I wonder how
Anthony Towns writes ("Re: getaddrinfo() behaviour"):
> 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 consensu
-BEGIN PGP SIGNED MESSAGE-
(First sent to debian-ctte on the 17th of October, but lost:)
Since I mentioned it when I took up my job with Canonical I thought I
should share the fact that I'm changing jobs again. I'm qutting
Canonical to go and work for Xensource on Xen.
(Perhaps we shoul
-BEGIN PGP SIGNED MESSAGE-
(First copy, to debian-ctte on the 8th of November, was lost:)
I'm about to send another Call for Votes regarding getaddrinfo.
I'm writing separately in this message to explain what I think TC
members should do about the question of rationale.
I agree with that
-BEGIN PGP SIGNED MESSAGE-
No-one else on the committee has commented on this issue at all. Do
you have any opinions ?
Here is my draft, which I'm not proposing formally as yet:
1. This is a dispute about who should be allowed to use the name
`libconfig' (both as a library name as
-BEGIN PGP SIGNED MESSAGE-
This is a test message, which I'm sending because the ctte list has
been very quiet.
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: noconv
iQCVAwUBRzyYyMMWjroj9a3bAQGdIgQAnD5Yee8e1QdERGjQviCJz+gxpJelzBbH
R6QL6fSS5We6WMICTB6jmQ2utJnHaiynfEOQ/IaID8ngDiWF
-BEGIN PGP SIGNED MESSAGE-
OK, my experiments show that:
* Messages sent by me to the TC list without signing them
get silently thrown away.
* Messages I send signed by the key in the Debian keyring get
through.
Is this the intended configuration ? This seems to be the case sinc
-BEGIN PGP SIGNED MESSAGE-
(I'm resending this lost mail from the 8th of November, intending to
restart the 7-day clock:)
It seems that discussion on this has dried up. Although my very
similar proposal was defeated the first time, I think it probably by
now falls to me by default to pro
Please reply to if you get this email and let us know whether you are
in a position to transact TC business. We seem to have a problem
getting quorum and I'd like to know why.
(FYI, I was laid up in bed with a tummy virus all of last week.)
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
w
Anthony Towns writes ("Re: Call for Votes (was Re: glibc's getaddrinfo() sort
order)"):
> On Thu, Nov 15, 2007 at 07:16:17PM +, Ian Jackson wrote:
> > -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> > [ ] Choice X: Do not use ru
Manoj Srivastava writes ("Re: Call for Votes"):
> I am not sure it is right to just leave things to the
> maintainers, no matter what they chose, once we have been called in to
> make a ruling.
I agree absolutely. We should make a decision if we can agree. If we
can't agree with the re
-BEGIN PGP SIGNED MESSAGE-
Here's another signed test message.
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: noconv
iQCVAwUBR0yEwsMWjroj9a3bAQEyHQQAh4L0QREHGLWIyOQ/YKgKPpi35wKk3Bmg
zvNI4D2a5MQZWwaTyOabKfx3NXW03sT+uK4AdAf1OsI4msvJpCXSqXbSShRx3JbZ
jGFOOlpmka68caIJoGsZItZJwA6AEE7m
There has been little further discussion following my last message.
I think we just need to vote on this. Regardless of how finely
balanced the various options are, we need to make a decision.
So I hereby formally propose the set of resolutions and (unaccepted)
amendments implied by this DRAFT B
Andreas Barth writes ("Bug#441200: libconfig name clash"):
> What are the reasons to also vote about a procedure for the new name,
> and not leave that to the default mechanismns?
Well, if we say nothing at all then at least one of the two parties
has suggested they may pick the name `libconfig1'.
-BEGIN PGP SIGNED MESSAGE-
This time can we _please_ try to get quorum ? You must send in your
vote within 7 days of me sending this message, for it to count, ie by
approximately 2007-12-06 19:50 +.
-8<-
1. RFC3484 s6 rule 9 should not be applied to IPv4 addresses
by Debian sy
Anthony Towns writes ("Bug#441200: libconfig name clash"):
> [stuff]
Thanks for that research, which is useful and interesting.
So just to be clear, you conclude as I did that both packages should
be required to select new names ?
> AFAICS neither libdebug nor libconfig have any reason to be pac
Peter Palfrader writes ("Re: Bug#412976 repoened - reassign tech-ctte
(mixmaster /etc/default/*)"):
> Summary of current status:
>
> o The mixmaster package provides both the client and server functionality.
> o By default the server part (running a remailer) is not enabled.
> o To configure mixm
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.
Here is a draft resolution and rationale.
Ian.
-8<-
(1) The REMAIL option should not be supplanted or supplemented by
anything in an /etc/default file. The current behaviou
Anthony Towns writes ("Re: Call for Votes (getaddrinfo)"):
> 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 you think that RCness (or desire to fix in stable) is relevant,
sur
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 t
Thanks to Jari for confirming agreement with Peter Palfrader's
summary, and for clarifying what is being requested. I don't think
anything more needs to be said about this.
So I hereby formally propose the draft resolution below. I'll give
other members of the TC a few days to weigh in (in parti
Ian Jackson writes ("Re: mixmaster /etc/default/*"):
> 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 enoug
Anthony Towns writes ("Re: mixmaster /etc/default/*"):
> 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 w
Anthony Towns writes ("Old tech-ctte bugs"):
> * #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
Steve Langasek writes ("Re: TC voting and amendment procedure"):
> In the present case neither of the non-FD options are satisfactory to me
> because as I wrote in <[EMAIL PROTECTED]>, I think
> rationale here is very important.
As I responded in my mail of Sun, 23 Sep 2007 16:23:54 +0100,
I th
Anthony Towns writes ("Re: Bug#441200: libconfig name clash"):
> I can't see any record of anyone suggesting [libconfig1] though, and
> I'd really hope that it wouldn't be accepted at NEW.
See #438683 where otherwise sensible people are suggesting using the
name libconfig1 for the new library due
I hereby call for a vote on the resolution below, which I sent round a
draft of on Friday and formally proposed yesterday:
-8<-
(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 e
Florian Weimer writes ("Re: Bug#412976 repoened - reassign tech-ctte (mixmaster
/etc/default/*)"):
> Really? Won't upgrades re-enable disabled services if update-rc.d is
> used?
Only if you delete _all_ of the links. If you leave the K links in
the shutdown and reboot runlevels, they will not b
Here's my latest draft of a libconfig resolution. No-one seems to be
suggesting that either package is entitled to the name so I have
removed that option.
Thanks to AJ for detailed feedback. I've taken out the process for
the TC approving names and replaced it with a request to the
ftpmasters.
Kurt Roeckx writes ("Re: Bug#412976 repoened - reassign tech-ctte (mixmaster
/etc/default/*)"):
> It is documented in the update-rc.d manpage:
>If any files /etc/rcrunlevel.d/[SK]??name already exist then
>update- rc.d does nothing. The program was written this way
>so
Anthony Towns writes ("Re: TC voting and amendment procedure"):
> 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. [...]
I thought that in your message of 2 Dec 2007 11:13:30 +100
Anthony Towns writes ("Re: Bug#441200: libconfig name clash"):
> On Sun, Dec 02, 2007 at 10:00:31PM +, Ian Jackson wrote:
> > See #438683 where otherwise sensible people are suggesting using the
> > name libconfig1 for the new library due to the TC's inactivity
Ian Jackson writes ("Bug#441200: libconfig name clash"):
> Here's my latest draft of a libconfig resolution. No-one seems to be
> suggesting that either package is entitled to the name so I have
> removed that option.
Have any of the rest of the committee (besides A
I think we probably have enough bandwidth (or will do shortly) to take
on another item from our todo list. #429671 on username policy seems
to me to be where we can most obviously improve the situation so I'm
going to start there.
The problem which Marc Haber (Exim maintainer) is trying to solve
Anthony Towns writes ("Re: Call for Votes (Re: mixmaster /etc/default/*)"):
> This bug hasn't been reassigned to the committee so we don't have any
> business ruling on it.
?
That seems to be an oversight on the part of the petitioner.
For the record, I agree with everything Steve has said in r
Andreas Barth writes ("Re: Call for Votes (Re: mixmaster /etc/default/*)"):
> I assume the voting means "we are not overriding the maintainer", i.e.
> this vote doesn't restrict the right of the maintainer to adjust the
> behaviour as he considers appropriate.
Absolutely.
For the avoidance of any
Bdale Garbee writes ("Re: Package-created usernames"):
> The second is whether it's acceptable for a Debian package to
> *require* a specific username. There seems to be at least an
> implication that if the namespace clash potential is eliminated or
> significantly reduced, that this would remove
Steve Langasek writes ("Re: Call for Votes (Re: mixmaster /etc/default/*)"):
> On Sun, Dec 02, 2007 at 10:13:38PM +, Ian Jackson wrote:
> > [1] Choice K: Keep current behaviour and existing policy, as above.
> > [2] Choice F: Further discussion
>
> I agree
Anthony Towns writes ("Re: TC voting and amendment procedure"):
> The substantive questions haven't been explored. I've been the only one
> doing that, and we _remain_ with absolutely no evidence [...]
Well, I think it must be clear to you that I (and others on the
committee) disagree.
The questi
Ian Jackson writes ("Call for Votes (getaddrinfo)"):
> -8<-
>
> 1. RFC3484 s6 rule 9 should not be applied to IPv4 addresses
> by Debian systems, and we DO overrule the maintainer.
> 2. RFC3484 s6 rule 9 should not be applied to IPv6 addresses
> by Debi
reassign 438179 glibc
thanks
The Technical Committee has decided as follows:
1. RFC3484 s6 rule 9 should not be applied to IPv4 addresses
by Debian systems, and we DO overrule the maintainer.
2. RFC3484 s6 rule 9 should not be applied to IPv6 addresses
by Debian systems. We do NOT
Ian Jackson writes ("Re: Call for Votes (getaddrinfo)"):
> Thus X wins and the resolution between -8<- above has been passed,
> overruling the maintainer.
I think we should send our rationales, including dissents, to the bug
report. I've collated the opinions that people
Steve Langasek writes ("Re: Call for Votes (getaddrinfo)"):
> On Thu, Nov 29, 2007 at 07:51:37PM +, Ian Jackson wrote:
> > This time can we _please_ try to get quorum ? You must send in your
> > vote within 7 days of me sending this message, for it to count, ie by
>
Andreas Barth writes ("Re: Call for Votes (getaddrinfo)"):
> * Anthony Towns ([EMAIL PROTECTED]) [071207 03:46]:
> > We don't. See also
> >
> > http://lists.debian.org/debian-ctte/2004/05/msg00027.html
>
> Frankly speaking, I consider it a bug that for a 3:1 supermajority we
> need a 4:1 vot
Aurelien Jarno writes ("Bug#438179: fixed in glibc 2.7-4"):
> reopen 438179
> thanks
..
> We have followed the decision of the tech-ctte before knowing the
> decision was not correct.
I'd just like to put on record hee my apology for my mistake.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTE
Just a FYI that I'm back now (I was away over Christmas) but still 474
emails behind so I'm not likely to get fully caught up until the weekend.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Florian Weimer writes ("Re: Bug#412976 repoened - reassign tech-ctte (mixmaster
/etc/default/*)"):
> The manpage also says:
> | System administrators are not encouraged to use update-rc.d to manage
> | runlevels.
>
> My experience with update-rc.d has been mixed at best. Removing the S
> links m
Anthony Towns writes ("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""):
> [stuff]
I've been skimreading this subthread and I have to say I'm not quite
clear about
Bdale Garbee writes ("Re: Package-created usernames"):
> After digesting the replies here and some off-list discussions, I
> now agree that while it is desireable for packages to be flexible about
> usernames to support the kinds of situations I described, requiring all
> Debian packages to be f
So here's a straw man draft for a decision on package-created
usernames:
-8<-
RUBRIC
1. We exercise our power in Constitution 6.1(1) to specify the
contents of Debian policy documents, and that in 6.1(5) to
offer our opinion.
2. Maintainers of policy documents should consult i
I've posted to debian-vote about this. I think we need to look into
this urgently unless we can find a time when we can get five people to
all vote on the libc resolver issue at once.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PR
Aurelien Jarno writes ("Re: RFC3484 rule 9 active again in glibc 2.7-5."):
> Upstream has committed a fix in the CVS (without telling anybody) so
> that for IPv4 addresses rule 9 is only applied when source and
> destination addresses are in the same subnet. I guess this is very close
> to the want
Aurelien Jarno writes ("Re: RFC3484 rule 9 active again in glibc 2.7-5."):
> An IP which uses the same IP range as your computer, as defined by the
> netmask. In short a local server which can be reached without a
> gateway.
Ah. I see.
So what you mean is that it will now:
* prefer a server in
Aurelien Jarno writes ("Re: RFC3484 rule 9 active again in glibc 2.7-5."):
> IP on different subnet are not sorted, IP on some local subnet are
> sorted by a longer common prefix with the interface address.
Err, pardon my language, but WTF ?!
What on earth is the justification for that ?
Ian.
Many of you will have already seen that I have decided to unilaterally
re-add myself to the list of dpkg maintainers and unilaterally remove
Guillem Jover. My reasons are explained in that mail there and I
don't want to go into them in detail here.
But there are two issues that are relevant to th
Kurt Roeckx writes ("Re: Functionality of the committee, and maintainership
disputes"):
> So you'll atleast need to change the constitution for that.
Yes. There are other bugs that need fixing too.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? C
dpkg is now forked, as you will be aware.
Guillem is continuing to commit to what he and Raphael regard as the
master official dpkg tree, changes which are reformatting,
reorganisation, and so forth.
As a matter of urgency, I would like the him to be asked to stop this
immediately. It will make
Raphael Hertzog writes ("Re: Code reformatting"):
> On Wed, 12 Mar 2008, Steve Langasek wrote:
> > That's a fair criticism, but I don't think it changes the fact that making
> > style changes while there's a major branch merge outstanding is precisely
> > the wrong thing to be doing, because it dir
Russ Allbery writes ("Bug#484841: Should /usr/local be writable by group
staff?"):
> The dispute is over the following text in Debian Policy:
>
> The `/usr/local' directory itself and all the subdirectories created
> by the package should (by default) have permissions 2775
> (group
Often people come to the TC just wanting a second opinion and a new
voice, perhaps to inject fresh insight into a stale discussion. We
normally seem to be reasonably good at this task provided the answer
to the original question is reasonably tractable, although we are
rather slow.
But we're hope
Andreas Barth writes ("Re: Technical committee workflow"):
> Ian Jackson (i...@davenant.greenend.org.uk) [081231 18:20]:
> > * The Rapporteur discusses the issue - off the main TC list - with
> >the various parties. debian-devel might be a good place, with
> >
Joerg Jaspert writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in
Debian"):
> Criteria that speak against inclusion:
> - no real upstream
I don't think that this is necessarily a showstopper. We have many
important packages in Debian that have defunct or completely absent
upstreams, so t
Raphael Hertzog writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in
Debian"):
> On Thu, 01 Jan 2009, Joerg Jaspert wrote:
> > Yet, we do see that there are people who want Qmail, and instead of
> > maintaining it in an own repository want it in Debian. As it is unlikely
> > that the positi
Raphael Hertzog writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in
Debian"):
> I'm particularly uneasy with letting the ftpmasters decide
> what's acceptable in the Debian archive on some non-usual policy
> requirements that can be difficult to justify.
I'm not uneasy with this at all.
Andreas Barth writes ("Re: Technical committee workflow"):
> * Ian Jackson (i...@davenant.greenend.org.uk) [090106 01:24]:
> > Andreas Barth writes ("Re: Technical committee workflow"):
> > > I'd like to see the discussion either on list or in the releva
..)
Raphael Hertzog writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in
Debian"):
> On Tue, 06 Jan 2009, Ian Jackson wrote:
> > I'm not uneasy with this at all. The ftpmasters' job is not to decide
> > the policy and then implement it without discretion.
Andreas Barth writes ("Proposed constitution fix for n+1-majorities"):
> this is a proposal to fix the n+1-bug in the constitution:
>
> In A.6.3.2, this sentence is changed:
> 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).
> to:
Steve McIntyre writes ("Re: Stepping down from tech ctte"):
> On Mon, Jan 05, 2009 at 04:08:33PM +1000, Anthony Towns wrote:
> >So thanks for the privelege of appointment, and best of luck for the
> >future, y'all.
Yes, thanks, Anthony.
> For the rest of the TC: this means you're down to 5 member
hin 7 days
4. After no more than 7 days we will vote once again, in
a single ballot, on Bob's report and any alternative
from Charlie
5. The queue is now as follows
Alice Bob (joint head of queue)
Charlie
Steve Langasek writes ("Confirmation vote for Don Armstrong"):
> While both Russ and Don have enjoyed the support of the Technical Committee
> in private discussions and I don't see a confirmation vote for them being
> anything more than a formality, under 6.3.4 of the constitution it is a
> formal
Steve Langasek writes ("Confirmation vote for Russ Allbery"):
> While both Russ and Don have enjoyed the support of the Technical Committee
> in private discussions and I don't see a confirmation vote for them being
> anything more than a formality, under 6.3.4 of the constitution it is a
> formali
Anthony Towns writes ("chiark -ctte copies"):
> I'm still getting duplicates of the -ctte lists via:
Steve Langasek writes ("Re: chiark -ctte copies"):
> I think this was something Ian set up to make sure the TC members were never
> unsubscribed from the list accidentally? Which has never happene
Raphael Hertzog writes ("Re: Technical committee workflow"):
> On Sat, 10 Jan 2009, Ian Jackson wrote:
> > Here's a first draft of the procedural resolution. Sorry it's so long
> > but I couldn't see how to make it shorter.
>
> It looks mostly fine.
Andreas Barth writes ("Re: chiark -ctte copies"):
> * Ian Jackson (i...@davenant.greenend.org.uk) [090113 01:58]:
> > Andreas and Raul: are you subscribed some other way ? If you are then
> > I can discontinue this alias. If you would like to continue to be
> > su
Bdale Garbee
member Russ Allbery
member Don Armstrong
member Andreas Barth
member Ian Jackson
member Steve Langasek
member Manoj Srivastava
And of course a warm welcome to Don and Russ.
Ian.
--
To UNSUBSCRIBE, email to deb
Gerrit Pape writes ("Re: Bug#422139: Please supply a sysvinit script"):
> Yes, sure. If there's an init script that's well integrated into the
> git packages contributed, I have no problem to apply the patch to the
> git-core packages. As I'm not that motivated, and sometimes also short
> on time
Don Armstrong writes ("Re: Bug#484841: staff group root equivalence"):
> Yeah, but by default, if you have staff access, you can easily gain
> root access, so there's really no distinction between the two. [In
> Debian, this could be done by shoving in a special /usr/local/bin/awk
> to trap cron.da
Andreas Barth writes ("Call for votes (was: Bug#484841: staff group root
equivalence)"):
> | 1. Keep /usr/local writeable by group staff (i.e. leave things as they
> | are).
>
> | 2. Decide to change the default so that /usr/local is not writeable by
> | group staff anymore. This change should o
Andreas Barth writes ("Re: Bug#573745: python maintainance: next steps"):
> For the initial setup, I would like to have people in the core team
> that are ok by both Matthias and the people who brought this to the
> tech ctte (e.g. you). If that doesn't work out, we'll of course decide
> who is in
(Redirected off the bug report as the BTS makes a poor mailing list
archive for the kinds of extensive threads that TC discussions
produce.)
Eugene V. Lyubimkin writes ("Bug#582423: tech-ctte: reaffirm that violating
Debian Policy deserves RC bug"):
> Please reaffirm that Debian bug #575786 again
Sandro Tosi writes ("Re: Bug#573745: python maintainance: next steps"):
> Please also understand that not receiving any update
> could give the impression that nothing is being done (that turned out
> it's not this case, but still), so a periodic update like "we're still
> talking to people, don't
Goswin von Brederlow writes ("Re: Bug#582423: tech-ctte: reaffirm that
violating Debian Policy deserves RC bug"):
> Just to make sure that means now the following is to be used, right?
Thanks for the helpful presentation of the questions.
Typically the situation involves an old package and a new
301 - 400 of 1203 matches
Mail list logo
