Clint Adams writes ("Re: Bug#573745: python maintainance: next steps"):
> On Fri, May 21, 2010 at 05:13:35PM +0100, Ian Jackson wrote:
> > So can I make a suggestion ? How about we have people send in
> > privately names that you think would make excellent candidates.
> >> Action | A Flags | B Flags
> >> +---+-
> >> Move file from A to B | Depends: B (>=) | Replaces: A (<<)
> >> | or Breaks: B (<<) |
> >> | as
Just to clarify, the inclusion of #582755 in the Subject line for this
conversation seems to be a red herring.
#582755 is a bug against dnscache-run complaining about the fact that
it edits /etc/resolv.conf, and has not been escalated to the TC.
Ian.
--
To UNSUBSCRIBE, email to debian-ctte-req
Steve Langasek writes ("Re: Bug#562945: Bug#582755: Bug#562945: fails to
install"):
> In summary, my proposal would be to:
>
> - decline to override the runit-run maintainer, whose use of debconf is
>discouraged but /not/ forbidden by Policy
> - advise the Policy maintainers to proceed with
I wrote:
> Steve Langasek writes ("Re: Bug#562945: Bug#582755: Bug#562945: fails to
> install"):
> > In summary, my proposal would be to:
> >
> > - decline to override the runit-run maintainer, whose use of debconf is
> >discouraged but /not/ forbidden by Policy
> > - advise the Policy main
Andreas Barth writes ("Bug#560238: tech-ctte: Default value for
net.ipv6.bindv6only sysctl"):
> Having said this, I would like to call for an vote with the options
> A set net.ipv6.bindv6only to 0
> B set net.ipv6.bindv6only to 1
> C further discussion
> unless someone from the tech ctte sees the
Russ Allbery writes ("Bug#560238: tech-ctte: Default value for
net.ipv6.bindv6only sysctl"):
> Having a different default on BSD than on other platforms strikes me as
> asking for trouble (in particular, asking for obscure portability issues
> to BSD systems that most developers don't test on).
I
Andreas Barth writes ("Bug#560238: tech-ctte: Default value for
net.ipv6.bindv6only sysctl"):
> Hm. As it currently looks to me, the decision was delegated to us. If Marco
> removes that delegation, that'd be fine with me. If not, we need to
> make a decision (at least I believe it's sensible to n
Josselin Mouette writes ("Re: Bug#587956: netbase: Does not cleanup bindv6only
upon upgrades"):
> Quick summary for the committee: netbase removed the infamous
> bindv6only=1 setting in the latest version, but the file remains upon
> upgrades from affected versions.
I see.
What would be needed t
Sandro Tosi writes ("Re: Bug#573745: Please decide on Python interpreter
packages maintainership"):
> Also, an additional level of "management" has to be well received from
> who has to be managed: are we really sure Matthias will follow even
> controversial decisions (so in opposition to some of
I wrote:
> I don't think we are considering adding an additional layer of
> management. Currently the person in charge is Matthias; he is the
> maintainer of python2.6 et al.[1]
>
> We would hand the maintainership of these packages to the new team.
We still don't have a new team. The only cohe
Joachim Wiedorn writes ("Bug#587886: future of maintaining of the bootloader
LILO"):
> because of the discussions of the last weeks mostly on debian-devel I
> have sent this bug report:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587886
> to the Technical Committee of Debian to find a sol
Andreas Barth writes ("Re: Bug#573745: Please decide on Python interpreter
packages maintainership"):
> * Ian Jackson (ijack...@chiark.greenend.org.uk) [100705 15:02]:
> > I wrote:
> > > I don't think we are considering adding an additional layer of
> >
severity 562945 serious
reassign 562945 runinit-run
thanks
Holger Levsen writes ("Bug#562945: ping"):
> AFAICT the case was quite clear, so whats left to do here?
I think there's nothing more for the TC to do. The runinit-run
maintainer can have the bug back. I'm going to mark it severity
serio
The package runinit-run, if successfully installed, generally breaks
the system by breaking booting. The administrator is supposed to fix
up the boot arrangements by converting startup scripts etc. after
installing runinit-run.
The administrator's attention is drawn to this by a debconf question:
Ian Jackson writes ("Bug#587886: future of maintaining of the bootloader LILO"):
> I've caught up on all of this now. I'm not sure I quite understand
> the position of the current lilo maintainers. In
> http://lists.debian.org/debian-devel/2010/05/msg00769.html
William, thanks for replying with your position and stating it very
clearly. It's very helpful for us to know exactly what you think.
William Pitcock writes ("Re: Bug#587886: future of maintaining of the
> bootloader LILO"):
> [Ian Jackson:]
> > I've caught up on
William Pitcock writes ("Re: Bug#587886: future of maintaining of the
bootloader LILO"):
> Hi,
> > If you still think that there is some really hard to fix image size
> > limitation with lilo, could you please provide a more specific
> > reference.
>
> For the most part, it is worked around by us
dave b writes ("Bug#552688: Please decide how Debian should enable hardening
build flags"):
> Hi I am just going to say that as a debian user,
Thanks for your contribution, but please, this list and bug is for
technical discussion and not for users' expressions of interest.
We don't need to be c
Joachim Wiedorn writes ("Bug#587886: future of maintaining of the bootloader
LILO"):
> Finally it would be nice we could move the new Debian packages into
> Debian unstable ...
I agree that Joachim and Matt Arnold should be made the joint lilo
maintainers. Would other TC members please express a
Debian Bug Tracking System writes ("Processed: reassign 604977 to linux-2.6,
reassign 604979 to linux-2.6"):
> Processing commands for cont...@bugs.debian.org:
Hrm, I see you reassigned them. I closed them, basically on the
thesis that the odds of being able to turn a report from this
submitter
Don Armstrong writes ("Bug#587886: future of maintaining of the bootloader
LILO"):
> Is there any objection to starting the voting process on this issue
> with the options presented in
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587886#55 ?
No, I don't think so. There's nothing more to be
Ian Jackson writes ("Bug#587886: future of maintaining of the bootloader LILO"):
> No, I don't think so. There's nothing more to be said.
>
> > [for reference:
> >
> > A. lilo should be removed. In the meantime, William is to be sole
> >
Kurt Roeckx writes ("Re: Bug#587886: future of maintaining of the bootloader
LILO"):
> I'd like to point out that neither of your votes are signed.
This is true. But there is no requirement for TC members' votes to be
signed. If there were any doubt about whether my vote was a forgery I
would g
conal writes ("Bug#611030: tech-ctte: Audio cd's won't mount"):
> Package: tech-ctte
> Severity: important
...
> Audio CD's won't mount and don't appear on the desktop or at their mount
> point. DVD's appear on the desktop and at their mount point. Audio CD's are
> not visible to to totem-xine or
Stefano Zacchiroli writes ("Bug#573745: ping"):
> 2 more months have passed, ... time for another ping :-)
I have to say I'm very disappointed that we haven't managed to do a
better job of this. We need to find a way to make this decision which
does not become irretrievably blocked.
AIUI at the
Stefano Zacchiroli writes ("Bug#573745: ping"):
> Let's assume for a moment (very hypothetically!) that a team can be
> found which both includes the current maintainer and has rough consensus
> on -python. Would the CTTE be willing to establish such a team as
> Python interpreter maintainers, eve
Steve Langasek writes ("Re: Bug#573745: ping"):
> Do you mean that you would get a *private* ack from the current maintainer,
> but no public one?
I am assuming that we are likely to get no ack at all.
> As commented in my previous mail, I don't believe that a maintenance *team*
> can be formed w
Thomas Schmidt writes ("Bug#625298: tech-ctte: iceweasel with Tor can't
remember used tabs"):
> Package: tech-ctte
> Severity: important
Bug reports should not be submitted directly to the technical
committee in this way. We as a project do not have a shortage of bug
reports, and it is not an ap
? | Toni Stoev writes ("Arbitrary-length numbers"):
> Hello members of the Debian Technical Committee,
>
> I would like to discuss a complex issue with you that could take up
> several swirls of discussion, inclusively in other places with other
> people.
This is not really the purpose o
Steve Langasek writes ("Re: Arbitrary-length numbers"):
> If you really think Debian in the right
> place for this discussion, then you should discuss with the Debian developer
> community at large via debian-devel or debian-project.
I think you shouldn't have suggested this. debian-devel is not
(Sorry to just join this conversation; I was on holiday in Wales,
which was excellent.)
Raphael Hertzog writes ("Re: Request for TC to rule on a course of action for
supporting build-arch"):
> I was going to suggest that. The way I prepared the corresponding patch
> (the one you called "auto-dete
Russ Allbery writes ("Re: draft ballot: please rule on how to implement
debian/rules build-arch"):
> Steve Langasek writes:
> > BTW, another option for the long-term solution which we haven't really
> > addressed head-on is that dpkg-buildpackage could detect whether both
> > arch-indep and arch-
Guillem Jover writes ("Re: draft ballot: please rule on how to implement
debian/rules build-arch"):
> In the thread in debian-policy I also proposed [0] another small variation
> for this, which would imply a two stage transition, reducing the immediate
> simultaneous FTBFS. Jakub Wilk provided nu
Raphael Hertzog writes ("Re: draft ballot: please rule on how to implement
debian/rules build-arch"):
> A squeeze system with a backported dpkg without auto-detection will fail
> to build many squeeze packages even if we manage to fix them all in sid.
> That would be a sad state that would require
Andreas Barth writes ("Bug#587956: Call for vote on "cleanup bindv6only""):
> * Andreas Barth (a...@not.so.argh.org) [110730 17:15]:
> > as I think after release of squeeze it is just to late to cleanup
> > bindv6only, so I intend to call for vote with the following options:
> >
> > 1. We don't ov
Andreas Barth writes ("Bug#636783: proposed constitution fix for super-majority
within the tech ctte"):
> > > + 2. An option A defeats the default option D provided that:
> > > + (a) V(A,D) is strictly greater than V(D,A); and
> > > + (b) if a supermajority of N:1
Josip Rodin writes ("Bug#640874: leave: debian/rules is not a Makefile"):
> Since my reasoning here didn't seem to leave a particular positive dent with
> those tech-ctte members who have responded so far, I would just like to
> solicit Ian Jackson's input, given his role in defining and implementi
Bdale Garbee writes ("Bug#658341: Call for Vote: upload of multi-arch enabled
dpkg (in time for wheezy)"):
> A. [...]
>February 6th: upload to experimental for general testing
>February 20th: upload to unstable
...
> B. The Technical Committee declines to override the decision of the dpkg
Don Armstrong writes ("Bug#607368: Call for Vote: Kernel ABI numbering policy"):
> I call for a vote on the kernel ABI numbering policy bug with the
> following ballot:
>
> A) The technical committee declines to override the kernel maintenance
> team's ABI numbering policy.
>
> B) Further discuss
Andreas Barth writes ("Re: Bug#636783: proposed constitution fix for
super-majority within the tech ctte"):
> Good. In that case I think we should just call for votes, and vote it,
> and do the other topics in different GRs?
This is a fine idea but if we are going to do several GRs we should
run
Russ Allbery writes ("Re: Bug#636783: proposed constitution fix for
super-majority within the tech ctte"):
> > * Explicitly being allowed to have private discussions on the subject
> > of who should maintain a particular package. The options should be:
> > - private discussions when we feel
There is one wrinkle we may need to sort out.
The resolution procedure for GRs contemplates amendments being
accepted "by the proposer". Particularly for my advisory proposal, it
seems that discussion about wording might produce amendments we would
like to accept.
But we don't want to have a TC
Russ Allbery writes ("Bug#629385: Request for TC to rule on a course of action
for supporting build-arch"):
> Hearing no objections, I call for a TC vote on the following ballot:
>
> A. dpkg-buildpackage, when doing a binary-only build (-B), should probe
>the package with "make -qn" to see if
Don Armstrong writes ("Bug#636783: proposed constitution fix for super-majority
within the tech ctte"):
> On Tue, 20 Mar 2012, Russ Allbery wrote:
> > I would be willing to make time to attend a public IRC meeting for
> > this purpose.
>
> I would as well. I believe we are all primarily in Europe
Russ Allbery writes ("Bug#640874: leave: debian/rules is not a Makefile"):
> Russ Allbery writes:
> > Based on Ian's last response, I think the ballot has two options plus
> > further discussion, since I'm quite sure that we're not going to outlaw
> > dh:
>
> > A. debian/rules is not required to
Russ Allbery writes ("Bug#640874: leave: debian/rules is not a Makefile"):
> Russ Allbery writes:
> > Russ Allbery writes:
> >> B. The Technical Committee affirms the Debian Policy requirement that
> >>debian/rules must be a makefile. All packages in the archive,
> >>including leave, are
Joey Hess writes ("Re: Bug#597050: GNU parallel, name conflict with moreutils"):
> I object to involving the technical committee. There is not a technical
> disagreeement here; there is a lack of work here.
Ah, I'm sorry, I must have misunderstood your comments in #597050.
I took them for an obj
Joey Hess writes ("Bug#88: upload of multi-option enabled coreutils ls (in
time for wheezy)"):
> ls is missing several key options, notably -y, -e, and -j.
Also, it is unable to read email. For a long time this serious
deficiency in ls has gone unremedied. Debian GNU/Linux should take
the l
Steve Langasek writes ("Re: Bug#640874: leave: debian/rules is not a
Makefile")> This is a surprising claim, but upon review, I see that the
constitution
> states only that the TC may overrule Developers, not Delegates, and a strict
> constructionist reading of the constitution would support the
Jonathan Nieder writes ("tech-ctte: please help maintainers of packages with a
"node" command to have a reasonable conversation"):
> The "node" and "nodejs" packages both provide a command named "node".
I'm disappointed to see this is still rumbling on. There is only one
correct solution, and it
Jonathan Nieder writes ("Bug#614907: nodejs/node command conflict: reasons to
include the command in each package"):
> There is a transition plan and patch for the (ham radio) node in
> #614907. Nobody has been able to demonstate any appreciable problems
> with renaming it. Indee
Russ Allbery writes ("Bug#614907: tech-ctte: please help maintainers of
packages with a "node" command to have a reasonable conversation"):
> I also think the current Policy suggestion to rename both programs in the
> event of an unreconciled naming conflict is not a very good idea, and
> think i
Patrick Ouellette writes ("Bug#614907: Question of sincerity on the node/nodejs
nausia"):
> I got called a passive aggressive, stonewalling individual not interested in
> moving the issue forward.
I agree that no-one should be calling anyone names. IIRC Jonathan has
already retracted those insul
Don Armstrong writes ("Re: periodic tech-ctte IRC meetings"):
> How about I try scheduling by fiat:
>
> Wed May 30 19:00:00 UTC 2012
> Wed May 30 12:00:00 PDT 2012
> date -d @1338404400
I'm afraid I can't make that time on any Wednesday. If we're looking
at that kind of time of day I can't do We
Don Armstrong writes ("Re: periodic tech-ctte IRC meetings"):
> On Fri, 11 May 2012, Ian Jackson wrote:
> > I'm afraid I can't make that time on any Wednesday. If we're looking
> > at that kind of time of day I can't do Wednesday or Monday or
Joey Hess writes ("Bug#665851: Bug#597050: GNU parallel, name conflict with
moreutils"):
> Ian Jackson wrote:
> > Ah, I'm sorry, I must have misunderstood your comments in #597050.
> > I took them for an objection, rather than a request for help.
>
> I se
Georgios M. Zarkadas writes ("Bug#665851: Bug#597050: GNU parallel, name
conflict with moreutils"):
> just FYI, GNU parallel is already in Wheezy, in a way that does not
> conflict with moreutils (cf. the last messages in Bug#518696).
Excellent, thanks. I'm closing 665851 then.
Ian.
--
To U
Tollef Fog Heen writes ("Re: Bug#665851: Bug#597050: GNU parallel, name
conflict with moreutils"):
> ]] Joey Hess
> > - The --tollef compatability option was, AFAIK, named without getting
> > the permission of the person it refers to, and therefore essentially
> > drags his good name through
We have just finished our first meeting. Having a bit of a backlog
meant we overran rather. We will keep the next meeting to an hour.
The time proposed and agreed by those present was
28th of June 1700 UTC (date -d @1340902800)
If any TC members can't make this please speak up and reschedule.
It looks like the TC are going to be proposing some GRs within the
next few months. Very likely there will be three:
- Constitutional change to fix the supermajority bug
- Constitutional change to permit the TC to have private discussion
- Position statement regarding when TC should overrule m
Steve Langasek writes ("Re: node"):
> I think it's too late for that. The TC has been asked to rule on the
> matter, and we appear to have a consensus regarding the correct technical
> path forward. If there are specific technical objections to the proposed
> resolution, we should of course take
Neil McGovern writes ("Re: node"):
> On Wed, Jun 06, 2012 at 08:43:09AM +0200, Carsten Hey wrote:
> > I wanted to ensure that the TC knows that nodejs' maintainers could do
> > this since they can not be forced to work on any Debian related task and
> > if nobody else would step in to upload about
Don Armstrong writes ("IRC Meeting (Thursday, May 31, 2012) Notes and Logs
(Time in PDT)"):
> Thursday, May 31, 2012
> * Hardening Build Flags #552688
NB that the list of ACTIONs in what appears to be a summary in Don's
mail is not complete. Here is the result of grep:
ACTIONS OUTSTANDING:
10
Hi. We haven't used this list in a while. It's listed as `[dead
list]' on http://lists.debian.org/debian-ctte-private/. It's likely
to become relevant soon and I've volunteered to get it sorted out.
Can we get it resurrected ? Can you please confirm to me (in private
email) the membership of t
Don Armstrong writes ("CTTE IRC Meeting tomorrow June 28 2012 1700 UTC"):
> Just a reminder that the next CTTE IRC Meeting is tomorrow at June 28
> 2012 1700 UTC in #debian-ctte on irc.debian.org.
Indeed. It was in my diary but thanks for the reminder.
Ian.
--
To UNSUBSCRIBE, email to debian-
Sorry I missed the meeting earlier, I got caught up with stuff at
work which I had expected to finish by then...
Ian.
--
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/
Steve Langasek writes ("Re: Draft resolution for node+nodejs"):
> === Resolution ===
..
> Ballot:
>
> 1. Approve transition plan for node and nodejs
> 2. Further discussion
I vote: 12
Ian.
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Troubl
What would you think of TC resolutions to start GRs along the
following lines ?
Thanks,
Ian.
= TC RESOLUTION STARTS =
1. The Debian Technical Committee hereby exercises its power in
4.2(1) of the Debian Constitution to propose the following
General Resolution:
- GENERAL RES
How about this ?
= TC RESOLUTION STARTS =
1. The Debian Technical Committee hereby exercises its power in
4.2(1) of the Debian Constitution to propose the following
General Resolution:
- GENERAL RESOLUTION STARTS -
Constitutional Amendment: Fix duplicate section numb
Here is a draft. The idea would be this, followed by my clause 2 re
accepting amendments (which I've just sent a copy of to the TC and
Secretary).
Thanks,
Ian.
= TC RESOLUTION STARTS =
1. The Debian Technical Committee hereby exercises its power in
4.2(1) of the Debian Constitution t
Again, would be followed by my clause 2 re amendments.
=== TC RESOLUTION STARTS ===
1. The Debian Technical Committee hereby exercises its power in
4.2(1) of the Debian Constitution to propose the following
General Resolution:
- GENERAL RESOLUTION STARTS -
Constitutional Ame
Again, would be followed by my clause 2 re amendments.
=== TC RESOLUTION STARTS ===
1. The Debian Technical Committee hereby exercises its power in 4.2(1)
of the Debian Constitution to propose a General Resolution,
and according to A.1(1) the TC also proposes an amendment.
The proposed
Ian Jackson writes ("Technical Committee proposed GRs, and amendments, again"):
>Therefore, to achieve roughly the same effect, the TC makes the
>following promise. If any TC member gives notice that the TC
>accepts an amendment, then at least one of the followi
Russ Allbery writes ("Re: Technical Committee proposed GRs, and amendments,
again"):
> How would we go about doing those things? I assume that, given the
> constitutional requirement, the TC does actually need to vote on
> amendments, so we would implement this by possibly batching up the
> amend
Russ Allbery writes ("Re: Draft GR for permitting private discussion"):
> The change to the core of the wording seems fine to me. However, in our
> previous discussion on IRC, we talked about adding a sentence along the
> lines of:
>
> The Technical Committee is encouraged to hold discussions
Russ Allbery writes ("Re: Draft GR for advice re overruling"):
> I think this is good to start with. I suspect there will be a lot of
> discussion about what exactly this means, but I think the discussion is
> the right next step.
Yes.
Ian.
--
To UNSUBSCRIBE, email to debian-ctte-requ...@list
Kurt Roeckx writes ("Re: Technical Committee proposed GRs, and amendments,
again"):
> On Mon, Jul 09, 2012 at 04:19:36AM +0100, Ian Jackson wrote:
> > The way I imagine this working is that we nominate one TC member (me,
> > I guess) to do the work of soliciting seco
Kurt Roeckx writes ("Re: Draft GR for supermajority fix"):
> On Mon, Jul 09, 2012 at 04:11:21AM +0100, Ian Jackson wrote:
> M currently can only be 1.
That might change. It would be nice to fix this definition so that it
works for N:M as well as N:1.
> I'm also not ver
Tollef Fog Heen writes ("Re: Draft GR for permitting private discussion"):
> ]] Ian Jackson
>
> >which inevitably involve discussion of personalitiees, in public.
>^^
> Typo, I guess?
Yes.
Ian.
--
To
Kurt Roeckx writes ("Re: Draft GR for supermajority fix"):
> On Mon, Jul 09, 2012 at 06:16:42PM +0100, Ian Jackson wrote:
> > Please do feel free to suggest improvements to the wording. I want
> > this to be clear and unambiguous.
> >
> > How about if we s/s
Stefano Zacchiroli writes ("Re: Draft GR for advice re overruling"):
> On Mon, Jul 09, 2012 at 04:11:22AM +0100, Ian Jackson wrote:
> >In the past the Technical Committee have been slow and reluctant
>
> [
Kurt Roeckx writes ("Re: Draft GR for supermajority fix"):
> On Mon, Jul 09, 2012 at 06:36:07PM +0100, Ian Jackson wrote:
> > If the 1:1 majority falls under it too then the proposed text works
> > correctly, surely ?
>
> Oh, you would interprete it as that both
Sam Hartman writes ("Re: Draft GR for supermajority fix"):
> I'm trying to think of a situation where you'd want m != 1 and where
> there would be an intuitively reasonable understanding of what was
> intended.
It would be perfectly plausible for some particular thing to need a
ratio of 3:2. That
Thijs Kinkhorst writes ("Re: Number typo in the Constitution"):
> This would of course break previous references to the section numbers, and
> may be confusing e.g. when browsing older mail archives referencing a
> specific section. To me an obvious solution would be to renumber the first
> 'A.1.'
Kurt Roeckx writes ("Re: Number typo in the Constitution [and 1 more
messages]"):
> Well you already made references to the second. I don't think
> there would be many references to the first.
That would suggest we should use A.0 then.
- GENERAL RESOLUTION STARTS -
Constitutional
Michael Gilbert writes ("Re: Draft GR for permitting private discussion"):
> I feel like this wording comes across as sacrificing too much in the
> openness/transparency of the tech committee's discussions. Perhaps
> something along the following would be better?
>
> Discussion, draft resolutions
Michael Gilbert writes ("Re: Draft GR for permitting private discussion"):
> Just to clarify, that is not my perspective. Like I said in the
> following sentence,
>
> The importance of a more stringent wording (I think) is to make it clear to
> project members that the committee will only be
I think the recent flurry of discussion has more or less converged.
You can find the results here:
http://www.chiark.greenend.org.uk/ucgi/~ijackson/git/technical-committee-grs/
I'd appreciate a final round of review (especially by TC members and
the Secretary) at this stage. If that is broadl
Stefano Zacchiroli writes ("Re: TC-initiated GRs, redux"):
> On Wed, Jul 11, 2012 at 01:26:14AM +0100, Ian Jackson wrote:
> > informal-propose allow private discussion (const. change)
>
> I've some pending comments on this one, but for family reasons
Anthony Towns writes ("Re: Draft GR for supermajority fix"):
> On Mon, Jul 9, 2012 at 2:02 PM, Kurt Roeckx wrote:
> > 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 a
Anthony Towns writes ("Re: Draft GR for supermajority fix"):
> 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
Russ Allbery writes ("Re: TC-initiated GRs, redux"):
> Ian Jackson writes:
> > informal-propose allow private discussion (const. change)
>
> I'm fine with this, although I'm mildly in favor of counterproductive
> instead of infeasible or uncon
Michael Gilbert writes ("Bug#681419: Alternative dependencies on non-free
packages in main"):
> Perhaps the motivation behind this centers around FSF expectations on
> Debian's handling of non-free? If that is the case, wouldn't this
> discussion be more appropriate on the new fsf-collab list?
H
Russ Allbery writes ("Bug#681419: Alternative dependencies on non-free packages
in main"):
> I had previously assumed that we weren't worrying too much about issues
> like that because the end-user had to have explicitly enabled the non-free
> repository to have any of the non-free packages become
Andrei POPESCU writes ("Bug#681783: Are Recommends really important (especially
for metapackages)?"):
> Package: tech-ctte
These questions seems rather abstract to me. I would rather deal with
them iff they turn out to be relevant to an actual specific package or
package(s). Are you referring t
Michael Gilbert:
> So, anyway, after all of that, I would actually rather see this GR go
> in the opposite direction and instead uphold the ideal of full
> transparency in all works of the tech committee. I am not naive
> enough to believe in this cabal idea, but enforcement of transparency
> elim
Goswin von Brederlow writes ("Re: Bug#681419: Alternative dependencies on
non-free packages in main"):
> On Fri, Jul 13, 2012 at 09:59:33PM +0100, Ian Jackson wrote:
> > How about instead we think about what the real issue is. The FSF's
> > view AIUI is that they
Russ Allbery writes ("Bug#681419: Alternative dependencies on non-free packages
in main"):
> Well, if we want to go this route, we could require use of a virtual
> package in all cases like this. Then foo and foo-nonfree would both
> Provide: foo (and probably Conflicts: foo), and those who want
block 645656 by 681834
thanks
The argument about the dependency from gnome-core to network-manager
has now reached the TC. This has been extensive discussed, most
recently on debian-devel. The most recent response from Josselin is
here:
http://lists.debian.org/debian-devel/2012/07/msg00210.htm
401 - 500 of 1196 matches
Mail list logo
