Test message
Committee members: can you confirm that you are still willing to be on the committee, and that you got this message and my other one to debian-ctte-private ? Ian.
Re: please vote...
Excuse me, but I'm still a bit reeling from having found all this mail
here in an inconvenient place.
Raul Miller writes ("please vote..."):
> I agree with Manoj's "forest of symlinks" proposal -- I'm voting for it.
I haven't read the background material yet. Can we delay voting ?
How much of a hurry are we in ?
I'll have some time this weekend to deal with this. I was going to do
this and some other Debian things last weekend but all my computers
broke down simultaneously.
I can be on IRC later today (from perhaps 2100GMT or 2200GMT) if this
would help.
> (2) We still don't have a chairman. I don't see anything in the
> constititution which requires us to have a chairman before we can
> vote, but this is an outstanding vote. Here's the current
> committee lineup:
>
> Manoj Srivastava:
> votes for Dale Scheetz as chairman
>
> Dale Scheetz:
> votes for myself (Raul Miller) as chairman
>
> Guy Maor:
> has not yet voted for a chairman
>
> Ian Jackson:
> has not yet voted for a chairman
>
> Klee Dienes:
> has not yet voted for a chairman
>
> Raul Miller:
> I'm voting for both myself and Dale Scheetz as chairman
Raul, you don't seem to have expressed a preference ? I think Raul
has shown that he has a lot of time available for this kind of thing,
as has Dale.
I vote:
1. Raul
2. Dale
We need at least 4 votes to make the outcome not in doubt. If it
takes too long and we have tried various things to contact people I
suppose we'll have to replace them (which would take a little while).
Ian.
Technical committee mails ?
I'm still not getting them here, which is where I was just told I was subscribed. Is that because there is no mail ? I propose the following resolution: Given that: * Wichert has made an announcement saying we should preserve the status quo pending a decision; * it will obviously take a little while to make a decision, particularly given that the technical committee's internal mechanisms haven't been debugged yet because they've not previously been used; * packages already using /usr/share/doc may make whatever decision we come up with hard to implemement; * people on debian-policy have tried getting the policy reverted to preserve the status quo as requested by Wichert, with no avail; * no analysis of the changes between FSSTND and FHS seems to have been made to determine whether to make the change and if so how best to do it; The Technical Committee mandates that, firstly: * Until a the a list of the differences between FSSTND and FHS, with a decision whether to change and if applicable a transition plan for each, has been prepared, Debian should continue to use the FHS. And in particular: * Until a decision on transition to FHS directories has been made by the Committee, /usr/share/doc, /var/state and /var/mail should not yet be used to by Debian packages. Instead, packages should continue to place files in and refer to /usr/doc, /var/lib and /var/spool/mail. Therefore: * The policy manual should immediately be amended accordingly immediately, to change the reference to the FHS back to the FSSTND, and to add a comment saying that /usr/share/doc, /var/state and /var/mail are not yet to be used or referred to. * If the policy editors or policy group feel it necessary to ratify this change to the policy manual with the formal policy process this should be done after the policy has been changed; the policy editors should change the policy manual and issue an updated version immediately. * Lintian and any other package checking software which has already made the change to FHS should be changed back. Ian.
Re: Calling Klee and Guy to vote for the Chair
On Wed, Aug 18, 1999 at 09:31:44AM -0400, Dale Scheetz wrote: > Before we can decide on the current proposals before us, I believe we need > to settle the issue of the Chair, so we have a mechanism to call a vote. No, we don't need a Chair to call for a vote. A.2: 1. The proposer or a sponsor of a motion or an amendment may call for a vote, providing that the minimum discussion period (if any) has elapsed. 6.3: 1. The Technical Committee uses the Standard Resolution Procedure. A draft resolution or amendment may be proposed by any member of the Technical Committee. There is no minimum discussion period; So we can transact business. The things that the Chairman can do that we can't do otherwise are: * Break ties with the Chairman's casting vote. * Stand in for an absent Leader. Ian.
Re: Calling Klee and Guy to vote for the Chair
Raul Miller writes ("Re: Calling Klee and Guy to vote for the Chair"):
> > Manoj Dwarf
> > RaulDwarf
> Actually, I've voted for both you and me -- I'm most interested
> in getting a chairman quickly.
Raul, can you specify a preference, please ?
Ian.
Re: Technical committee mails ?
I have to say that I'm rather unhappy at the tone of Manoj's mails. For example, the threat to block whatever we come up with seems unhelpful to me. Manoj, why are you treating us like enemies ? Aren't we trying to do the right thing together ? Ian.
Re: Calling Klee and Guy to vote for the Chair
Dale Scheetz writes ("Calling Klee and Guy to vote for the Chair"):
> Member Vote
>
> Manoj Dwarf
> RaulDwarf
> Dwarf Raul
> Ian Raul
>
> We need at least one more vote to make this final, and so far neither Klee
> or Guy has been heard from at all.
We have four people voting out of a committee of six, we should be
able to resolve this. If the above summary is true then Dale prefers
Raul and Raul prefers Dale !
If one of Manoj and I change our minds then the Raul and Dale can just
both agree with us, giving us a chairman. Alternatively, we could
informally ask Wichert to pick one of the two.
But as I observed earlier, having no chairman doesn't paralyse us.
Ian.
Revised proposed interim FHS resolution
It seems to me that Manoj has got the impression I'm trying to make the `old' FSSTND status quo permanent with my resolution. That's not the case. I'm just trying to fix the immediate problem to produce some calm and time for us to consider the transition. Manoj: you must agree that there is need for us to discuss this, because there is disagreement and we haven't come to consensus yet. So, is it not right for us to mandate that the status quo be preserved, as Wichert requested in his mail ? Having looked at my propsed resolution it didn't make it clear that it's an interim solution. So I've added a bit on the end saying what the committee will do after this resolution - ie, look at the complex issues surrounding symlinks, dpkg, existing packages, finding documents, etc. I propose the resolution below, in place of my previous one. Manoj, if you don't agree with this as a status-quo-preserving resolution, please propose amendments, or a counter-resolution. I will call for a vote shortly. Proposed resolution of the Technical Committee `Interim decision to preserve status quo wrt fhs transition' Given that: * Wichert has made an announcement saying we should preserve the status quo pending a decision; * it will obviously take a little while to make a decision, particularly given that the technical committee's internal mechanisms haven't been debugged yet because they've not previously been used; * packages already using /usr/share/doc may make whatever decision we come up with hard to implemement; * people on debian-policy have tried getting the policy reverted to preserve the status quo as requested by Wichert, with no avail; * no analysis of the changes between FSSTND and FHS seems to have been made to determine whether to make the change and if so how best to do it; The Technical Committee mandates that, firstly: * Until a the a list of the differences between FSSTND and FHS, with a decision whether to change and if applicable a transition plan for each, has been prepared, Debian should continue to use the FHS. And in particular: * Until a decision on transition to FHS directories has been made by the Committee, /usr/share/doc, /var/state and /var/mail should not yet be used to by Debian packages. Instead, packages should continue to place files in and refer to /usr/doc, /var/lib and /var/spool/mail. Therefore: * The policy manual should immediately be amended accordingly immediately, to change the reference to the FHS back to the FSSTND, and to add a comment saying that /usr/share/doc, /var/state and /var/mail are not yet to be used or referred to. * If the policy editors or policy group feel it necessary to ratify this change to the policy manual with the formal policy process this should be done after the policy has been changed; the policy editors should change the policy manual and issue an updated version immediately. * Lintian and any other package checking software which has already made the change to FHS should be changed back immediately. Finally, the Technical Committee resolves that it will: * Enquire with the debian-policy group, maintainers of packaging tools, and other relevant Developers, to make clear in the minds of the members of the Committee what the issues and options are with respect to FHS transition; * Discuss and agree a proposal for moving /usr/doc to /usr/share/doc, including a transition plan; * Discuss and agree policy on other aspects of FHS transition, or agree to refer this matter back to the debian-policy group, possibly with some specific advice. Ian.
Re: Away notice
Manoj Srivastava writes ("Away notice"):
> I am going to take some time off from the project. Recent
> developments in the real world have increased the time demands
> that I must face, as well as increasing the stress levels. At the
> same time, the current situations I am involved in in the project
> have ahd their share in contributing to the stress as well.
I'm sorry you feel that way.
Does your message constitute a resignation from the Technical
Committee ? We need to know this so that we know what the quorum is,
etc.
Ian.
Re: ping
Raul Miller writes ("ping"):
> We've been inactive for pretty much this entire year. I think this is
> a good thing, but I'd like everyone to just give me a heads up:
>
> [0] Are you still reading this list?
> [1] Do you still want to participate in this
> committee?
Yes.
> [2] Are there issues you think we should be
> dealing with that we're not?
I haven't been following the policy lists for some time, basically
because I think the process is broken and Wichert doesn't support my
views about how it should work.
> I'm also considering putting up a page inviting people to contact us if
> they have development/interface disputes that they can't resolve.
That would be very good I think.
> I suspect that if we did this we'd get a bunch of "faq" type questions,
> and a number of things that could be resolved by references to existing
> policy or documentation. The issues that we'd need to solve would
> probably require some additional detail that isn't readily available.
> And, of course, there will be the ever-popular questions that should
> have been sent to debian-user (we've seen a variety of those this year,
> though none have ever been approved, and thus none have become a part
> of the official archive).
Possibly.
> Anyways, I think it's our job (as individuals) to keep problems from
> blowing up to the point that they really require the committee's attention
> to resolve -- I think that if things are being done right the committee
> should never have to take any formal action. And, while this year has
> been quiet, I'd like to ensure that future years are as well.
I don't think that's the job of the committee as individuals, IYSWIM,
but rather of the people on the policy list, developers, users with
problems, etc.
I agree that if things go well people won't need to contact us.
However, I think it's likely that the reason people haven't been
contacting us isn't because things have been going well. It's more
likely that by the time someone gets to the point where we should be
looking at the issue they're already tired of fighting a battle
against the forces of conservatism IYSWIM.
Manoj Srivastava writes ("Re: ping"):
> I do want to participate in this committee. I do think we may
> need to make the process of calling upon the tech ctte more visible
> -- and we do need to make this process more accesible to people (and
> not just developers)
I agree that we should be more visible and that it should be easier to
call on us.
It may be that we'll end up being swamped if we deal with complaints
from users who are not developers, but we should give it a go. If we
end up dealing with too many lame questions we'll have to look then at
asking users to find a developer who agrees with them to bring the
complaint.
Ian.
Re: bug report dispute resolution request
Herbert Xu writes ("Re: bug report dispute resolution request"):
> [SuS has] nothing about backtracking when parsing a $(( expression if the
> terminating )) is not found. Indeed, such expressions would be slow to
> parse anyway and should be avoided if the underlying shell supports it.
I agree completely. If a shell is required, after seeing $((, to scan
ahead to see whether the thing is supposed to be a command or
arithmetic substitution, then it will have to either read the input
twice, or maintain (and try building) two parse trees.
I think that this is an unreasonable requirement to impose on the
shell.
I see a lot of standards being quoted, and indeed it is usually good
to follow standards - but we shouldn't be afraid to call it a bug for
a program to do something which a standard technically permits but
which is unhelpful or in our view wrong, and also we shouldn't be
afraid to call it a bug in a program if it uses a feature in another
program which is technically required to exist by a standard but which
we feel imposes an undue burden or some such on the other program.
Ie, we should look at standards for guidance, and nearly always for
answers to questions to which there is no `right' answer, but we
should not feel totally bound by them.
Having said that, I think the SuS doesn't completely support Herbert's
view. Just at the end of the section on command expansion we see:
If the command substitution consists of a single subshell, such as:
$( (command) )
a portable application must separate the $( and "(" into two tokens
(that is, separate them with white space). This is required to
avoid any ambiguities with arithmetic expansion.
The phrase `single subshell' seems to suggest that it's intended only
to forbid to things like
$((command | othercommand))
and not
$((command | othercommand) > file)
$((command | othercommand) && (command | othercommand))
and the like. Indeed, only the former is ambiguous when the whole
expression is taken. This - together with the qualification on the
requirement to use `$( (' instead of `$((', which could have been
unqualified - seems to suggest to me that the SuS intends
the shell to be able to parse any unambiguous expression, even if this
means possible backtracking.
Herbert, is it - in your opinion as ash maintainer, or the opinion of
the upstream authors - a part of the the spec for ash that it is
supposed to support POSIX (let us assume that SuS and POSIX don't
differ on this point) ?
Ian.
Re: bug report dispute resolution request
Branden Robinson writes ("bug report dispute resolution request"):
> Had Herbert bothered to pay any attention at all, [...]
> [If Herbert were to downgrade] this bug report to a wishlist item (which,
> given his attitude, [it] would indicate that he has no intention of ever
> addressing it),
> Given past experience in this Project, [Herbert's] opinion has
> frequently been shown to be anything but sensible. [He has done]
> user-unfriendly and gratuitous [things].
> Please direct further replies to the Technical Committee; I am not
> interested in hearing further self-serving justifications from you,
Don't you think is a rather unhelpful attitude ? I'm not convinced
that you're really demonstrating here a willingness to engage with
Herbert to find a solution. It's a shame that, for example, your
conversation with Herbert had to get CC'd to the Technical Committee
so soon - clearly you hadn't yet finished even quoting standards at
each other.
I think it would be much more helpful if we all tried to be
constructive - after all, we are engaged in a joint project, not a
war. I think Herbert has been showing a willingness to engage and a
constructive attitude, in at least the mails I see here so far. (I
haven't gone and read the bug log yet).
If you have a complaint about another developer's personal behaviour,
then you should take it up with the project management.
Ian.
Re: Beefing up the Technical Committee
I said: > It's true that the committee has been very inactive, but this is > largely due to us not having been called on - although we have had had > a couple of ideas to make ourselves more visible, and it is perhaps > a failure on our part to get some of those done. Wichert suggested that we could post a summary of our activity periodically. I think this is an excellent idea. Ian.
Re: Bdale Recommendation
Raul Miller writes ("Bdale Recommendation"):
> I vote to formally recommend Bdale Garbee as a technical
> committee member.
Absolute, I vote in favour of this too. (I've been away in SF and
then to a con, so I've had no access to my home email for about two
weeks.)
Ian.
Re: Bdale Recommendation
Ian Jackson writes ("Re: Bdale Recommendation"):
> Raul Miller writes ("Bdale Recommendation"):
> > I vote to formally recommend Bdale Garbee as a technical
> > committee member.
>
> Absolute, I vote in favour of this too. (I've been away in SF and
> then to a con, so I've had no access to my home email for about two
> weeks.)
So now the following committee members have voted in favour:
Raul Miller
Ian Jackson
Manoj Srivastava
Dale Scheetz
These two have not yet voted:
Guy Maor
Klee Dienes
This means that the outcome is no longer in doubt so Bdale is
officially proposed by the Committee for consideration by the DPL as a
new member.
Bdale, I assume that you're happy with this ? Ben has already stated
that he agrees, so if Bdale is willing then he's appointed. Who do we
mail to get him added to debian-ctte ?
Ian.
Re: Beefing up the Technical Committee
Ben Collins writes ("Beefing up the Technical Committee"):
> I'd like to see the Technical Committee play a more active role in the
> project. I'm looking to call on the committee for various reasons within
> the near future.
Excellent, I'm very glad to hear it.
> While I respect all of these people as technically minded, I'm asking
> that perhaps some of the less active ones can step down to open a spot
> for a more active member to replace them.
It's true that the committee has been very inactive, but this is
largely due to us not having been called on - although we have had had
a couple of ideas to make ourselves more visible, and it is perhaps
a failure on our part to get some of those done.
> Even without this, I would like to get the count up to the max of 8
> in the committee. I ask that members who plan to stay active and
> remain, recommend possible members to me so I can appoint them. One
> that I ask as a possible candidate is Bdale Garby, who has expressed
> interest in being part of the Technical Committee.
If there are good people we should be appointing then room should
indeed be made for them. Do you, Ben, have any suggestions ?
I think Raul's suggestion of Wichert is an excellent one. What do you
think, Ben ? I just asked Wichert on IRC and he was agreeable.
Ian.
Re: administrivia
-BEGIN PGP SIGNED MESSAGE-
Raul Miller writes ("administrivia"):
> Guy and Ian have spoken out in favor of Bdale, but have not signed
> their votes. I'd like both of you to sign your votes.
Fair enough. I vote in favour of Bdale Garbee as Tech Ctte member.
> Also, both of you: you're moderators of mail which goes to the debian-ctte
> mailing list. If you don't approve your messages someone else (such as
> myself) has to. Please approve your own messages (To see how, read the
> mail headers for any message which isn't approved).
Surely it should automatically approve messages from our email
addresses ? And what value should work for `moderator' ?
> I like this group to be informal, but I do think it's important to pgp
> sign ballots, and I do think it's important that official messages are
> sent to all subscribers to this list (and to the archives).
Indeed. I hadn't noticed that my messages were being handled in this
weird way. I've reconfigured my VM to show me the X-Diagnostic
header.
Ian.
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: noconv
iQCVAwUBOtzPcsMWjroj9a3bAQEBLgQApPqfM3ECOtMZna7bdDCy3zncV4e1eKML
AI8tmb3agaWav/1uQIGpNZEMFR8DlsSr60NaXrI+q704cqdZ4bHyvBV4RMnfwhat
seTqtf1MHRU3GHHMpBJDpzmwh0f30icLlTXDFUTnBUnUtgsTAwlKexUQayH+waeX
G4COG+rXIrg=
=RKch
-END PGP SIGNATURE-
Re: Call for Votes: recommending Wichert as a committee member
-BEGIN PGP SIGNED MESSAGE-
Raul Miller writes ("Call for Votes: recommending Wichert as a committee
member"):
> Ok: I'm calling for votes to formally recommend Wichert as
> a technical committee member.
>
> To cast a vote: please clearly indicate whether you're voting
> for or against this proposal, and please gpg (or pgp) sign your
> message.
I vote in favour.
Ian.
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: noconv
iQCVAwUBOtzPjMMWjroj9a3bAQFs7QP9GK4oaDkac/afxZtdCvdJ8+HN+xqFdsX4
D2Z2vqKXNuEXoY5Ft4fkaRmTuwg5MQT39AP1qBESPfA6ir4AIGj3c/qWxMDyIJT8
k5K9nXC+BIL37qilUUOp7SGU50M+8Q/8XX3fNZ4vOXv0d8gTskbPlKd7OWHa+EHJ
ie+bU3e8mm4=
=7xsw
-END PGP SIGNATURE-
Re: Beefing up the Technical Committee
Raul Miller writes ("Re: Beefing up the Technical Committee"):
> I'm concerned about you not being able to sign messages for a month.
>
> I can either toss the signature requirement on ballots, have you abstain
> until you get things set up, consider the fact that you're able to send
> mail from master.debian.org as sufficient proof, or come up with some
> other system.
>
> Anyone else have any strong leanings here?
Since all the committee get all the mails anyway automatically, I
don't think forged messages are likely to be a problem - you'd spot
them because you'd get them. But, if you still want signatures, Guy
could create a temporary key and you could phone him up at his phone
number (which you must have on record somewhere), or he could put the
new public key in his filespace.
Ian.
Re: debian-ctte mailing list: unmoderate, please
Jaakko Niemi writes ("Re: debian-ctte mailing list: unmoderate, please"):
> On Sun, 10 Feb 2002, Ian Jackson wrote:
> Moderation taken off, but posting is still limited to subscribers
> only. If we need to remove that too, let me know.
>
Yes, please. And, your mailer is doing something very odd.
Ian.
Re: suXscribe
Bdale Garbee writes ("suXscribe"):
>
That proves the list is working, even if Bdale isn't on it, at least :-).
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Technical Committee
Firstly, I'd like to apologise to everyone here for not stepping up to the job of Chairman as quickly as I ought to done. From now on I'm rearranging my schedule to ensure that I'll read and deal with tech-ctte mail at least twice a week, which should prove a useful response time. So, having said that, I now want to work out what the todo-list is for the Committee. I want us to be more visible, and to provide a better quality of service. I think the following meta-tasks need doing: * We need at least a static web page giving our details * There should be something in the Developers' Reference about us * Eventually there should be a joint document of the Leader and the Committee about dispute resolution Additionally we currently have the following two bug reports assigned to us: * #119517: pcmcia-cs: cardinfo binary needs to move into a separate package Package: tech-ctte,pcmcia-cs; Severity: serious; Reported by: Branden Robinson <[EMAIL PROTECTED]>; Tags: moreinfo, wontfix; 163 days old. * #97671: xutils: why is rstart.real a conffile? Package: tech-ctte,xutils; Severity: serious; Reported by: Tollef Fog Heen <[EMAIL PROTECTED]>; Tags: pending; 345 days old. I shall do something about these later in this session. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Can we reject HTML mail ?
Is there any software on lists.debian.org that could bounce all HTML mail sent to debian-ctte ? debian-ctte is getting a hideous amount of spam. It's clogging our mailboxes and making the archives unuseable. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Technical Committee: decision on #119517?
Branden Robinson writes ("Technical Committee: decision on #119517?"):
> Over six months ago, on 2001-11-14, Bug #119517 was submitted to the
> Technical Committee for a ruling. No member of the Technical Committe
> has participated in any public discussion of this bug (at least in the
> bug logs or in available messages from the debian-ctte list archives)
> since 2001-12-04, and no apparently discussion of any sort since
> 2002-02-26.
Apologies for the delay. I've been the chairman of the committee
since the end of January and have, unfortunately, let it slide. I'm
now rearranging my schedule to prevent that.
> Does the Technical Committee have any plans to issue any statement on
> this issue? Either an affirmative statement regarding the issue on
> point, or a statement that the Committee refuses to countenance the
> it? If the latter, please provide some reasoning as to why, as Section
> 6.3.6 of the Constitution appears to be applicable:
It is our job and we will get back to you. I hope to have a formal
answer within no more than 4 weeks.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Technical Committee: decision on #119517?
Manoj Srivastava writes ("Re: Technical Committee: decision on #119517?"):
> From reviewing the bug report, Ian Jackson sided with the
> maintainer, with the opinion that not all binaries shipped with a
> package need work when the dependencies are satisfied. Dale Scheetz,
> Jason Gunthorpe, and I disagreed.
...
> I suggest that the quorum of two was met, and that the
> decision of the committee be formalized.
Certainly we didn't vote. Before we vote now I'd like to recap the
issues and make sure we've considered everything. It seemed to me
that we were still discussing the question. In particular, looking at
the bug logs, and recalling what was said before, I think there are
still some unanswered questions.
So, the current situation is as follows:
The package pcmcia-cs contains, amongst many other more important
things, a binary `cardinfo' which is an X program. It declares a
Suggests dependency on the X libraries. The effects of this are:
When you install pcmcia-cs, some UI tools (eg dselect) offer the X
libraries, but none install it by default. If you do not select the X
libraries you still get the binary `cardinfo' installed, but if you
try to run it you get an error from ld.so.
The complaint is that this is wrong, and instead either pcmcia-cs
should Depend on xlib6g, or the X11 cardinfo program should be split
into a separate package. (There was also a fudge suggested, making
cardinfo a wrapper script to do something completely different, to
avoid using X, if xlib6g wasn't present.)
As I understand it, the supposed principle which is being applied is
that it is unacceptable to have a binary in the package which depends
on libraries not mentioned in Depends, and that Recommends or Suggests
are not sufficient. I have two objections to this:
1. I think the current situation is fine. The other suggested
approaches to this issue have much worse effects than a slightly ugly
but perfectly informative error message.
Forcing the user to always install the X libraries with pcmcia-cs is
clearly unacceptable.
Splitting the package up is gross overkill - the general cost of an
additional package to maintain, update, select, install, cope with
dependencies of, find, etc. etc. is considerable. Note that a person
who forgets to install X when they wanted cardinfo is even more likely
to fail to spot the proposed pcmcia-cs-cardinfo package; when they
want to run cardinfo because they heard about it from a colleage
running some other distribution, we serve them better by giving them
the ld.so error message than by making the file vanish !
The only remaining approach suggested was to make cardinfo a wrapper
script which would either invoke the real X cardinfo program, or do
some kind of text-mode alternative if X wasn't available; I think this
is a hideous idea. It is a pointless piece of programming, since it
adds no new functionality or ease of use (people who wanted the text
UI will invoke it directly). It makes our `cardinfo' command behave
gratuitously differently to everyone else's. Finally, by making the
error message go away it hides the real reason why the user isn't
getting the X interface (which is presumably what they wanted), so now
it becomes harder to fix the original problem.
In fact, it seems to me that much of the aim of the complainants here
is to suppress the error message. I think this is a severely
misguided aim. Error messages are often useful and informative.
Trying to get rid of them just because you don't like errors on
principle, or find them ugly, is a road to ruin, certainly when we're
talking about the UN*X command-line.
2. I think the proposed principle is either inconsistent with current
practice, or internally inconsistent (depending how far it goes). Let
me explain:
Is this suggested principle, that binaries' dependencies on shared
libraries should always be declared as Depends:
(a) a special case which applies only to executables' dependencies on
shared libraries, or
(b) just an application of the supposed general principle that we
should declare as Depends all dependencies which, when unsatisfied,
manifest themselves as a straightforward run-time error ?
If you think (a) then I'd be interested to hear an explanation of what
makes dependencies of executables on their libraries different.
If you think (b) - that all dependencies whose violation produces
run-time errors should be declared as Depends - then you're
effectively suggesting abolishing a primary use of Recommends and
Suggests in the distribution.
There are many programs which just fail if you request the use of a
feature which needs an unsatisfied Recommends or Suggests. Some
examples:
* cron Recommends mail-transport-agent. But, cron is supposed to be
able to send mail and can't if you don't install
mail-transport-agent; the messages that
Stuff to put on the committee web page
I propose to put the following stuff on our web page: (in no particular order) * List of members and name of the chairman * Link to the constitution * Link to the debian-ctte archives * Link to the BTS page * Instructions for how to contact the committee * What to expect when you contact the committee I'd like to tell people they are entitled to a decision within 4 weeks of a referral and that they should chase it up if they don't get one, or if things seem to stall. * Admonishments to people not to be arseholes - phrased nicely :-) Anything else ? Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Release-critical bugs, and #97671
Branden Robinson writes ("Re: Processed: yawn"):
> reassign 97671 tech-ctte,xutils
> thanks
>
> Anthony has offered no basis for his latest manipulation of my bug list
> aside from the derisive remark in the Subject:.
>
> I am requesting the Technical Committee's resolution of this dispute
> under Section 6.1 of the Constitution. Both parties stipulate that the
> bug in question is not release critical. Therefore, this bug does not
> fall within the Release Manager's jurisdiction, and I am not aware of
> any other grounds upon which the package maintainer's discretion can be
> overridden on issues like this.
Can you explain what you think the technical dispute is between you
and Anthony, if any ? It seems to me that you're disagreeing about
process. As you know, if you're disagreeing about process, the
Technical Committee's involvement is limited to stating its
non-binding opinion - not that we would necessarily avoid that :-).
Looking at the situation, I think that the definition of `serious' bug
report is rather unhelpful and does not match up with the use of
`must' or `required' in policy. The idea in the BTS seems to be that
a serious bug is one which makes a package unsuitable for release.
But, the idea in the policy manual is that a `must' is a rule for
which there are not expected to be exceptions; it doesn't touch on how
damaging a breach of the rule is.
Part of the dispute seems to stem from this discrepancy. The bug in
question is agreed by everyone to be a violation of a `must' in
policy, but not to make the package unsuitable for release. If our
processes make it difficult to reconcile this then they should be
fixed.
How about if we change the wording in `Severity levels' in the BTS
documentation (http://www.debian.org/Bugs/Developer#severities).
Currently it says:
serious
is a severe violation of Debian policy (that is, it violates a
"must" or "required" directive), or, in the package
maintainer's opinion, makes the package unsuitable for
release.
How about:
serious
is a severe violation of Debian policy or any other problem,
which makes the package unsuitable for release.
This definition makes `serious' correspond identically to the
package's suitability for release. It avoids defining `severe'
violation of policy as a violation of a `must'; that seems to me to be
the core error. This change would avoid violations of exceptionless
policies (which are of course always bugs) always being treated as
release critical even if they're unimportant.
If you and Anthony agree then maybe we should see if we can get that
changed. If you disagree I'm sure you'll let us know :-).
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can we reject HTML mail ?
Jason Gunthorpe writes ("Re: Can we reject HTML mail ?"):
> On Fri, 26 Apr 2002, Ian Jackson wrote:
> > Is there any software on lists.debian.org that could bounce all HTML
> > mail sent to debian-ctte ? debian-ctte is getting a hideous amount of
> > spam. It's clogging our mailboxes and making the archives unuseable.
>
> Hmm. It seems I'm not getting unmoderated ctte postings anymore.
> Bother.
>
> Anyhow, it looks to me like the trouble is that postings sent to
> moderators are not run through the spamassasin setup. liiwi can you fix
> that?
Eh ? I thought we'd unmoderated the list.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Technical Committee: decision on #119517?
Manoj Srivastava writes (SuperCite undone): > Ian Jackson: > > As I understand it, the supposed principle which is being applied is > > that it is unacceptable to have a binary in the package which depends > > on libraries not mentioned in Depends, and that Recommends or Suggests > > are not sufficient. > > If I install a package properly, all dependencies satisfied, > all binaries work. Added recommended or suggested packages may > enhance functionality; but the b i n a r i e s M U S T w o r k. Err, that's a more general restatement of what I said, isn't it ? I'm afraid I still don't understand what is special about a feature that's invoked by running a separate program, as opposed to a feature invoked by a keystroke sequence, menu option, or command to a program's built-in CLI. I'm not sure whether this paragraph ... > Nope. The objection is that a package presents an interface to > a user to added functionality, and binaries provided by a package are > the user interface most commonly seen by users towards that. Any > binary that fails is a bug in the package. Mitigating factors are > that a package may not be properly installed. ... is supposed to be an answer to that question, but I'll try to treat it as one. In many packages, there is one main program. In those packages, the interface people use to discover the functionality provided is to use the user-interface features and on-line help of the program itself. So it seems to me that if you forbid having programs installed which do not work, you must even more strongly forbid having menu options or what-have-you that don't work. But that's the opposite of your position as I understand it. > No. The suggestion, which you apprently did not follow, was to > provide core functionality of the program regardless of X, and added > functionality when X libs are present. In other words, the program, > the interface the user sees, actually does something. Does the provided cardctl program not provide an text-mode interface to the same information as cardinfo ? I agree that it's not as friendly, and that it might be nice if there was something a little easier to use, but if such a thing were written it IMO ought not to be called `cardinfo'. > I disagree strongly. This is a quality of implementation > issue. When I go on a machine, fire off a binary, and it faults, I > know the machine is broken. You say it `faults'. To me that would mean that it receives a signal whose default action is to terminate and dump core - SIGSEGV or SIGBUS or the like. It doens't do that. It prints an informative error message and exits nonzero, just like gxditview: -norway:~> really cardinfo cardinfo: error in loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory -norway:~> echo $? 127 -norway:~> I'm not sure why you see this as a totally unacceptable behaviour, but the behaviours of cron, minicom and fvwm as fine. For example, fvwm does this if you run it without m4 installed: -norway:~> fvwm -cmd 'FvwmM4 .fvwmrc' sh: m4: command not found [ and then it runs with an empty config file using builtin defaults ] > Suggests does nto mean install suggested packages, or else > some binaries are just going to fail. Why the hell have a dependency > system with differeing levels at all, if you can no longer be sure > what one needs install in order to have binaries work? The dependency system is intended to make *packages* work. The different levels of dependency are there precisely to allow different subsets of a package to be made to work, without having to split packages up unnecessarily. > Really? I would rahtter add one more package to the nearly 10k > list than have broken systems all over the place. You keep saying you think a system with cardinfo but not X libraries is broken. If I considered it as broken as you do then I'm sure I'd agree that it was bad and ought to be avoided even if doing so has substantial costs. Can you explain why you think this is such a terrible situation ? I understand that the binary does not work in this configuration, but I don't understand why you think this is flat out unacceptable. What actual bad consequences are there ? > yeah, it just makes sure that programs in debian kinda work, > rather than be discovered randomly after the install phase is over, > and one no longer has access to the install system. That is > ridiculous. Note also that even if we made cardinfo a separate package, or arranged for the dependency to enforce the installation of the X libraries, you still wouldn't be able to run cardinfo on a system with no X installation because you'd have no display ! > >
Re: Release-critical bugs, and #97671
Anthony Towns writes ("Re: Release-critical bugs, and #97671"):
> It's not clear to me why tech-ctte discussions seem to not get cc'ed to
> the appropriate bug number properly. See also the discussion for the
> pcmcia-cs bug, much of which happened on the list rather than in the
> bug report.
Bug reports are not a particularly good medium for extensive
discussion, because they're harder to navigate than mailing list
archives. It's not like the discussion isn't accessible, starting
from the bug log - you can just go and read it in the debian-ctte
archives.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
Anthony Towns writes ("Re: Release-critical bugs, and #97671"):
> On Sat, Apr 27, 2002 at 01:34:26AM +0100, Ian Jackson wrote:
> > But, the idea in the policy manual is that a `must' is a rule for
> > which there are not expected to be exceptions; it doesn't touch on how
> > damaging a breach of the rule is.
>
> Uh, this is completely incorrect. See policy section 1.1, Scope.
You're right. My apologies for assuming I knew what it would say
without reading it.
Manoj Srivastava <[EMAIL PROTECTED]> writes:
] The core error is that bug severities should not be rigidly
] connected to release criticalness. *THAT* is the place where we need
] to make case by case, subjective decisions
Let me just see if I can get some common ground here.
Does everybody agree that it's not possible for the policy manual to
correctly specify in advance whether a particular policy violation
will actually mean that a package should definitely not be released ?
(I'm going to call this whether the bug is `releaseable' or not, to
avoid getting tangled in an argument over the definition of `release
critical.)
In this case then there are several pieces of different information
which we might record in the BTS severity field:
(a) The package maintainer's idea of how urgent/important the bug is
(b) The release manager's idea of whether the bug is releaseable
(c) Something specified by the policy manual
Now there is a relationship between (a) and (b): since the release
manager decides whether a bug is releaseable, and the package
maintainer should really be trying to deal with the unreleaseable bugs
first in order to get the package into the distribution, you can
encode both (a) and (b) in an appropriate set of severity levels:
divide the severity levels firstly into unreleaseable and releaseable,
and then have a number of levels of each.
That leaves us with (c) as the other option. I admit that I don't
understand the reasoning behind this at all. Surely since the policy
manual speaks in terms of generalities, anything it says about classes
of bugs is by and large going to need interpretation/discretion
anyway. I don't see the value of recording a purely mechanical class
in the BTS.
Now, that's not to say that the policy manual can't have something to
say about what's likely to be a releaseable bug - thus leading one to
consult the policy manual when assigning severities in the (a)/(b)
model - but it clearly can't have the last word. (It seems to me that
the `must's in the policy manual ought to be interpreted this way.)
AJ also wrote:
> I'm sorry I don't have a catchy way of phrasing this, but it *is* a bug
> that makes the package unsuitable for release, it just so happens that
> it's going to get released as is now anyway.
I hope you won't mind me saying so, but this sounds confused to me.
Surely if the bug makes the package unsuitable for release, that
*means* that we ought not to release it ? Conversely, if we decide
that the package is better off released even with this bug, it means
that we've decided that the bug is releaseable, given all the
circumstances ?
A bug's releaseability can of course change depending on lots of
external factors.
> > serious
> > is a severe violation of Debian policy or any other problem,
> > which makes the package unsuitable for release.
>
> Absolutely unconditionally _no_. This leaves the definition of serious
> a matter of judgement on behalf of the submitter which makes managing
> the release an order of magnitude more difficult.
Well, the current wording sort of does that too:
serious
is a severe violation of Debian policy (that is, it violates a
"must" or "required" directive), or, in the package
maintainer's opinion, makes the package unsuitable for
release.
But, I can see that you might want to avoid too much discretion being
exercised by bug submitters.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Technical Committee: decision on #119517?
So, let me see if I can summarise the core of the dispute: * Manoj feels that a $PATH executable, ie a shell command, failing with a run-time linker missing library error (or indeed other startup failures of a shell command) is a different kind of problem to a non-working command-line option, menu option, command to a program's built-in CLI, etc. * Manoj feels that these errors are sufficiently bad that they should never happen without a forced or broken Depends. * Everyone agrees that in some circumstances the best answer can be to have non-working command-line options, menu options, etc., when only a Recommends or Suggests is violated and not necessarily a Depends. * AJ and I think that there is no important difference in this context between an executable not working and (for example) a command line option or menu option not working. * AJ and I therefore feel that these errors, while not ideal, are tolerable with only violated Recommends or Suggests, if there are other factors involved which make it a good idea (such as wanting to avoid creating an otherwise-pointless trivial package fragment). Manoj, have I represented you fairly and accurately ? Is there anything else you think you wanted to say ? Does anyone else have anything to say ? Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Technical Committee: decision on #119517?
Anthony Towns writes ("Re: Technical Committee: decision on #119517?"):
> I think everyone agrees that it's a Bad Thing to have packages like this,
> the question is really whether it's completely unacceptable to ever do it,
> or if having packages with a single fairly trivial binary and different
> depends: is enough to justify it.
Indeed. I think that this kind of tradeoff between different kinds of
costs is best left to the package maintainer.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Technical Committee: decision on #119517?
Firstly, I just wanted to thank Anthony Towns for his concise and
excellent responses to some of your points. I won't repeat what he
says, but I have this minor point to add ...
Manoj Srivastava writes ("Re: Technical Committee: decision on #119517?"):
> Ian Jackson <[EMAIL PROTECTED]> writes:
> > -norway:~> fvwm -cmd 'FvwmM4 .fvwmrc'
> > sh: m4: command not found
> > [ and then it runs with an empty config file using builtin defaults ]
>
> And it works. Not ideally, but it did not dump me back to the
> login screen. I can now put in place a second config file, which does
> not need m4, and it shall work even better -- perhaps not all the
> bells and whistles I might have, had I installed m4, but hey. It WORKS!!
Err, the behaviour you see is AIUI the same you get from *any* failure
by fvwm to open or parse the config file; ie, it's fvwm's failsafe
response (which is reasonably good, but could do with better error
reporting in most configurations).
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
Manoj Srivastava writes (SuperCite undone): > Ian Jackson <[EMAIL PROTECTED]> writes: > > But, I can see that you might want to avoid too much discretion being > > exercised by bug submitters. > > Discretion is not quote how I would describe bug severity > escalation, but yes, bug severities ought to be as objective as we > can make them. I don't think this quite follows, as you put it here. I agree that it's unhelpful to rely on submitters' judgement to accurately prioritise bugs, and that a good way to help submitters do a useful thing is to give them objective criteria. But, that doesn't mean that the severities need to remain set by those objective criteria. Someone other than the submitter, with a greater overview of the whole package or distribution, might have a better idea, and might reasonably apply subjective judgement. Indeed, I think the argument you make later leads on to a different conclusion. You say: > [The] RM decides on a case by case basis [whether a bug is > unreleaseable], and factors in the time left to release, this is > the hardest criteria to achieve, and indeed, we should not even > try. So, you think that the bug severity should not be used to record the bug's releaseability. The question is then, what other useful information can we use it to record, or are we trying to use it to record, in a way that supports everyone in our work ? My understanding of the main way we treat the BTS is that we use it to store our todo list - both the whole project's, individual maintainers'. For some bugs, namely approximately the ones corresponding to the current definitions of severity levels grave and critical, it is very important to the whole project to get them fixed, because they have bad effects which spread far beyond frequent users of the package. These bugs are high-priority work items for the whole distribution. For most other bugs, the package maintainer, and other people closely involved with the package, are in the best position to decide which bugs are the most serious and which should be worked on first. If, then, we are not to encode in the BTS severities the releaseability of bugs, but instead use them to prioritise work, it seems clear that at least for bugs which are not `critical' or `grave', the package maintainer should have discretion. This discretion can't sensibly be eliminated by specifying the relative (or absolute) priority of bugs in the policy manual and BTS instructions, because those documents can't capture all of the relevant circumstances. Do you follow this argument ? Do you agree with it ? As you can probably tell, I think I'm still feeling my way around this issue. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Technical Committee: decision on #119517?
Anthony Towns writes ("Re: Technical Committee: decision on #119517?"):
> On Thu, May 02, 2002 at 03:31:18PM -0500, Manoj Srivastava wrote:
> > In this particular case, you got me. In the general case,
> > though, I still think my arguments have merit.
>
> Right, but that's kind-of the point: in the general case this isn't an
> issue, since everyone recognises it's a bad thing to do and there're
> very few cases where fixing it would actually be worse.
So, let me just see if we all have a shared understanding now. I may
have misread Manoj's comments (and subsequent clarification) - if so,
let me know, Manoj.
1. We think that in general it's a bad thing for programs to fail
because of missing stuff that was only in an optional dependency (ie,
Recommends or Suggests rather than Depends).
2. However, there are circumstances where it is less of a bad thing
than the available alternatives, so we can't make a hard and fast rule
that it should never be done that way. For example, it is sometimes
not worth creating a separate package just for some peripheral program
or feature, and in this case Suggests or Recommends should be used, as
appropriate.
3. With respect to cardinfo, we agree with the maintainer that the
decision is at least plausibly correct in this case. (NB that we
would need a 3:1 majority to overrule the maintainer.)
4. We note that there are some other cases which are more or less
similar, and we hope that maintainers will continue to exercise their
discretion reasonably. If anyone feels that a mistake has been made
in a particular case then we will of course consider it on its merits.
There's just one thing left to consider: do we think the current
contents of the policy manual is adequate ? If not then perhaps we
should ask the policy group to try to incorporate something like my
points 1 and 2 in an appropriate place. Also, perhaps we should
review what the manual currently says.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Technical Committee: decision on #119517?
Manoj Srivastava writes ("Re: Technical Committee: decision on #119517?"):
> Ian Jackson <[EMAIL PROTECTED]>:
> > Indeed. I think that this kind of tradeoff between different
> > kinds of costs is best left to the package maintainer.
>
> Unfortunately, unless this determination matches the one the
> users make, we have an issue. If the user thinks the program is
> broken, they shall report a bug. If it is summarily closed with
> essentially the statement "I do not agree", the result is frustating
> to the suer, who sees this as a flaw in the implementation (and we
> are all agreed it is a Bad Thing), and every such incident thwarts
> ones desires to report bugs.
Well, I agree that maintainers shouldn't close bug reports unhelpfully
like that. Better would be a reference to some appropriate
documentation - eg `see README.Debian para 4' (assuming that there's
an appropriate paragraph there about needing to install xlib6g
according to the Suggests if you want to use cardinfo, or whatever).
Certainly difficult or unusual things to do with a package, that are
likely to become frequent bug reports or enquiries, should be in the
documentation, where conscientious users will see them before they
submit bugs :-).
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
Manoj Srivastava writes ("Re: Release-critical bugs, and #97671"):
> Ian Jackson <[EMAIL PROTECTED]> writes:
> > But, that doesn't mean that the severities need to remain set by
> > those objective criteria. Someone other than the submitter,
> > with a greater overview of the whole package or distribution,
> > might have a better idea, and might reasonably apply subjective
> > judgement.
>
> To what end? Why make the objective criteria malleable? When
> one discards objective criteria for classifying bugs, one merely
> opens the door for more disruptive disagreements between reporters,
> and even fellow maintainers. With around a 1000 developers and
> counting, there is unlikely to be agreement amongst developers.
Perhaps this will be an aside, or an attack on a straw man, but:
I seem to get the impression that you want to try to generally reduce
subjective judgements, and discretion. I think this is a deeply
flawed goal. We rely absolutely on the good judgement of our
maintainers and other members of the project, and I don't see how it
could be any other way. If it were possible to produce a good
distribution without using the judgement of good people, it would be a
lot easier, it's true, but I think it's not at all possible.
Any attempt to do this will result in a tendency towards blind
application of rules, rather than detailed understanding of particular
cases, which seems to me to be the very opposite of what is required
when doing system integration. The hard bits of system integration
are all about special cases.
We have plenty of mechanisms for helping people excercise judgement
wisely, and in extremis we also have the Technical Committee, who can
overrule something that is sufficiently clearly a mistake. I think we
should be relying on these.
I think the best way to resolve arguments is to make sure that it is
clear in whose bailiwick a certain decision falls, and having a
well-functioning escalation procedure, rather than trying to make
every decision objective.
So, on to the actual question at hand, here: you want to try to make
the bug severity criteria objective. What purpose do you think the
severity classification serves ? It seems to me that Branden was
trying to use it the BTS to help manage his worklist, and that he
wanted to use the severities to do so.
This is, it seems to me, exactly what the severities were originally
intended for, and if we think that that's what they're for, it seems
clear that the package maintainer is generally authoritative for the
severity of a bug.
Your recollection may disagree with mine, but if so I'd like you to go
into more detail about what the purpose was/is. You say:
> [The severity] represents impact on the system. It categorizes
> the bug. It helps people understand potential damage the bug could
> cause, at a glance. It keeps packages out of testing. Releases
> occur farly seldom, and whether a certain version of a package is
> releasable or not is of importance to a small number of people for
> relatively short intervals of time.
I think these are all different and in some cases conflicting
functions.
* If the severity is supposed to be objectively determined by the
policy manual, I don't see how it could represent impact on the
system; furthermore, depending how you interpret `impact on the
system' it might well correspond fairly closely to a notion of how
high a priority the bug was on a notional todo list.
* Clearly it `categorises the bug' - that's tautological for a
classification. But *why* is the categorisation useful ? You could
categorise bugs by the hair colour of the first submitter, which would
be an objective classification but not particularly useful :-).
* Using severities to keep packages out of testing is using them to
keep a certain kind of releaseability information; not releasability
into stable, but nevertheless a releaseability. Furthermore, reading
between the lines, I get the impression that the release manager
doesn't deal with this particular question. If indeed this is what's
going on then it's not surprising we have a conflict, because we have
a decision whose owner is not clear.
> When you bring in policy conformance, and RCness, the
> maintainer may no longer be the one with the best knowledge of the
> issues.
>
> Also, just because a person is the maintainer does not mean
> they are more knowledeable than the reporter. (I would prefer not to
> name names here).
This is true, of course, but I think that any attempt to fix this by
trying to remove subjectivity is doomed. You can't save clueless
maintainers' packages by giving them a rulebook to follow, and clueful
maintainers will spend all their lives arguing with the rulebook.
If a maintainer is not up to scratch t
Proposed committee web page
Please save as a file called `something.html' and review it and let me know what you think. If no-one objects, I'll ask the debian-www team to put it on the website as http://www.debian.org/devel/tech-ctte/. Thanks, Ian. #use wml::debian::template title="Debian Techical Committee" # $Id: $ The Technical Committee is established by the Debian Constitution, section 6. It is the body which makes the final decision on technical disputes in the Debian project. How to refer a question to the committee Before referring a decision to the Technical Committee, you should try to resolve it yourself. Engage in a constructive discussion and try to understand the other person's point of view. If, after discussion, you've identified a technical question which you can't agree on, you can put it to the committee: Write up a summary of the disagreement, preferably agreeing it with your opponent, and send it to the bug tracking system. Reassign the bug report to the pseudo-package tech-ctte. If there is no bug for the dispute yet, file one. The committee will discuss your question on the committee mailing list, http://lists.debian.org/debian-ctte/";>[EMAIL PROTECTED]. We will not CC all of our discussion to the bug report, though we may CC the participants. Anyone else who wishes to do so may subscribe to the debian-ctte mailing list and see our deliberations. Normally, the committee will aim to make a decision within 4 weeks. Sometimes, one side or other is convinced, during the committee's deliberations, by the merit of the other side's arguments. This is a good thing ! If it happens, the committee need not make a formal decision, and bug report can be closed, or reassigned, as appropriate. Some caveats about contacting the committee A sound and vigorous debate is important to ensure that all the aspects of an issue are fully explored. When discussing technical questions with other developers you should be ready to be challenged. You should also be prepared to be convinced ! There is no shame in seeing the merit of good arguments. Please conduct your technical discussions with other maintainers in a calm and civilised way; do not use insults, or question their competence. Instead, address yourself to your opponents' arguments. The committee is only empowered to make technical decisions. If you feel that someone has been misbehaving, the committee probably can't help you much. You may wish to talk to the Project Leader, [EMAIL PROTECTED]. Membership The current members of the committee are: Wichert Akkerman Bdale Garbee Jason Gunthorpe Ian Jackson (chairman) Guy Maor Raul Miller Dale Scheetz Manoj Srivastava Archives and status The http://lists.debian.org/debian-ctte/";>committee mailing list is archived. http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=tech-ctte&archive=no";>Questions pending decision can be reviewed in the bug tracking system. Formal technical decisions NB that decisions from before the 1st of April 2002 are not yet recorded here, and there have not yet been any since then. Formal recommendations and opinions The committee has not yet issued any non-binding recommendations or opinions. Formal nontechnical and procedural decisions 2002-01-31 Appointed Ian Jackson as chairman, following Raul's resignation from the post. (In favour: Dale Ian Manoj Raul Wichert; none against or abstaining.) NB that decisions from before the 31st of January 2002 are not yet recorded here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Technical Committee: decision on #119517?
Manoj Srivastava writes ("Re: Technical Committee: decision on #119517?"):
> Ian Jackson <[EMAIL PROTECTED]> writes:
> > 2. However, there are circumstances where it is less of a bad thing
> > than the available alternatives, so we can't make a hard and fast rule
> > that it should never be done that way. For example, it is sometimes
> > not worth creating a separate package just for some peripheral program
> > or feature, and in this case Suggests or Recommends should be used, as
> > appropriate.
>
> I am afraid I am not yet convinced. [...]
Now I'm not sure I follow you. Are you unconvinced that
(a) we can't make a hard and fast rule
(b) my example is useful or interesting or
(c) that the maintainer made the tradeoff correctly in this case ?
Earlier, you replied to Anthony:
Anthony Towns writes:
> "Hey why doesn't cardinfo work?"
> "It's an X program and you don't have X installed."
> Doesn't seem particularly hard? (Seems a lot easier than
> explaining it to the cognoscenti tbh... :)
...
In this particular case, you got me. In the general case,
though, I still think my arguments have merit.
If you didn't mean that you were now convinced that the situation wrt
cardinfo was reasonable, what did you mean ? What about the argument
introduced by AJ - that even if we changed the dependencies to prevent
people installing pcmcia-cs including cardinfo without xlib6g, it
still wouldn't work, just giving a different error message ? Do you
think that is also an unacceptable situation ?
> The argument that we have too many packages already does not
> hold water; indeed, we have so many packages that the few created
> in these rather rare (we are all agreed that this is an unusual
> circumstance, correct?) would not make a perceptible difference.
> We _have_ to come up with mechanisms to make the burgeoning
> packages palatable to users, and improve discovery and selection
> methods.
I agree that we need better mechanisms for dealing with our many
packages. But:
(i) Those mechanisms don't exist yet, and until they do, the current
situation with cardinfo is better than the available
alternatives.
(ii) Even with better mechanisms for handling many packages,
additional packages still impose costs. Not just performance
problems, but management and information problems too. These
can be mitigated by better automation, but automation itself has
costs and can't completely eliminate the problems it addresses.
For these reasons it seems to me that creating additional packages is
a bad idea unless there's a good reason. And, as you know, I remain
unconvinced that there is a good reason here: the actual bad
consequences of this installation situation are negligible, and point
easily to the remedy.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Technical Committee - ping !
Are the rest of you there ? Manoj and I have been having an extensive discussion about #119517, and about the use of the BTS, and I sent round a number of other mails, but there have been no responses. Please read the discussion, or at least skimread the summaries, and get involved. The committee can't function with only the two of us ! It seems impossible that you've all read the discussions but have nothing to add. But, if you have read them and have nothing to add, an indication of where your current leanings are and any remaining doubts you have might allow us to move to a resolution more quickly. Thanks, Ian. (with official Chairman hat on and pointy sticks to poke you with ...) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Technical Committee: decision on #119517?
Branden Robinson writes ("Re: Technical Committee: decision on #119517?"):
> Well, it's been over 7 weeks, by my count (as observed before, sometimes
> my math gets fuzzy when I attempt to work with dates :) ).
>
> Do you have any information or status regarding the pending issues
> before the Committee?
I'm working on my mail backlog in this mailbox now. I'm clearly going
to have to filter my tech ctte mail differently, as I'm not giving it
the attention it needs.
Expect to hear from me about each outstanding issue shortly. I'll
think what best to do about redirecting my ctte mail.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
This discussion makes it clear to me that the decision here is not technical, it is a question of process. As such it should be made by the project leadership and/or bug tracking administrators. I therefore hereby propose the following resolution of the Technical Committee: We note that * This dispute contains both technical and process (ie political) elements; however, it has not been possible to identify a clear technical dispute which as at the heart of the problem. * The heart of the problem seems to be a disagreement over the proper use of various tagging features of the bug tracking system. This is a process matter. * We do not feel that this decision is within our normal remit; the constitution suggests that the project leader and delegates would be responsible. * The bug system administrators would seem to be the most relevant delegates. * We are not sufficiently united in our opinions that we feel that the Committee should issue any formal advice or opinion. * Should a disputed technical question be raised, we would be happy to answer it. We therefore recommend that * The bug system administrators and/or the project leader or some other delegates appointed by the project leader decide on the proper use of the bug system features. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
The current state of this seems to be: * Everyone agrees that it's not ideal for programs to fail in this way. There is disagreement about whether it should be always strictly forbidden in every case, or whether there are other tradeoffs etc. that might justify it. (I can't quite make out whether Anthony and Manoj are really saying that a strict rule should be made.) * Anthony and Manoj feel that cardinfo should be split. I feel that it should remain the same. * No-one else on the committee has said anything else of substance. To overrule a developer requires a 3:1 supermajority, which is not currently apparently available. I was hoping that some of the other TC members would comment, but it seems they're all apathetic. We haven't ever been here before, but it seems to me that the best course of action would be to formulate a resolution overruling the pcmcia-cs maintainer's decision and vote on it. If it fails, we have at least cleared the question off our books. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: developers-reference: patch re: replacing files on the ftp site
Branden Robinson writes ("Re: developers-reference: patch re: replacing files
on the ftp site"):
> I still think it would be a good idea if the Technical Committee
> documented its decision per 6.3.3.
You are right, of course. However, there are probably better things
we could be doing than going through our old mail archives documenting
or formalising old decisions. If this matter is no longer disputed,
then it's probably easier for everyone to leave it be.
With respect to your complaints:
>[illusion that]
> 1) the Technical Committee is a going concern;
I agree that the TC is not as active as it should be. However, we
have not been entirely idle. For my own part I admit a large share of
the responsibility for failing to drive matters and am trying to
change my working patterns to give the TC email much higher priority.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
Ian Jackson writes ("Re: Release-critical bugs, and #97671"):
> I therefore hereby propose the following resolution of the Technical
> Committee:
(Full resolution below.)
No-one has commented to say they object to us punting on this one, so
I hereby call for a vote on the resolution I proposed on Monday. If
anyone votes against, or proposes an amendment, I'll probably withdraw
the resolution so we can talk about it.
Ian.
-8<-
We note that
* This dispute contains both technical and process (ie political)
elements; however, it has not been possible to identify a clear
technical dispute which as at the heart of the problem.
* The heart of the problem seems to be a disagreement over the proper
use of various tagging features of the bug tracking system. This
is a process matter.
* We do not feel that this decision is within our normal remit; the
constitution suggests that the project leader and delegates would
be responsible.
* The bug system administrators would seem to be the most relevant
delegates.
* We are not sufficiently united in our opinions that we feel that
the Committee should issue any formal advice or opinion.
* Should a disputed technical question be raised, we would be happy
to answer it.
We therefore recommend that
* The bug system administrators and/or the project leader or some
other delegates appointed by the project leader decide on the
proper use of the bug system features.
--
Ian Jackson, at home. Local/personal: [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.chiark.greenend.org.uk/~ijackson/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Ian Jackson writes ("Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move
into a separate package"):
> We haven't ever been here before, but it seems to me that the best
> course of action would be to formulate a resolution overruling the
> pcmcia-cs maintainer's decision and vote on it. If it fails, we have
> at least cleared the question off our books.
No-one has objected, so we should take this route.
I therefore hereby propose the following two alternative versions of a
resolution for this issue:
Version A (my favourite):
1. It is generally bad for programs to fail due to run-time
linkage failures, in most cases. There may however be other
tradeoffs involved that make this a reasonable choice.
2. In this particular case, splitting the package introduces a level
of administration and other overhead which outweighs the minor
ugliness of the run-time linker error message.
3. We therefore agree with the package maintainer that pcmcia-cs
should remain one package, with cardinfo included.
4. The bug report should be closed with no action.
Version B (Anthony and Manoj, I think):
1. It is generally bad for programs to fail due to run-time
linkage failures, in most (if not all) cases.
2. In this particular case there are no countervailing tradeoffs
that legitimise the behaviour. In particular, the alternative
solution of splitting the package has no significant problems
that are relevant.
3. We therefore agree with the submitter that pcmcia-cs should be
split, with cardinfo being put into a separate binary. We
recommend or direct that the maintainer do so.
4. The bug report should be reassigned to the pcmcia-cs package.
I hope I've captured everyone's opinions, and the substance of our
disagreement, accurately. If not, please propose an amendment to
version A or B, or at least complain and I'll try to draft it for you.
If the wordings seem good, I'll call for a vote.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
Jason Gunthorpe writes ("Re: Release-critical bugs, and #97671"):
> On Wed, 26 Jun 2002, Ian Jackson wrote:
> > No-one has commented to say they object to us punting on this one, so
> > I hereby call for a vote on the resolution I proposed on Monday. If
> > anyone votes against, or proposes an amendment, I'll probably withdraw
> > the resolution so we can talk about it.
>
> I think this is just fine. I agree that it is not fitting for the ctte to
> decide how the project should use the current BTS features.
Right. I take it we're to interpret that as a vote in favour ?
(Obviously I vote in favour too.)
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed committee web page
On the 6th of May I wrote: > Please save as a file called `something.html' and review it and let me > know what you think. If no-one objects, I'll ask the debian-www team > to put it on the website as http://www.debian.org/devel/tech-ctte/. There were no comments, so I'll talk to the www people. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Wichert Akkerman writes ("Re: Bug#119517: pcmcia-cs: cardinfo binary needs to
move into a separate package"):
> Previously Ian Jackson wrote:
> > I therefore hereby propose the following two alternative versions of a
> > resolution for this issue:
>
> Can we please wait with a vote until July 5? I'm afraid I'm currently
> really swamped with both work, Debian security and SPI tasks.
OK, I think we can wait another week or so, it's been long enough
already :-). But please do make sure you help out, then, ...
Thanks,
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Anthony Towns writes ("Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move
into a separate package"):
> For reference, I'm actually with Ian on this issue; I don't see much
> point creating a new package for cardinfo and dealing with the hassle
> of cardinfo disappearing on an apt-get dist-upgrade and such like. But
> I'm also not on the tech ctte, so *shrug*.
Quite.
> It's a pity we're going with votes and committee rulings when we can't
> establish a consensus on something that's clearly the right thing to do.
I agree.
> Oh well. I'm still interested in how such a view affects other packages
> that do similar things:
I would very much like those who broadly support the version B to
answer these questions ...
> * debconf frontends [...]
> * ifupdown methods [...]
> * kernel modules etc [...]
... and other similar ones I asked on the 27th of April:
] * cron Recommends mail-transport-agent. [...]
] * fvwm Suggests m4. [...]
] * minicom Suggests lrzsz. [...]
] * groff contains gxditview, [...]
I think that to support version B you have to either say that
(i) a non-core part of a package that is a separate executable and
which fails to start with a dynamic linker error is much worse than a
non-core part that is a menu option, configuraton option, sub-CLI
command, etc., or a failure of an executable to start for some other
reason (kernel feature missing, lack of DISPLAY variable, some
subfeature of some other program being disabled, or even the very
option being disabled by configuration ...)
(ii) all these other examples should be changed too, producing
zillions of extra little packages and requiring dynamically generated
menus and command lists in all sorts of configurations.
In fact, as I've said before, I think what's happening here is that
some people are unwilling to tolerate error messages, and intend
instead to make the error messages go away by hiding away the ability
to request the non-working feature. This will just make it harder
rather than easier for a user who wants the feature to make it work.
> Should any of the above be changed too? Should the Readline and
> Gnome, frontends all be packaged separately with appropriate depends
> (libterm-readline-gnu-perl, libgnome-perl, respectively) to ensure
> they're functional if they're installed?
Quite.
> It's a pity we still don't have better support for splitting packages
> in apt/dselect than adding a Depends: from the old package to the new.
Replaces: is supposed to do this. grep the dselect source for fixme ...
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
The Technical Committee has passed the following resolution, regarding the dispute surrounding Bug#97671 and the proper use of the Severity tag and other BTS features: We note that * This dispute contains both technical and process (ie political) elements; however, it has not been possible to identify a clear technical dispute which as at the heart of the problem. * The heart of the problem seems to be a disagreement over the proper use of various tagging features of the bug tracking system. This is a process matter. * We do not feel that this decision is within our normal remit; the constitution suggests that the project leader and delegates would be responsible. * The bug system administrators would seem to be the most relevant delegates. * We are not sufficiently united in our opinions that we feel that the Committee should issue any formal advice or opinion. * Should a disputed technical question be raised, we would be happy to answer it. We therefore recommend that * The bug system administrators and/or the project leader or some other delegates appointed by the project leader decide on the proper use of the bug system features. As Chairman, I shall arrange for this decision to be appropriately documented and work out the disposition of the bug report. Thanks for your attention, Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
Ian Jackson writes ("Re: Release-critical bugs, and #97671"):
> The Technical Committee has passed the following resolution, regarding
> the dispute surrounding Bug#97671 and the proper use of the Severity
> tag and other BTS features:
...
>We therefore recommend that
>
>* The bug system administrators and/or the project leader or some
> other delegates appointed by the project leader decide on the
> proper use of the bug system features.
I'd therefore like to formally request that the bug system
administrators and/or the project leader take responsibility for this
issue. I have spoken informally to one of the bug system
administrators on IRC, and was advised that they wish to avoid process
and political questions and want to just keep the software working.
Therefore, I'd suggest that the project leader ought to consider the
question, or delegate it. Should I reassign the bug report to the
`project' pseudo-package ? Or is there some other pseudo-package for
the project leader ?
Thanks,
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Ian Jackson writes ("Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move
into a separate package"):
> I therefore hereby propose the following two alternative versions of a
> resolution for this issue:
See below for the full text, and my last message for my views.
(Wichert said he wanted until at least the 5th and hasn't said
anything more, so ...)
I hereby call for a vote on this resolution. We'll vote on the whole
lot on one ballot - effectively, conducting two votes one after the
other. The overall options are:
AVersion A (allow maintainer discretion to bundle)
BVersion B (overrule maintainer, split packages)
FD Further Discussion
It'll be easiest if you just rank these in descending order of
preference.
If you're not familiar with the voting arrangements you may want to
reread the constitution section A. We'll interpret the results as
follows:
* First - constitution A.3(1) - we select either A or B as the `most
preferred form' (henceforth P), or choose FD. If we choose FD, then
we go back to further discussion. Otherwise A or B goes onto the next
round:
* Second - constitution A.3(2) - we decide whether the most preferred
form P beats FD by enough to pass. When considering this, we
disregard any preferences for the losing form; a vote is counted as
for `Yes' if it ranks P above FD, `No' if FD above P, or abstain
otherwise.
* Results - constitution 6.3, A.6:
There is a quorum of 2. Additionally, overruling a developer requires
a 3:1 supermajority. So:
If P is A and beats FD by at least 2 votes, then A is carried.
If P is B and beats FD by at least 2 votes, and also at least 3 times
as many ballots prefer B to FD as prefer FD to B, then B is carried
and is binding: the maintainer is directed to split the package.
If P is B and beats FD by at least 2 votes, but not the required
supermajority, then B is carried and is a recommendation only: the
maintainer is recommended to split the package.
I hereby vote as follows:
1AVersion A (allow maintainer discretion to bundle)
2FD Further Discussion
3BVersion B (overrule maintainer, split packages)
Ian.
> Version A (my favourite):
>
> 1. It is generally bad for programs to fail due to run-time
> linkage failures, in most cases. There may however be other
> tradeoffs involved that make this a reasonable choice.
>
> 2. In this particular case, splitting the package introduces a level
> of administration and other overhead which outweighs the minor
> ugliness of the run-time linker error message.
>
> 3. We therefore agree with the package maintainer that pcmcia-cs
> should remain one package, with cardinfo included.
>
> 4. The bug report should be closed with no action.
>
> Version B (Anthony and Manoj, I think):
>
> 1. It is generally bad for programs to fail due to run-time
> linkage failures, in most (if not all) cases.
>
> 2. In this particular case there are no countervailing tradeoffs
> that legitimise the behaviour. In particular, the alternative
> solution of splitting the package has no significant problems
> that are relevant.
>
> 3. We therefore agree with the submitter that pcmcia-cs should be
> split, with cardinfo being put into a separate binary. We
> recommend or direct that the maintainer do so.
>
> 4. The bug report should be reassigned to the pcmcia-cs package.
--
Ian Jackson, at home. Local/personal: [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.chiark.greenend.org.uk/~ijackson/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Ian Jackson writes ("Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move
into a separate package"):
...
> I hereby call for a vote on this resolution.
Just a reminder about the voting period. That CFV of mine was
timestamped by lists.debian.org as:
Received: from chiark.greenend.org.uk ([EMAIL PROTECTED])
by murphy.debian.org with SMTP; 12 Jul 2002 18:40:19 -
which is Fri, 12 Jul 2002 18:40:19 +. The voting period is up to
one week, unless the outcome is no longer in doubt before then. You
therefore have to get your vote in by
Fri, 19 Jul 2002 18:40:19 +
as evidenced by lists.debian.org's (murphy's) Received line.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: EN-IT translator
Paolo Risso writes ("EN-IT translator"):
> I'm Paolo, from Genova - Italy. I drop you these few lines in the case you
> need my help for your fantastic project (of course, for free).
...
> I'm a 6 years free-lance translator from English to Italian, [...]
I have forwarded your mail to our Italian localisation team, who
should be in touch.
Thanks,
Ian.
(technical committee chairman)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Vote! on supposedly controversial tech ctte question Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
See my call for votes last Friday: Date: Fri, 12 Jul 2002 19:40:15 +0100 Message-ID: <[EMAIL PROTECTED]> Subject: Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package Votes (rankings) [1] so far are: Ian A, FD, B Wichert A, FD, B I was expecting Bdale and Manoj to have a different view. Manoj, Bdale, are you going to vote ? Is anyone else on the committee paying any attention at all ? Please participate, even if only to explicitly abstain ! You have until 18:40 UTC tomorrow. [1] the options to rank being AVersion A (allow maintainer discretion to bundle) FD Further Discussion BVersion B (overrule maintainer, split packages) Thanks, Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
For history of this resolution, see earlier postings on the tech ctte list. The committee has voted as follows: Bdale FD, B, A Ian A, FD, B Manoj B, FD, A Wichert A, FD, B Dale no response Guy no response Jason no response Raul no response The result of this a tie between A and FD. I hereby use my casting vote as Chairman to resolve the tie in favour of A. For full details of how the vote is counted, see below. I'll respond separately to the points people have made alongside their votes, to try to keep this this results message as short as it can be. Therefore, the Technical Committee has passed the following resolution: 1. It is generally bad for programs to fail due to run-time linkage failures, in most cases. There may however be other tradeoffs involved that make this a reasonable choice. 2. In this particular case, splitting the package introduces a level of administration and other overhead which outweighs the minor ugliness of the run-time linker error message. 3. We therefore agree with the package maintainer that pcmcia-cs should remain one package, with cardinfo included. 4. The bug report should be closed with no action. I am closing the bug report with this message and will update the committee webpages. Thanks to everyone for participating and for generally managing to keep the conversation civilised despite strong feelings (which I think are fair enough even if I disagree with the content). Ian. Vote counting - Firstly - constitution A.3(1) - we select either A or B as the `most preferred form' (henceforth P), or choose FD. This is to be done by the Condorcet method from A.6 (misspelled Concorde in the constitution). First, we calculate which options dominate others according to A.6(2): BallotsA to FD Ian, Wichert which prefer FD to A Manoj, Bdale neither FD nor A dominates FD to B Ian, Wichert, Bdale B to FD Manoj FD dominates B A to B Ian, Wichert B to A Manoj, Bdale neither A or B dominates So according to A.6(3) we eliminate B because it is dominated by FD. This leaves us with a choice between FD and B, and the ballots have decayed to A, FD (Wichert, Ian) and FD, A (Manoj, Bdale). This is a tie, which my casting vote resolves. (Other interpretations of the counting system have similar results.) Secondly - constitution A.3(2) - we decide whether the most preferred form A beats FD by enough to pass. Again, we have the same two pairs of ballots: Yes, No/FD (Wichert, Ian) and No/FD (Manoj, Bdale). Again I use my casting vote again to make Yes win. Thirdly, according to A.6(8) we check for the quorum, which is two according to 6.3(1). There were at least two votes which prefer the winning option (A) to the default option (FD), so the quorum is reached. -- Ian Jackson, at home. Local/personal: [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.chiark.greenend.org.uk/~ijackson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
Anthony Towns writes ("Re: Release-critical bugs, and #97671"):
> I still haven't had a chance to properly think about the whole "serious"
> and -policy and whatever issues, so I'm still not making substantive
> comments about this.
Right, well, no-one seems to be telling me what to do, so I'll
reassign the bug to bugs.debian.org, project and you and the DPL can
argue it out. Have fun :-).
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Manoj Srivastava writes ("Re: Bug#119517: pcmcia-cs: cardinfo binary needs to
move into a separate package"):
> Here is my vote, though couched in terms biased the other way:
I'm sorry you didn't like my wording. But, the discussion /was/ about
whether to split the package and whether to overrule the maintainer
and I think my wording was fair (and anyway, I hope the committee are
strong-minded enough not to be led astray by a simple summary line).
Next time I'll put a one-line summary of each proposal the top, when I
draft them, which will give you the chance to complain earlier.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vote! on supposedly controversial tech ctte question Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
Bdale Garbee writes ("Re: Vote! on supposedly controversial tech ctte question
Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package"):
> My reason for wanting further discussion is that I'm willing to let
> the maintainer have some discretion, but believe that it's only
> reasonable to allow packages to deliver binaries for which the
> runtime dependencies are not met in some limited set of
> circumstances, such as perhaps when the binary is peripheral to the
> main purpose of the package, and/or rarely used, and/or does a good
> job of providing a useful error message when attempted without the
> full set of runtime requirements available.
Right.
> This suggests to me
> that before I'd accept 'A', I'd want some sort of an expression of
> boundary conditions from the ctte. Any time a maintainer is unclear
> on the issues or the binary in question doesn't provide good error
> checking/communication, I fall back on wanting the packaging system
> to help ensure users have good experiences.
I don't think this is necessary. If we're satisfied that a line could
be drawn (however fuzzily), then we can agree with the maintainer in
this case with a clear conscience. If another maintainer does
something different with their package, which has different
circumstances, we can make a different decision.
On the other hand, this kind of thing might well reasonably be covered
in our policy documents. If you want there to be a written policy,
perhaps the right thing to do would be to write up a proposal for the
policy manual, which the policy editors could include (or which we
could resolve should be included).
Also, this question has been outstanding far too long. I think it is
better to make a decision in this case now than to let it wait any
more.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Technical committee composition and activity
--text follows this line--
Ian Jackson writes ("Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move
into a separate package"):
> For history of this resolution, see earlier postings on the tech ctte
> list. The committee has voted as follows:
>Bdale FD, B, A
>Ian A, FD, B
>Manoj B, FD, A
>Wichert A, FD, B
>Dale no response
>Guy no response
>Jason no response
>Raul no response
OK, I seem to be managing to get some life into this beast. But, we
still have some problems:
* I'm advertising a 4-week response time. This doesn't seem to be
anywhere near reality, so I propose to change it to 8 on our webpage.
* We have a lack of questions to resolve. I can't believe that no-one
is arguing about anything; the silence may well mean that people have
stopped caring, or are browbeating each other instead.
* Half of the committee seem completely dead. This is what the rest
of my message will be about.
I think the lack of responsiveness by half of the committee is a big
problem. It undermines both our legitimacy and effectiveness. It's
OK for people to be busy occasionally and miss bits of our work. But
completely disappearing and not answering email at all is out, really.
So, I think we should try to replace the silent committee members. I
propose to try a novel (for the committee) appointment system: an
announcement asking for volunteers; applications, with some
information about past history; discussion in the committee about who
would be best, and then replacement of up to 4 of the currently
inactive members.
Dale, Guy, Jason, Raul: now would be a good time to pipe up and say
you're here really and promise to actually take part. Otherwise we'll
assume you've moved on to other things.
It is important to remember that it is much more important to have
only really good people on the committee, than it is to have many
people. If we can't find enough candidates that we're sufficiently
convinced about, we should stay with the status quo.
What do you think ? If you like this idea, I'll write up a draft `job
advert' for d-d-a.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee composition and activity
Raul Miller writes ("Re: Technical committee composition and activity"):
> I am still on the committee?
Yes.
> I'm sorry, I've been completely out of touch with Debian since Februrary.
>
> At the moment: I've moved, I don't have a phone yet, I've got access
> to the machine which was receiving my debian email, but have not had
> a chance to review it.
>
> If there is a particular set of issues you'd like me to focus on
> (especially if there are certain subject lines or words to search
> on), I'll try to bring myself up to speed on those issues.
Until just now, there were no questions before the committee - there
were a few earlier, but we dealt with them. So please don't feel you
have to catch up with any backlog.
> But I have been out of touch, and I've not been active -- and if you
> want somebody on the committee more active than I currently am able to be
> I'll support you in that.
If you could manage enough time to read the mails sent to
[EMAIL PROTECTED] and then vote when the time comes, I think that
would make your membership an asset.
Ian.
Re: Bug#154950: Gnome 2 transition
Raphael Hertzog writes ("Bug#154950: Gnome 2 transition"):
> Christian Marillat is working on conversion scripts, but there's no way
> he can run them automatically because maintainer scripts are not
> supposed to modify the user configuration ...
Why not ? I don't see any reason why a carefull-written conversion
script should not automatically update user configuration. Just to
check: it's possible to have both a GNOME 1 and 2 configuration, and
most users will not have a GNOME 2 one ?
In which case automatically generating one (possibly after asking the
sysadmin whether this is a good idea) by converting the GNOME 1 config
would seem quite sensible.
Ian.
Draft Call for Applications
To: debian-devel-announce Subject: Call for Applications to the Technical Committee Reply-To: [EMAIL PROTECTED] INTRODUCTION The Technical Committee is established by the Debian Constitution, section 6. We are the body which makes the final decision on technical disputes in the Debian project. Currently, the active members are: * Bdale Garbee * Ian Jackson (chairman) * Manoj Srivastava * Raul Miller * Wichert Akkerman There are also three inactive members: * Dale Scheetz * Guy Maor * Jason Gunthorpe We feel that 5 is too small an active membership, and are considering replacing up to three of the inactive members with new blood. In a breach with usual Debian tradition, we're doing this by posting a call for applications. The project is too large for us to know personally all the possible candidates. So, we would like to you to put yourself forward if you feel you are able and willing. JOB DESCRIPTION --- For you to apply, ideally: * Your technical skills are exceptionally good. * Your ability to reason and and argue is exceptionally good. * You are able to have a constructive discussion even when you disagree strongly with people. * You have substantial experience in the Debian Project; preferably, you will understand well both the technical and organisational structure. * You have a strong reputation and respect in the Project and elsewhere in the Free Software world. What the job involves: * You will have to read the list [EMAIL PROTECTED] Traffic is moderate; see the archives at http://lists.debian.org/debian-ctte/ * It is best if you participate in the discussions, when you have something relevant to say. * If you have been following a discussion, you should vote if and when the time comes (ie, simply sending a reply to a CFV email). The total time involved should be no more than 1-2 hours per week in busy times, and consists almost entirely of answering email. What is not very important: * You do not need to be available 100% of the time. If you take a holiday or have a work crisis, that's fine. The committee can function even with some absenteeism. * You do not need to currently be a maintainer of an important package or packages, or be deeply involved in other parts of Debian's key infrastructure. * You do not need to be an expert on any or all of the software in Debian; the design and behaviour of software will be explained during our discussions. APPLICATIONS Please send your application to [EMAIL PROTECTED] It would be helpful to you if you could provide some information to help us make our decision. * How long have you been involved with Free Software, and with Debian ? What is your current involvement with Debian ? * What TWO pieces of Free code that you have written are you most proud of, and why ? Please provide URLs so we can go look at them. * We would like to get an idea of your discussion skills by reviewing a couple of email or USENET argument you were involved in and you think you made a substantial and helpful contribution to. (It doesn't matter if the ultimate decision went against you.) Please provide TWO references, including URLs, to an appropriate archive location, and any commentary that you think might help your application :-). Notes: 1. You have until the 7th of August 2002. 2. Please try to keep your answers reasonably short. We don't want whole essays here. 3. URLs should be accessible with a variety of web browsers and not require registration or cookies. PROCESS --- The exact process will depend on the number of applications. If there are many, we may prepare a shortlist, first, and then publish, on debian-devel-announce, a list of the (shortlisted) candidates and will invite comments to be published, as well as being considered by the committee. Throughout we will keep the Project Leader informed. When we're done collecting information, and arguing, we will decide which of the idle committee members (if any) we wish to replace and with who. If the Project Leader agrees, the new members are appointed. In accordance with the Constitution, our votes will be public. To avoid too much acrimony we will hold our actual discussions on the private mailing list, copying the Project Leader. When we are deciding, we will remember that it is much more important to have only really good people on the committee, than it is to have many people. If we can't find enough candidates that we're sufficiently convinced about, we will stay with the status quo. We may decide on a somewhat different process when we see the applications, after the closing date. -- Ian Jackson, at home. Local/pers
Re: Technical committee composition and activity
Jason Gunthorpe writes ("Re: Technical committee composition and activity"):
> FWIW, I wasn't able to get to my PGP key when I had time to make a vote.
> It's been a trying week. Lame excuse..
Oh, hello. Damn, I just sent out my draft with you down as
`inactive'. Do you want to join in again, then ?
> > It is important to remember that it is much more important to have
> > only really good people on the committee, than it is to have many
> > people. If we can't find enough candidates that we're sufficiently
> > convinced about, we should stay with the status quo.
>
> Indeed, and no job with those requirements has ever been filled in Debian
> by posting a help wanted ad. Bdale and the existing members should be
> given first crack at recommending people before we resort to that.
I disagree. I think the project is too big for us to know well all
the possible applicants, and I think collecting some information from
applicants is a very good idea to help us choose.
On the other hand I think people should be encouraged to prompt others
to apply. Perhaps we should ask for third-party applications ?
Ian.
Re: Bug#154950: Gnome 2 transition
Wichert Akkerman writes ("Re: Bug#154950: Gnome 2 transition"):
> Previously Ian Jackson wrote:
> > Why not [automatically convert users' configs] ?
>
> Lots of nastiness: users might currently be logged in and suddenly
> have files changing underneath them. NFS /home will also break things.
I hope GNOME 1 won't mind the user suddenly acquiring lots of GNOME 2
config files, and clearly the user ought not to be running GNOME 2
until it's set up ...
> We had the same problem with fvwm/fvwm2 a couple of years ago and
> ended up with the postinst offering to try and convert the config
> for all users but also offering a commandline tool users could use
> to update their config.
That seems like a sensible plan to do again. Is there some reason not
to do that ?
Ian.
Re: Draft Call for Applications
Martin Schulze writes ("Re: Draft Call for Applications"):
> Ian Jackson wrote:
> > To: debian-devel-announce
> > Subject: Call for Applications to the Technical Committee
> > Reply-To: [EMAIL PROTECTED]
> [..]
> > 1. You have until the 7th of August 2002.
>
> Are you going to post this on d-d-a as well?
No-one commented on it at all. Do people think it's a good idea ?
Ian.
Re: Bug#154950: Gnome 2 transition
Chris Waters's message implied that the argument was not really about whether Gnome2 should go into unstable, but whether it should take over the old package names. In the past we've used the same package names when it really only makes sense, as a desirable goal, to have one version installed. Typically this involves either such incompatibility that having both on the system is nearly impossible, or such similarity that it's pointless. We should only approve the release of Gnome2 into stable without the `2' suffix if we're sure, now, that we will definitely only want to release one set of Gnome packages, with no choices for end-users and with only having choices for sysadmins by using different distributions and possibly even manual package fetching. But obviously that's not true. Indeed, even if we choose to only keep Gnome2 in unstable or release only Gnome2 in sarge, it still makes sense for individual sysadmins to install the Gnome2 from unstable alongside the Gnome1 from stable, regardless of what the release manager or package maintainers think. So it seems to me that it's completely clear that the Gnome2 packages ought to keep the `2' suffix. Now, Raphael Hertzog writes in his initial referral: ... > * Solution two : > > Upload some Gnome2 packages in unstable with a new name (adding a "2" > suffix) so that unstable users can choose to install Gnome 2 or Gnome > 1.4. Ask the user to test *2 packages. Rename them later and move them > to sarge. This is the only solution he offers which gives a `2' suffix at all. But, it assumes that the packages have to be renamed before they can go in sarge. Why can't the Gnome2 packages keep the `2' suffix forever ? Indeed, as Steve M. Robbins writes: > There's one aspect of this debate given little attention in > submissions to the bug report: It is entirely possible that both > Gnome 1 and Gnome 2 are desirable in the next Debian release. > [The] release manager may wish to have the flexibility of > releasing both Gnome desktops. Raphael's "solution two" is the > only one that allows this flexibility. It seems that this will be unlikely because of the size of Gnome and the difficulty of maintaining two version. But, more to the point, the release manager may wish to choose at a late stage whether to go with Gnome1 or 2, depending on available information and quality. Prejudging that issue now is a mistake. Also, I want to respond to this: On Mon, Aug 05, 2002 at 10:55:28AM +0200, Raphael Hertzog wrote: > Of course, during the Gnome2 switch, some apps will continue to work > with 1.4 until they are ported. That means that we won't have a > fully consistent Gnome2 desktop for several months but that's how > things are going on. Putting no incentive on porting them to Gnome2 is > not going to help that move ... I am very strongly opposed to any attempt to provide `incentives' for maintainers to do work in this way. Penalising our users, or making life difficult for ourselves, in order to `encourage' people to do something, is a very bad idea in a volunteer organisation. If something isn't being done that you want done, go and do it. Don't break things in an effort to force the issue. So, I'm very strongly leaning towards saying that Gnome2 should go in unstable, as soon as uploads are ready, with a `2' suffix which it should keep indefinitely. Gnome1 should remain in unstable as long as people are willing to maintain it there. The release manager should decide whether Gnome1, Gnome2 or both should go into testing and eventually sarge. I'll write this up as a draft resolution in my next mail. (Thanks to everyone for their contributions.) Ian.
Re: Bug#154950: Gnome 2 transition
See my previous mail for discussion. I hereby propose the following resolution: The Technical Committee is of the opinion that: * Gnome1 and Gnome2 can sensibly coexist on installed systems, and they should not be gratuitously prevented from doing so; * Gnome1 and Gnome2 should both be available in unstable for the release manager to choose from, provided maintenance effort is available for both; * Whether Gnome1, Gnome2 or both should be in testing, or future releases, is a decision for the release manager. * There is no problem with the Gnome2 packages maintaining a `2' suffix in the package name. We therefore resolve this matter as follows: * All the Gnome2 packages shall have `2' appended to the package name (or possibly embedded in the middle), so that they do not replace or clash with the Gnome1 packages. The Gnome2 maintainers should prepare appropriate packages at their convenience. * Gnome2 shall be uploaded into unstable as soon as the files are prepared. * Gnome1 shall remain in unstable until it falls into disrepair. * Gnome2 shall retain the `2' suffixes indefinitely. If it is proposed to remove the `2' suffix at some point in the future, the Technical Committee shall be kept informed. Let me know what you think. I'm going to be away until Sunday night; if there's no disagreement or amendments or anything by then I'll call for a vote. If you think I'm jumping the gun let me know and I'll back off. Ian.
Bug#154950: Gnome 2 transition
Raul Miller writes ("Bug#154950: Gnome 2 transition"):
> That said: Ian's proposal is incomplete. It only addresses package
> names, and does not address file paths/names for files which are the same
> (or are named the same) in both gnome1 and gnome2.
You're right, and I hereby withdraw the proposal. I'll get onto the
substance in just a moment ...
Ian.
Bug#154950: Gnome 2 transition
Raul Miller writes ("Bug#154950: Gnome 2 transition"):
> That said: Ian's proposal is incomplete. It only addresses package
> names, and does not address file paths/names for files which are the same
> (or are named the same) in both gnome1 and gnome2.
For executable programs, of course, we can use alternatives. That's
what they're there for. If this is not sufficiently easy for some
reason, perhaps it would be better to add a feature somewhere to make
it easier.
Can Gnome1 programs run on a Gnome2 desktop and vice versa ? If not
then we could invent a standard wrapper script that chooses the right
version based on the current desktop.
Runtime libraries are not supposed to be incompatible unless they have
different sonames and can coexist.
What other files are involved ?
> Some of these issues are subtle [for example: sawfish, where there's no
> difference between sawfish in gnome1 vs. gnome2 but there is a difference
> in what libraries it's (dynamically) linked against].
If the libraries are compatible, why not just keep linking against the
old library until the new one is truly stable ?
Ian.
Bug#154950: Gnome 2 transition
Raphael Hertzog writes ("Re: Bug#154950: Gnome 2 transition"):
> Have we ever offered that choice with KDE ? Why would you want to
> provide that choice for GNOME ?
The question hasn't arisen with KDE. Either this was a mistake, or
new versions of KDE are better in sufficiently nearly all situations
that it wasn't necessary to provide the old version as an option.
> Le Thu, Aug 15, 2002 at 12:49:14AM +0100, Ian Jackson écrivait:
> > install the Gnome2 from unstable alongside the Gnome1 from stable,
>
> That's not easily doable and nobody has ever proposed it in the
> debate.
Why is it difficult ? I must be missing something.
> > go in sarge. Why can't the Gnome2 packages keep the `2' suffix
> > forever ?
>
> Because user expect to have their usual gnome packages without that
> suffix. Because it's the simplest upgrade method without requiring dozen
> of compatibility empty packages.
I must be missing the requirement for dozens of empty compatibility
packages.
> > I am very strongly opposed to any attempt to provide `incentives' for
> > maintainers to do work in this way. Penalising our users, or making
> > life difficult for ourselves, in order to `encourage' people to do
> > something, is a very bad idea in a volunteer organisation. If
> > something isn't being done that you want done, go and do it. Don't
> > break things in an effort to force the issue.
>
> I'm sorry, but Gnome 2 won't wait until each uninteresting applet is
> ported ... it's up to the applet developer to do the work, and maybe
> they will do if they got complaints. If they don't, well the applet
> disappear, that's life.
The core message I was responding to was the suggestion that we should
deliberately break things to add incentives to update software.
The choice between Gnome1 and Gnome2 should be based exactly on the
question of which is better to have at the time. If Gnome2 gets to be
better than Gnome1 despite some Gnome1 applets not being available for
Gnome2 then fine. But pushing ahead with Gnome2 despite it being
worse due to the lack of those applets, to `encourage' the applet
maintainers, would be a mistake; instead, the effort should be put in
to port the applets, or do whatever else is the most effort-efficient
route to improving Gnome2.
(NB: that paragraph is all hypothetical. I've not heard any clear
statement about whether Gnome1 or Gnome2 is currently better.)
Ian.
Bug#154950: Gnome 2 transition
Christian Marillat writes ("Bug#154950: Gnome 2 transition"):
> Ian Jackson <[EMAIL PROTECTED]> writes:
> > What other [conflicting] files are involved ?
>
> Pixmaps files, .mo files, documentation files.
These can be put in different directories, surely ?
> > If the libraries are compatible, why not just keep linking against the
> > old library until the new one is truly stable ?
>
> Libraries aren't compatible. You can't recompile a GNOME 1 package
> against a GNOME 2 package. And GNOME 2 libraries are stable. 2.0.1 has
> been released 2 weeks ago.
So, taking the sawfish example, the _source_ has changed but the
resulting binary behaves similarly after the old version is compiled
against Gnome1 and the new one against Gnome2 ?
Ian.
Bug#154950: Gnome 2 transition
Christian Marillat writes ("Bug#154950: Gnome 2 transition"):
> The pixmaps path is harcoded in gnome libraies, this imply we need to
> recompile all gnome2 applications who use stock gnome pixmaps or store
> pixmaps in /usr/share/pixmaps
That shouldn't be too hard surely ? There must be a single place
where that path is specified, or at most a few places.
> For .mo files no. Those files are i18n files and are only read in
> /usr/share/locale by libc
You can specify a different domain_name in the textdomain() call; then
the .mo files (have to) have different names.
> Sawfish is a window manager, then he manage yours windows...
> The problem is configuration options. Sawfish 2 doesn't use all sawfish
> 1 options then if you reinstall sawfish 1 after sawfish 2 you lose some
> configuration.
That seems like a very bad way of handling configuration changes.
Also, let me just clarify: are you disagreeing with Raul's assertion
here:
On Fri, 16 Aug 2002, Raul Miller wrote:
> Some of these issues are subtle [for example: sawfish, where there's no
> difference between sawfish in gnome1 vs. gnome2 but there is a difference
> in what libraries it's (dynamically) linked against].
?
Thanks,
Ian.
Bug#154950: Thoughts on GNOME 2 transition
Raphael Hertzog writes ("Bug#154950: Thoughts on GNOME 2 transition"):
> I urge the technical committee to take a sensible decision (ie one of
> the three solutions proposed in my initial mail) quickly. [...]
You're right that we are taking too long. I'd like to propose that we
hold an IRC meeting between interested parties - not to decide, but to
discuss questions. We'd publish the log to this bug report, and I'd
write up a summary.
I'm available:
Thursday 29th Augustunavailable
Friday 30th August 1900 - 0200
Saturday 31st August0900 - 1300
Sunday 1st September0900 - 0200
Monday 2nd Septemberunavailable
Tuesday 3rd September 1900 - 0200
Wednesday 4th September 1900 - 0200
Thursday 5th September unavailable
Would everyone who would like to participate, please mail me privately
with their availability, and say which if any Gnome package(s) they
maintainer or any other relevant status they hold ?
Please pass this message on to appropriate people. If there's a
separate Gnome list it would be good to announce it there.
> If you provide us a resolution that imposes Gnome 2 and Gnome 1.4
> to coexist on the same system, you risk to have a bad precedent :
> nobody listening to the technical committee because the
> recommandation is completely inapplicable and has absolutely no
> supporters within the Gnome maintainers.
It does seem that you may be right on this point - that no-one wants
to make them coexist.
Ian.
Bug#154950: Thoughts on GNOME 2 transition
Christian Marillat writes ("Re: Bug#154950: Thoughts on GNOME 2 transition"):
> Ian Jackson <[EMAIL PROTECTED]> writes:
> > I'm available: [...]
> > Sunday 1st September0900 - 0200
> > Monday 2nd Septemberunavailable
> > Tuesday 3rd September 1900 - 0200
> > Wednesday 4th September 1900 - 0200
> > Thursday 5th September unavailable
>
> No preferences for me. But tell me if thst hours are GMT or not.
Yes, these are all GMT.
My current proposed time and date is Sunday 1st of September 1530 GMT.
I think this means Bdale ought to be able to make it, if he gets out
of bed too early. Bdale, is that OK ? No-one else has expressed much
of a preference yet.
Ian.
Bug#154950: Thoughts on GNOME 2 transition
Anthony Towns writes ("Bug#154950: Thoughts on GNOME 2 transition"):
> Any chance of making it closer to 23:30 UTC? That'd be 9:30 am Monday
> in .au, rather than 1:30 am; and around around 5pm wherever Bdale is. I
> imagine Jeff Waugh's in a similar TZ to me, and I imagine we'd both like
> to sit in.
Bdale has a flight out mid-Sunday his time, so won't be able to make
it then. Sorry, but I'm going to give priority to the people who
mailed me sooner.
But if this meeting goes well and we hold another meeting like this,
I'll be sure to try to (a) set the time more in advance and (b) try to
set a time that's tractable to people in .au too.
Thanks, and my apologies,
Ian.
Bug#154950: Thoughts on GNOME 2 transition
Robert McQueen writes ("Bug#154950: Thoughts on GNOME 2 transition"):
> This time is not ideal for myself and other interested GNOME2 type
> maintainery people in the UK, we're at large in Cambridge at that time,
> and not reliably net-connected (ie we may be doing something =).
I'm going to the Debian UK meet too. We should be able to work
something out so you can be in the meeting.
Ian.
Bug#154950: Thoughts on GNOME 2 transition
Anthony Towns writes ("Bug#154950: Thoughts on GNOME 2 transition"):
> Is the intention to hold it on #debian-devel or #debian-ctte on
> irc.debian.org or similar?
Reminder: we're having this meeting at 1530 GMT today, about 90 mins
from now. It'll be on #debian-ctte on irc.oftc.net.
Ian.
Re: Please organize the vote
Raul Miller writes ("Re: Please organize the vote"):
> The committee is about picking between choices which have been adequately
> discussed elsewhere -- the committee is not about designing detailed
> proposals to make these choices work.
Quite.
Jason Gunthorpe writes ("Re: Please organize the vote"):
> So, I really don't get the point of involving ctte.. There is no argument
> here. You've already decided.
That's the way it looks to me. I'm very puzzled as to why everyone is
waiting for the committee to make a decision when in fact there
doesn't seem to be anything to decide. Who disagrees with the
`modified solution 2' ?
Certainly I'm finding it really difficult to see my way in all this.
The lack of clear sides with clear statements of their points of view
is particularly troubling.
If we're being asked to choose between the three options Raphael
originally presented, then it would be nice (for example) if we could
have some names of proposers to put to each proposal ...
Ian.
Dale Scheetz has resigned
In the message attached, Dale resigned from the committee. Apologies to everyone for missing Dale's message the first time round. This leaves the committee with 7 members, and we're rather short of active people anyway. I'll dig out my draft call for applications. Dale, yes, of course you can stay on the list; it's public. [EMAIL PROTECTED]: please remove Dale from [EMAIL PROTECTED] Ian. --- Begin Message --- As you can see from my lack of involvement with this, IRC, and other matters before the committee, I'm not really serving in any capacity on the ctte committee. If you haven't already done so, please remove me from the committee. If possible I would still like to stay on the mailing list, as it contains the most interesting sources for information about what Debian is doing these days. I'm finding time to maintain libgmp, and little else. I haven't even had the time to finish the woody version of my book, although it is now at the top of my priority list ;-) The only thing working a 40 hour week brings is a steady trickle of money. The fact that my employment is in a non-comp-tech capacity, means I can't even hide a bit of Debian work amongst my regular workload (which has lulls, but is overall pretty steady work). Hope things are going well at your end, Dwarf -- _-_-_-_-_- Author of "Dwarf's Guide to Debian GNU/Linux" _-_-_-_-_-_- _-_- _- aka Dale Scheetz Phone: 1 (850) 656-9769 _- _- Flexible Software 11000 McCrackin Road _- _- e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308_- _-_- _-_-_-_-_- Released under the GNU Free Documentation License _-_-_-_- available at: http://www.polaris.net/~dwarf/ --- End Message ---
last call on Draft Call for Applications
I sent a very similar draft to the one below to the committee in August. No-one replied with any comments. Do I take it you're all happy ? If so I'll send it to d-d-a (after checking that the debian-ctte-private list actually works). Ian. To: debian-devel-announce Subject: Call for Applications to the Technical Committee Reply-To: [EMAIL PROTECTED] INTRODUCTION The Technical Committee is established by the Debian Constitution, section 6. We are the body which makes the final decision on technical disputes in the Debian project. (See http://www.debian.org/devel/tech-ctte.) Currently, the active members are: * Bdale Garbee * Ian Jackson (chairman) * Manoj Srivastava * Raul Miller * Wichert Akkerman * Jason Gunthorpe There is also one inactive member: * Guy Maor We feel that 6 is too small an active membership, and are considering adding up to two new members (replacing Guy if we decide to appoint two new members). In a breach with usual Debian tradition, we're doing this by posting a call for applications. The project is too large for us to know personally all the possible candidates. So, we would like to you to put yourself forward if you feel you are able and willing. Please also encourage people who you know are technically excellent to apply. JOB DESCRIPTION --- For you to apply, ideally: * Your technical skills are exceptionally good. * Your ability to reason and and argue is exceptionally good. * You are able to have a constructive discussion even when you disagree strongly with people. * You have substantial experience in the Debian Project; preferably, you will understand well both the technical and organisational structure. * You have a strong reputation and respect in the Project and elsewhere in the Free Software world. What the job involves: * You will have to read the list [EMAIL PROTECTED] Traffic is moderate; see the archives at http://lists.debian.org/debian-ctte/ * It is best if you participate in the discussions, when you have something relevant to say. * If you have been following a discussion, you should vote if and when the time comes (ie, simply sending a reply to a CFV email). The total time involved should be no more than 1-2 hours per week in busy times, and consists almost entirely of answering email. What is not very important: * You do not need to be available 100% of the time. If you take a holiday or have a work crisis, that's fine. The committee can function even with some absenteeism. * You do not need to currently be a maintainer of an important package or packages, or be deeply involved in other parts of Debian's key infrastructure. * You do not need to be an expert on any or all of the software in Debian; the design and behaviour of software should be explained during our discussions. APPLICATIONS Please send your application to [EMAIL PROTECTED] It would be helpful to you if you could provide some information to help us make our decision. * How long have you been involved with Free Software, and with Debian ? What is your current involvement with Debian ? * What TWO pieces of Free code that you have written are you most proud of, and why ? Please provide URLs so we can go look at them. * We would like to get an idea of your discussion skills by reviewing a couple of email or USENET argument you were involved in and you think you made a substantial and helpful contribution to. (It doesn't matter if the ultimate decision went against you.) Please provide TWO references, including URLs, to appropriate archive locations, and any commentary that you think might help your application :-). Notes: 1. You have until the 30 DAYS FROM NOW *** 2. Please try to keep your answers reasonably short. We don't want whole essays here. 3. URLs should be accessible with a variety of web browsers and not require registration or cookies. PROCESS --- The exact process will depend on the number of applications. If there are many, we may prepare a shortlist, first, and then publish, on debian-devel-announce, a list of the (shortlisted) candidates and will invite comments to be published, as well as being considered by the committee. Throughout we will keep the Project Leader informed. When we're done collecting information, and arguing, we will decide how many of the applicants (if any) we wish to appoint. If the Project Leader agrees, the new members are appointed. In accordance with the Constitution, our votes will be public. To avoid too much acrimony we will hold our actual discussions on the private mailing list, copying the Project Leader. When we are deciding, we will remember that it is much more impo
Disputes between developers - draft guidelines
such as `I will never implement that'. There is no shame in being convinced, by good arguments, to change your mind, even if you have just been vigorously propounding the opposite view ! In the case of a tradeoff between one good property and another, there are often value judgements to be made; these value judgements are usually best made by package maintainers, and other developers should allow the maintainer of a package some leeway. If discussing the issue with all the relevant people hasn't produced a conclusion and doesn't look like it will, the Technical Committee can decide. You can refer it to the Committee in the form of a bug report - see below; sending a summary of the situation to the Committee would be very helpful, too. 6. Bug report etiquette Sometimes bugs are reported inappropriately; likewise, sometimes maintainers close bug reports inappropriately. Bug reports are `todo list' items for the whole Project; they should be closed when there is rough consensus that the whole system is working as well as it could. For example, here are some examples of situations where a bug report should not be closed: * The bug was reported against A, reassigned to B, but the maintainer of B feels that B is working correctly (and by implication that the bug is in A). The maintainers should talk about it to decide which package needs to change, without closing the bug until it's fixed. * The bug was reported; the maintainer felt immediately that it was a spurious bug report of some kind, and closed it, but the submitter disagrees with the explanation and has reopened the report for discussion. The matter should be debated until both Developers are happy. While a situation is being discussed, any relevant bug report(s) should remain open. If a package maintainer closes your bug report, you may reopen it if you wish to continue the discussion. At no other time should you play `bug report tag' with anyone else. If someone makes a change to a bug report status which you disagree with you should *discuss* the matter with them but *not* immediately undo their action in the BTS, except to reopen the bug to stop it getting lost. If you are unable to reach a conclusion through constructive discussion, you should ask for outside help with resolving your dispute, as outlined above. Note that while the Technical Committee is also happy to help resolve disputes over individual bug reports, you should not refer a matter to the Committee until you have tried to explore the issue yourselves. When this has been done, the bug report logs should contain detailed description of the problem and records of your discussions, and you may then reassign the bug report to the pseudo-package `tech-ctte'. For more information about the committee, see http://www.debian.org/devel/tech-ctte. -- Ian Jackson, at home. Local/personal: [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.chiark.greenend.org.uk/~ijackson/
Standing in for the Tech Ctte chairman
And finally, in my barrage today: Remember that it's not just the chairman who can write up proposed resolutions, calls for votes, etc. So if I seem to be temporarily MIA, please do feel free to stick your oars in. Would it help if we semiofficially nominated a stand-in, who'd pick up drafting, chasing, etc. ? Ian.
No applications yet please (Re: last call)
Ian Jackson writes ("last call on Draft Call for Applications"):
> I sent a very similar draft to the one below to the committee in
> August. No-one replied with any comments. Do I take it you're all
> happy ? If so I'll send it to d-d-a (after checking that the
> debian-ctte-private list actually works).
>
> Ian.
>
> To: debian-devel-announce
> Subject: Call for Applications to the Technical Committee
> Reply-To: [EMAIL PROTECTED]
THAT WAS NOT A CALL FOR APPLICATIONS, IT WAS A DRAFT.
Please do not send any applications yet !
Thank you.
Ian.
Re: Disputes between developers - draft guidelines
Branden Robinson writes ("Re: Disputes between developers - draft guidelines"):
> Overall, it looks great. Thanks for working on this.
>
> I have a few suggestions, raging from stylistic and spelling corrections
> to the more substantive, reflecting my own observations of disputes
> (some of which have gone to the Technical Committee, and some which
> haven't). I'm also confused by one thing, which I've placed in
> brackets.
Thanks for your contribution.
> I'm attaching a diff, and my revised version in the event that it is
> useful.
I'm finding this quite difficult to read. I'll deal with it this
time, but can I suggest that for text documents, where you think the
changes are likely to want discussion, it might be better to express
your changes in prose ?
I'll respond in detail in private mail, to avoid the public discussion
getting bogged down in details so early on.
Ian.
Committee members please check you got my test
I've just sent a test message to debian-ctte-private. To avoid any problems with the call for applications that I'm going to send out, please let me know within the next few days if you didn't get my other test mail. Thanks, Ian.
Gnome (#154950) (was Re: Please organize the vote)
Ian Jackson writes ("Re: Please organize the vote"):
> That's the way it looks to me. I'm very puzzled as to why everyone is
> waiting for the committee to make a decision when in fact there
> doesn't seem to be anything to decide. Who disagrees with the
> `modified solution 2' ?
No-one has replied. So, I hereby propose the following resolution:
The Committee regret that we have failed to get to grips with the
actual dispute or issue in the question of bug #154950 and the Gnome
transition.
It seems to us that all of the original disputants and other
relevant participants are now agreed on a course of action, which
roughly resembles the `option 2' of Raphael Hertzog's original bug
report.
Therefore it seems to us that there is no longer a need for a
decision by the Committee. The bug report will be closed.
If anyone feels that the current course of action is wrong, and
wishes the Committee to once more take an interest, we would welcome
a clear statement of the issues and the dispute, and are fully
prepared to reopen the question (and the bug report), and to
reconsider.
Ian.
Re: Gnome (#154950) (was Re: Please organize the vote)
Colin Walters writes ("Re: Gnome (#154950) (was Re: Please organize the vote)"):
> On Tue, 2002-10-22 at 19:59, Ian Jackson wrote:
> > Therefore it seems to us that there is no longer a need for a
> > decision by the Committee. The bug report will be closed.
>
> That is correct. Please go ahead and close the bug.
I think normally I would just go ahead and do so. But given the
intense politics surrounding this one I'd rather have a vote on it.
So, I hereby call for a vote on my earlier proposal to close the bug
and vote in favour. Here's a copy if you missed it:
The Committee regret that we have failed to get to grips with the
actual dispute or issue in the question of bug #154950 and the Gnome
transition.
It seems to us that all of the original disputants and other
relevant participants are now agreed on a course of action, which
roughly resembles the `option 2' of Raphael Hertzog's original bug
report.
Therefore it seems to us that there is no longer a need for a
decision by the Committee. The bug report will be closed.
If anyone feels that the current course of action is wrong, and
wishes the Committee to once more take an interest, we would welcome
a clear statement of the issues and the dispute, and are fully
prepared to reopen the question (and the bug report), and to
reconsider.
Thanks,
Ian.
Re: Gnome (#154950) (was Re: Please organize the vote)
Raul Miller writes ("Re: Gnome (#154950) (was Re: Please organize the vote)"):
> [Aside: I'm not yet in a position to pgp sign anything.]
That's fine. If you see someone forging your votes, we can phone you
up to check what you really said :-).
Ian.
Re: Gnome (#154950) (was Re: Please organize the vote)
Raphael Hertzog writes ("Re: Gnome (#154950) (was Re: Please organize the
vote)"):
> Duh. You really do not need to vote just to decide nothing. :-/
> I'm the submitter of the bug, I'm closing it. Problem closed.
Thanks. That obviates the need for the vote, I think.
Ian.
Re: [herbert@gondor.apana.org.au: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]
So let me see if I can summarise what the pros and cons are, that have been mentioned so far: Pro: * Some laptop users and certain others who wish to use the console in better video modes have an easier life, as they can do so with the stock Debian kernel. How many people would benefit seems to be disputed, but it does seem clear from the BTS logs that the VESA fb is popular. Con: * A small increase in kernel size. This has not been quantified. Allegedly, including all drivers which are in roughly the same situation as VESA fb would increase the kernel size significantly. Do we have a list of other examples ? Herbert suggests arpd, sch_atm, lp_console, nfs_root I think it's clear that most of those are not really in the same position as VESA fb, because they are much more of a minority interest. nfs_root may be a good example (but there the boot disk argument Herbert's making is weakened, because there are good reasons why nfs_root might be useful on a rescue disk). The inclusion of quota support in the default kernel seems to make this a difficult argument to sustain, if the quota support is significantly bigger than VESA fb as Eduard Bloch maintains. * Herbert says that there is another driver, fbcon, which cannot be distributed in modularised form if VESA fb is included statically . But the argument for needing to distribute fbcon as a module - that it can be recompiled more easily - seems very weak to me. Issues that seem irrelevant to me: * I don't care whether it's easy to modularise VESA fb or not. If it's modularised then the dispute goes away, but at the moment it is not modularised and we cannot mandate that that work be done. We can only decide whether the non-modular version should be included. Issues that seem to have been dealt with: * Older non-VESA-fb kernels would present the user with a black screen if a previous VESA-fb-using configuration was used. This bug has now been fixed. * There was a question as to whether VESA fb breaks some machines, even when it is not used. It seems that no-one is arguing this any more. If there is some evidence to the contrary, it would be good to know. Please let us know what you think of this summary of the situation. Thanks, Ian.
Re: [herbert@gondor.apana.org.au: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]
Manoj Srivastava writes ("Re: [EMAIL PROTECTED]: Re: Bug#161931:
kernel-image-2.4.19-k7: VESA driver for console]"):
> I am not sure the latter follows. Certainly, there is a (small)
> vocal set of users, but popularity is still in question.
Well, certainly it's not decisive, but we're unlikely to get better
information. We're going to have to decide on the basis of the
information we have available, I think.
> >> Con:
>
> >> * A small increase in kernel size. This has not been quantified.
> >>Allegedly, including all drivers which are in roughly the same
> >>situation as VESA fb would increase the kernel size significantly.
>
> Lack of modularity in the kernel is a bad idea, and unless
> there is overwhelming need for it, I would much rather not taint the
> kernel with non modular code; in this I agree with Herbert.
This argument seems aesthetic, possibly even emotional, to me. Is
there actually any _problem_ with the non-modular code ?
(I should say that personally, I find kernel modules a mixed blessing,
and on my own systems often avoid them because of their extra
complexity. That's not to say that they're not useful in distribution
kernels, of course, but I think I should warn you about my prejudices ...)
> >>Do we have a list of other examples ? Herbert suggests
> >> arpd, sch_atm, lp_console, nfs_root
>
> >>I think it's clear that most of those are not really in the same
> >>position as VESA fb, because they are much more of a minority
> >>interest.
>
> What is the dataset you are basing this assumption on? I am
> not sure that they are in a different category at all.
Guesswork. No-one in this argument has any concrete data.
> >>The inclusion of quota support in the default kernel seems to make
> >>this a difficult argument to sustain, if the quota support is
> >>significantly bigger than VESA fb as Eduard Bloch maintains.
>
> No, unless you can prove that quota system popularity is as
> low as VESA popularity (looking at business use of Linux, that would
> be a hard argument to sustain).
Do business users often turn on quotas on desktop machines ? I'd be
surprised. For servers, of course, most people will (or should!)
build their own kernels.
Ian.
Re: [herbert@gondor.apana.org.au: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]
Herbert Xu writes ("Re: [EMAIL PROTECTED]: Re: Bug#161931:
kernel-image-2.4.19-k7: VESA driver for console]"):
...
> Who is supposed to make these decisions about how many people are
> interested? Should I ask you every time this comes up?
If you end up getting into a serious enough dispute about it, yes.
That's what we're here for.
> To sum up I'm rather worried if the basis of your decision is purely
> on the fact that you are satisfied that enough people are interested
> in VESA fb.
It seems to me that the question is precisely whether enough people
are interested in VESA fb.
Ian.
Re: [herbert@gondor.apana.org.au: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]
Manoj Srivastava writes ("Re: [EMAIL PROTECTED]: Re: Bug#161931:
kernel-image-2.4.19-k7: VESA driver for console]"):
> [Raul:]
> > I made an earlier comment on that discussion thread:
> > "This is an argument for the kernel architects. We're not kernel
> >architects, however -- we're distributors.
...
> You are making an assumption that thre is intelligent desing
> -- thet there is a coherent body of kernel architects, that encompass
> all subsystems and modules.
No, Raul is not making that assumption. He's just pointing out that
the decisions about kernel architecture need different considerations
to the decisions about what to ship in a distribution.
We may well agree or disagree with the current kernel structure, but
that's not what is being discussed here. The point about modularity
of the kernel is relevant when talking about how to implement new
kernel features, and whether and how to restructure the kernel.
I don't think it's relevant when we're trying to decide what to ship.
> I must confess that I can't imagine that the set of people who
> a) Can't live with text mode
> b) Can't use X
> c) Won't compile their own custome kernel
>can be very large at all.
This hypothesising doesn't explain why three separate people have
already filed bug reports about this. (Also, it's not really accurate
- you say `can't live with text mode', but apparently sufficiently
good text modes are not always available without VESA fb.)
> It all boils down to a non technical judgement call -- whether
> the worth function of modularity offsets the utility of a precompiled
> kernel containing vesafb for what maybe an infinitesimal audience;
> and whether we can come up with a convincing enough case to override
> a maintainer.
The alleged cost of the non modular VESA fb is still a mystery to me.
What bad consequences does it have ?
> I reiterate, overriding the maintainer must never be trivially
> undertaken, and ought not to be done on guess work, or without a
> strongly defensible case. None of which I see at the moment.
I disagree most fundamentally. Nearly all actual disputes will
involve cases where there is doubt and uncertainty, and will also
often include situations where there is disagreement about the value
of one thing versus the value of another.
We already have the 3:1 supermajority rule to prevent us from
overruling maintainers in cases of real doubt; we already can't
override a maintainer's decision unless we have (near) unanimity.
We have to realise that maintainers are human, and that therefore they
will sometimes make mistakes. Sometimes they'll been convinceable,
but sometimes - also because they are human - they'll not be
convinceable, even if they are wrong. We should not adopt a view that
says that the maintainer's opinion on a difficult question is
necessarily right !
If you, Manoj, actually agree with Herbert on this question, then you
should obviously vote accordingly. But if you agree with what seems
to be the position of Raul and myself, that including VESA fb has real
benefits (which are admittedly hard to measure) but no significant
costs, then I think you should vote accordingly.
Ian.
Re: [herbert@gondor.apana.org.au: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]
Raul Miller writes ("Re: [EMAIL PROTECTED]: Re: Bug#161931:
kernel-image-2.4.19-k7: VESA driver for console]"):
> On Sun, Oct 27, 2002 at 01:37:43PM -0600, Manoj Srivastava wrote:
> > What I am unsure about is whether I have the grounds to cause
> > my judgment to override the maintainers in this case. I don't have
> > the hubris to assume that I know so much better than the maintainer.
>
> I think we can trust the developer to explain his reasons. We're not
> expected to be omniscient.
>
> Herbert has already said that he'd go along with our decision. And,
> from the way the discussion has gone, I trust that means that he's
> already said everything he has to say on the subject.
I agree, and I'm just about to write up a draft resolution.
Ian.
Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console
I think all that's going to be said has been said. So I hereby propose the following resolution and immediately call for a vote. 1. The Technical Committee has considered the question of whether VESA fb support should be compiled into the default kernel, as requested in Bug#161931. 2. We have concluded that: * inclusion has significant benefits for some users, and * inclusion has no significant costs. Therefore, the VESA fb driver should be included. 3. In particular, we have considered the following supposed downsides to including the driver in the distribution kernel: a. That the increase in kernel size (while not significant for just VESA fb) due to including all other non-modular drivers in a similar position, would be significant and perhaps problematic for boot floppies etc. This question is difficult to analyse conclusively, but we feel it is largely unsubstantiated. If demand for many other similar drivers turns out to be similarly high, and including them is a problem, we are certainly prepared to make specific decisions in specific cases, and/or revisit VESA fb as part of a broader question. b. That the non-modularity of the VESA driver harms the kernel architecture. This is clearly relevant for a kernel architect, when choosing what drivers to include in a source tree. However, we do not feel that it is relevant when - as distributors - we consider which drivers to enable or disable. 4. Accordingly we request (or require, if the required supermajority is reached according to the Constitution) that the Debian kernel maintainers change the configuration to include the VESA fb driver in the default kernel, at their earliest convenience. Ian.
Barfmail when trying to reach to Ian Jackson
My apologies, but I got caught out when an RBL-style blacklist operator (of a blacklist shut down by a lawsuit threat) decided to suddenly start blacklisting the whole internet. I thought I was keeping an eye on the relevant places where such things might be announced, but apparently not closely enough. Anyway, so if you tried to mail me and got this message 550 Your site is realtime-blacklisted (inputs.orbz.org: Mail rejected because the server you are sending to is misconfigured.) then it was my fault (in some sense, anyway) and I'd appreciate it if you'd resend it now that I've fixed the problem. As ever, if you have any kind of problem mailing me, please mail [EMAIL PROTECTED] and I'll help figure out what the problem is, and fix it if it's at my end. That address bypasses all the policy filtering, of course, and gets a lot more rapid attention than most of my other addresses. Thanks, Ian.
Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console
Raul Miller writes ("Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for
console"):
> [details of proposal elided]
>
> I think this proposal matches the best information we have available
> and I vote for this proposal.
So, would everyone else please vote ? If you don't have an opinion or
don't want to vote, please explicitly abstain. That will shorten the
voting period due to the `no longer in doubt' rule.
I didn't say so earlier, but obviously I vote in favour of my
proposal too. Here's another copy, in case you missed it:
1. The Technical Committee has considered the question of whether
VESA fb support should be compiled into the default kernel, as
requested in Bug#161931.
2. We have concluded that:
* inclusion has significant benefits for some users, and
* inclusion has no significant costs.
Therefore, the VESA fb driver should be included.
3. In particular, we have considered the following supposed downsides
to including the driver in the distribution kernel:
a. That the increase in kernel size (while not significant for just
VESA fb) due to including all other non-modular drivers in a
similar position, would be significant and perhaps problematic for
boot floppies etc.
This question is difficult to analyse conclusively, but we feel it
is largely unsubstantiated. If demand for many other similar
drivers turns out to be similarly high, and including them is a
problem, we are certainly prepared to make specific decisions in
specific cases, and/or revisit VESA fb as part of a broader
question.
b. That the non-modularity of the VESA driver harms the kernel
architecture.
This is clearly relevant for a kernel architect, when choosing
what drivers to include in a source tree. However, we do not feel
that it is relevant when - as distributors - we consider which
drivers to enable or disable.
4. Accordingly we request (or require, if the required supermajority
is reached according to the Constitution) that the Debian kernel
maintainers change the configuration to include the VESA fb driver
in the default kernel, at their earliest convenience.
Ian.
