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: Can we reject HTML mail ?
Previously 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. stick this in the procmailrc filters on murphy: :0 * ^Content-Type: *text/html.* /dev/null -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Can we reject HTML mail ?
On Sat, 27 Apr 2002, Ian Jackson wrote: Eh ? I thought we'd unmoderated the list. mmm, in that case you are probably looking at old spam that pre-dates the spamassasin setup. I haven't got any on the ctte list since then.. Jason -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian Looking at the situation, I think that the definition of Ian `serious' bug report is rather unhelpful and does not match up Ian with the use of `must' or `required' in policy. What makes you say that? Serious is defined as a violation of a must or required directive of policy; I fail to see how this could not match up with the use of `must' or `required' in policy; they are identical ways of saying the same thing. Ian The idea in the BTS seems to be that a serious bug is one which Ian makes a package unsuitable for release. This is where the disconnect is. The release manager decides what is or is not fit for release. The general guideline is that a violation of a must directive in policy is likely to be cause for the release manager to reject the package. The final decision lies with the release manager. Ian How about if we change the wording in `Severity levels' in the BTS Ian documentation (http://www.debian.org/Bugs/Developer#severities). Ian Currently it says: Ian serious Ian is a severe violation of Debian policy (that is, it violates a Ian must or required directive), or, in the package Ian maintainer's opinion, makes the package unsuitable for Ian release. Ian How about: Ian serious Ian is a severe violation of Debian policy or any other problem, Ian which makes the package unsuitable for release. This is bogus. You have changed a stright forward, objective criteria for a serious bug, softening it to where it has no meaning. The output of your program makes my nose twitch, this is obviously a problem, and this bug is thus critical. Ian This definition makes `serious' correspond identically to the Ian package's suitability for release. It avoids defining `severe' Ian violation of policy as a violation of a `must'; that seems to me to be Ian the core error. This change would avoid violations of exceptionless Ian policies (which are of course always bugs) always being treated as Ian release critical even if they're unimportant. No, the core error is that you are taking away from the release manager the task and responsibility of determining release criteria. Did you ignore everything that I and aj wrote? Would you please catch up instead of jumping in late, and ignoring the advances and arguments already made? 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 Ian If you and Anthony agree then maybe we should see if we can get that Ian changed. If you disagree I'm sure you'll let us know :-). I strongly object to turning the criteria upside down and creating a situation where bug severities are even more subjective. This is a far worse situation than we find ourselves in now. manoj -- A lady with one of her ears applied To an open keyhole heard, inside, Two female gossips in converse free -- The subject engaging them was she. I think, said one, and my husband thinks That she's a prying, inquisitive minx! As soon as no more of it she could hear The lady, indignant, removed her ear. I will not stay, she said with a pout, To hear my character lied about! Gopete Sherany Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
