Re: Another voice
On Mon, 13 Jan 2003, Kamil Toman wrote: Bugzilla may help a bit (if it was activelly maintained). I don't expect bugreports regarding x-protocol. Indeed, such type of bug report is extremely rare. I'm quite sure that most of reports would concern drivers. I can back that up with my own experience. Almost all bug reports that come into our database are either: 1) Driver related 2) Configuration related 3) App related There are other bug categories too of course, and it would be interesting to divide up X into different categories, then go through and get statistics on those categories. The plus is that such bugreports can be easily categorized (per driver) and seen only by interested people (driver maintainer, contributors and maybe some power-users), another that (at least some) people will stop asking about the same all over again (there are even volunteers outside projects who often help marking duplicates and nonsential bugreports). More general reports could be forwarded elsewhere. Yep. That is basically what I see on a day to day basis. Another point of view: Bugzilla can be thus seen (and used!) as an email filter + advanced search. Thus (if set properly!) can substantively reduce the amount of mail a developer/maintainer/contributor of a smaller part has to skim through. Of course, you could subscribe into many smaller lists than devel but who does it (especially if the chance of any response is smaller?) There are also people who do care about a particular bug only... Indeed. Some developers just read the bugzilla emails, and prefer to work with stuff in that context, only using the web interface when they need to. I use both myself. I sometimes use my email folder for quick searches, and to flag bug reports in pine with a * for looking at later today. There are many ways of using the tool though as there are developers that use it. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Sun, 12 Jan 2003, Mark Vojkovich wrote: Is a bug tracking system necessarily imposing? Perhaps it's not well understood what's really involved with one. Keeping track of what is broken and when it gets fixed seems like a good idea to me. What does this impose on developers? Nothing is imposed on developers at all. If we were to hypothesize that tomorrow, all of a sudden a bugzilla database sprung up for XFree86, I think it would take a while - not long, for it to get set up, organized, get the quirks out, and start getting useful data input. There are already tonnes of volunteers knocking on the door to triage, and help maintain such a thing. I can't speak for anyone but myself, but all I'd request, would be for people to look at such an effort with an open mind, and to at least voluntarily try it on their own free will, and provide whomever would be running it with feedback about what they like/dislike, and such. In other words, all that is really being requested, is open mindedness, and open co-operation to try new things that are likely to help the project. I think frivilous bugs and non-bugs being reported could be a potential time waster. Yes, they can be a bit of a time waster. That's why developers would not at all be expected to do anything they do not want to do voluntarily. The whole idea is _completely_ volunteer based. Volunteer as in, people contribute to the bug database only if they want to, and how much they want to, and they only do _what_ they want to also. I for one would be the first person to tell someone to take a long jump off a short dock if they demanded anything of me. I'm sure many people reading this email will vouch that I do that right now in fact. In fact, I volunteer to be the person who tells other people to take a long jump off a short dock, if they make any demands on other developers also. ;o) Who gets to file bugs? It might be a good idea to discuss that with the various people whom would actually volunteer to help out at the beginning, and also receive input from those who aren't willing to volunteer, but are willing to look at it with an open mind. Personally, I think having the database be open to the public is a good idea, and it has proven to be a good idea with many other large projects. As long as there are people to triage, and trim out the riff raff and useless crap (like 90% of the bug reports traditionally received on the existing bug report mechanism), and people volunteering to help get bug reporters to provide proper information and details until there is something useable for a developer to look at. Many people have volunteered already to participate in such an effort, and many of those volunteers already do triage on other existing bugzilla databases out there. Who determines whether they are legitimate or not? I suppose anyone can do that. If a developer says this is not a valid bug report, that is pretty close to the final word in lieu of more details from the reporter or someone else. Some bug reports are rediculously useless - no question. When I get those, if I can't get information out of someone that is useful, their bug report hits the can. Does a bug tracking system necessarily complicate the work that some developers do? I can speak from both sides of the fence on that one. I used to HATE bugzilla (and I can hunt down my email postings on this subject for proof if need be grin) until a short while after I begun maintaining X for Red Hat. I get bug reports via email still, and I also get bug reports from the XFree86 bug report list. I can say, without a question, the quality of the bug reports received on the [EMAIL PROTECTED] bug submission list, is close to zero on 60-90% of all submissions. Bugzilla bug reports concerning XFree86 on the other hand, generally have a much higher information to noise ratio, and since there is a simple method of 2 way communication involved, I can easily ask the person for more information. Also, _anyone_ else can also ask the person for more information, and many people do, including other employees, other users, and a few people who just seem addicted to helping with bugzilla. There are a heck of a lot of volunteers out there though that take care of some of the tedious boring stuff like finding duplicates and closing them as such, closing already fixed issues, requesting more information, and the variety of other things that bug tracking needs doing. I delete bug reports sent via email directly to me on first sight, and I also delete emails unread where someone has replied to the email message bugzilla sends out that specifically says do not reply to this email. I do so because if I respond, then I have to email back and forth with the person, and remember their situation, store the emails that are related to their problem, and stand on my head simply because they can't read do not reply via email, use
Re: [Devel] Re: Another voice
The Linux kernel for example has a very large source code base, and has countless developers whom have worked on it under the Bazaar model, and the code is quite high quality. People write good patches, and people write bad patches regardless of what model of development is used. However, I think that due to the bazaar style of development the kernel is done under, the bad patches get weeded out much more easily, whereas with the cathedral style of development, they're more likely to simply get ignored or cast aside. Is that similar to what you mean? This seems to be another angle ;) My point was that the easier it is for patches to go in the more attractive the project looks to new developers. I couldn't agree with you more. Personal experience: I had a simple patch to fix a typedef in the kernel, mailed to Alan Cox; reply less than 5 minutes later: 'applied to my pool'. Appeared in the next Linux release 3 days later. These days, with bitkeeper, the patch would be widespread almost instantly. This is *strong* incentive to contribution. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Egbert Eich [EMAIL PROTECTED] Sent: Monday, January 13, 2003 10:45 AM Subject: Re: [Devel] Re: Another voice Sender: [EMAIL PROTECTED] From: Egbert Eich [EMAIL PROTECTED] Date: Mon, 13 Jan 2003 11:10:14 +0100 To: [EMAIL PROTECTED] Subject: Re: [Devel] Re: Another voice - Matt Wilson writes: I'm not attempting to bully anyone, nor have I argued that you or any other member (individual or corporate) of XFree86. However, there are plenty of volunteers that are offering to set up and maintain a bug tracking system for you. I think that such a project would be much more successful if it were endorsed by XFree86 and integrated into the development policy for the project. Matt, I'm *very* uncomfortable with saying a bug tracking system should become policy for any project unless/until a project has a pretty universal buy in that it should be that way. We're a *very* long way from that point. Sorry, this is not how it goes. We won't be willing to adopt anything blindly. There is a German saying applying here: 'Never buy a cat in the bag!' 1. First there should be a proposal Seems like that's what some of us have been making, though we haven't fleshed it out completely yet. Without discussion, it is difficult to make it concrete. Ergo, the discussion. 2. Secondly there should be a test implementation as proof of concept we can work with and see how well it goes. Entirely agree. 4. Thirdly this should be evaluated - if we think it is usable at all. - what modifications we would like to see. Entirely agree. 5. The modified system needs to get retested and reevaluated. Entirely agree. 6. This is the earliest stage we can talk about a more or less formal policy. Entirely agree. Any policy, however, can/should only occur if there is nearly complete consensus. We're a long way from that, if ever. Up to now it is not even clear who should be able to submit to this bug tracking system: Very good questions on which multiple opinions are solicited. Should it be internal only? Should only projects like GNOME, KDE etc and distributions like RedHat, SuSE, Mandrake be able to submit bugs? Or should it be open to the general public? I personally argue for openness, with a couple major caveats: o The verbiage around bug submission should be carefully crafted to try to help with the triage process between projects (e.g. if your server crashes, its definately an XFree86 bug; if it is bad rendering, asking people to verify it is specific to a particular piece of hardware, else report to the appropriate project's bug system, and so on. o the states of a bug inside the database allow for triage, with states like bug verified, duplicate, etc. I suspect/expect many developers might ignore problems until they've been marked verified. That's the point of a triage process: to bounce the problem the right direction so that not all bugs get looked at by all people (or no people). One could go through an evolutionary process, from developers, to invited others, to fully open. The question still is: is there enough interest among the developer community to it be worth the investment to get it set up? If no-one is going to use it, why bother? On the other hand, if enough of us say, as I do, that we're dropping too many problems on the floor and such a system might be useful if it gets established correctly, I think there is enough resources to start getting it set up. But those resources should go elsewhere if there is no interest. And who would determine the 'no interest'?. Is this mutual or some arbitary self-appointed person? Georgina - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Mon, 13 Jan 2003 [EMAIL PROTECTED] wrote: This seems to be another angle ;) My point was that the easier it is for patches to go in the more attractive the project looks to new developers. I couldn't agree with you more. Personal experience: I had a simple patch to fix a typedef in the kernel, mailed to Alan Cox; reply less than 5 minutes later: 'applied to my pool'. Appeared in the next Linux release 3 days later. These days, with bitkeeper, the patch would be widespread almost instantly. This is *strong* incentive to contribution. I have had many similar experiences with different projects as well. Most projects like that have more heirarchial tree structures of developers though I find than a flat list. I think it's a difference that shows up more in the bazaar type of development more naturally than it could in the cathedral style. Perhaps the age old bazaar style motto: Release early, release often. Could be also enhanced with: Patch early, patch often. I know that many people don't contribute code simply because they've been ignored, or FEEL they've been ignored, and have no incentive to attempt to try and contribute again. So I can certainly relate to what you're saying also. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
Mark Vojkovich wrote: ...snip... Where I work, bug tracking is necessarily tied to source control in rather strict ways. Ways that I don't necessarily like, and would not want to see XFree86 emulate. But I can envision non- intrusive bug tracking. Mark. This might be a good topic for discussion. In the MediaGX driver, bugs have appeared and disappeared without any obvious coding changes. I have much less time than I devoted to the initial 4.X driver but a good tracking system might help. I found it too discouraging to work on the driver when changes elsewhere in the server changed the behaviour. Devoting more time might be the obvious solution but I prefer to focus on maximizing the results of whatever time I happen to devote. Richard ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Devel mailing list changes.
On Sun, 12 Jan 2003 09:14:19 +, David Woodhouse wrote: Please could we drop the [Devel] which serves no useful purpose and just obscures the _real_ subject line? I'm very surprised anyone would object to this. This tag, which is common to mailman lists, is enormously useful for e-mail filtering. It certainly helps me distinguish mailing list messages from the depressingly vast array of e-mail I already get just by scanning my inbox. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Devel mailing list changes.
On Mon, Jan 13, 2003 at 11:00:01AM -0800, Tim Roberts wrote: I'm very surprised anyone would object to this. This tag, which is common to mailman lists, is enormously useful for e-mail filtering. It certainly helps me distinguish mailing list messages from the depressingly vast array of e-mail I already get just by scanning my inbox. The List-Id header is there precisely for the purpose of mail filtering, and if you're overwhelmed by email, you might want to use it. :-) On top of that, a subject tag of Devel is really not very useful; I subscribe to dozens of development lists, and Devel is fairly ambiguous. :-) Those of us who do filter our mail into separate folders and still read email on a 80x24 terminal would really like the screen line real estate back. :-) -- Edward S. Marshall [EMAIL PROTECTED] http://esm.logic.net/ Felix qui potuit rerum cognoscere causas. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
No Digests?
After coming in to find 170-odd messages from the new [Devel] list in my inbox, I decided to switch to digest mode. However, mailman tells me that the list administrator has disabled digest delivery for this list. Any particular reason why this is so? -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xterm on Mac OSX
Hans Mittendorf wrote (in a message from Monday 13) Hello, Installing X11 on a Mac under OS 10.2.3 gave a problem related to typing inside xterm from a french keyboard. For typing m¹ I have ;¹. Changing keyboard to US via software, does not change anything. Therefore, my question: does XFree86 4.2.1 support french keyboards? Are you referring to XDarwin or the X11 package from Apple ? XDarwin has a global preference to set the keyboard layout, but it needs to be restarted to take effect. AFAIK Apple's X11 need a command line option to speficy the keyboard layout. Both X server can't change their layout from the main OS X menu bar. If you want to change your keyboard dynamically (ie without restarting X) on Mac OS X, you can use xmodmap(1). Appended below is set of xmodmap commands to set up an french layout keyboard. For more information see the xmodmap manual page. -- cut -- keycode 234 = Mode_switch remove mod1 = Alt_L remove mod1 = Alt_R add mod1 = Meta_L !add mod3 = Mode_switch !keysym Alt_L = Mode_switch Alt_L keycode 61 = at numbersign keycode 38 = ampersand 1 keycode 39 = eacute 2 keycode 40 = quotedbl 3 keycode 41 = apostrophe 4 keycode 42 = parenleft 5 keycode 43 = paragraph 6 keycode 44 = egrave 7 keycode 45 = exclam 8 keycode 46 = ccedilla 9 keycode 47 = agrave 0 keycode 53 = parenright degree keycode 54 = minus underscore keycode 50 = BackSpace Delete keycode 28 = A keycode 34 = Z keycode 55 = dead_circumflex dead_diaeresis keycode 56 = dollar asterisk keycode 12 = Q keycode 59 = M keycode 60 = ugrave percent keycode 58 = grave sterling keycode 108 = less greater keycode 37 = W keycode 24 = comma question keycode 62 = semicolon period keycode 63 = colon slash backslash bar keycode 64 = equal plus -- cut -- Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Mon, 13 Jan 2003, Georgina Economou wrote: [Extremely large nontrimmed quote snipped] Since I am a member however, I get both of these lists automatically and can't be sure if they're public now or not. A member? A member of what? The public lists? Not sure to what memberhsip you are referring. Sorry.. XFree86.org member is what I was refering to. Prior to the recent list changes and whatnot, only XFree86 member developers to my knowledge had the ability to subscribe to the fixes@ and patches@ mailing list addresses. I asked other people and they were of the same assumption. Just seeking clarification of wether or not the general public has access to subscribe to the 2 patch mailing lists now or not after David declared the private lists to be no longer private. Since I've received them all along, as an XFree86.org member developer, and still do, it's easier to ask than to try and test because if I attempted to subscribe, being already a member, it would likely succeed. Thanks in advance, TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
Mike A. Harris wrote (in a message from Monday 13) I'd be interested also in hearing feedback and comments from Debian, Mandrake, SuSE, Gentoo, FreeBSD, NetBSD, OpenBSD, Caldera, and other Linux and BSD distribution XFree86 package maintainers, and other developers also. I've talked personally with some of them already, but the more who get involved the better. We all benefit, and everyone's feedback is very valuable. In my opinion, a bug tracking system would help, but as others already said, setting up and maintaining such a system in a useful state is a really time-consuming task. The Gnats systems used in OpenBSD (and in other BSDs too) is not perfect, but it has been proven itself useful in a few occasions, although not all submitted PRs get handled. On the other side, I've seen other projects where the bug tracking system totally failed : no one would take the time to fill reports and anyways no developper ever bothered to look at the few reports that were filed. A bug tracking software per itself doesn't prevent bug reports from staying unanswered for weeks nor does it automagically insure that fixes are correct. Only the work of the people reviewing and editing the contents of the database can produce those effects. If some people are seriously volunteering to go through a specification and review process to setup a system that will be bring something the project, let's start it. If done right it will help to focus developper attention on things that need fixing. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another voice
On Mon, 13 Jan 2003, Vladimir Dergachev wrote: So.. any chance of GATOS getting into XFree86? ;o) This question gets asked very often. The answer is that part of GATOS is already there. The part that isn't is TV-in and hardware Xv for mach64 cards. And it was submitted but it takes quite a while to get in. The major reason for this is that ATI driver maintainer and me have different priorities: My impression is that ATI driver maintainer (Marc please correct me) is primarily interested in * clean and working code that is easy to maintain which, IMO, is a worthy goal. My priorities are: * robust (non-crashing) driver that supports new features * experimentation with new approaches to programming and new features These two do imply clean and easy to maintain but in a significantly different way. Also both of us are quite short on spare time. That, pretty well, sums it up. And more of GATOS will be merged shortly. I know I promised earlier to get the merge done before 4.3, but that just didn't happen, sorry. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: programming question: Window Information
On Mon, 13 Jan 2003 16:43:14 +0100 (CET) Krasi Zlatev [EMAIL PROTECTED]
babbled:
I would like to gather inforamtion about all the
running X applicaiotns.
Thus I do
Window root = RootWindow (dpy, screenno);
XQueryTree (dpy, root, dummywindow, dummywindow,
children, nchildren);
for (i = 0; i nchildren; i++) {
if (XGetWindowAttributes(dpy, children[i],
attr) (attr.map_state == IsViewable)) {
XFetchName(dpy, children[i], win_name);
printf(Window ID: 0x%lx\n,children[i]);
}
}
I thought that win_name will contain the name of the
window, but it is always null,
what am I doing wrong?
short answer and you'll figure it out yourself:
xwininfo -tree -root
:)
long answer:
x loves windows. it isnt single level like mac os (a root and then windows).
it's a big big big VRY deep tree. client window will be 2 or 3, maybe 4
levels down (this may vary depending on how deep your wm likes to reparent
client windows within its scheme of things).
you need to keep traversing the tree down as far as you can go (ALL the way...
do NOT just stop at the first window with a title... it IS possible that client
windows can be managed within other client windows... ie MDI style). :)
--
--- Codito, ergo sum - I code, therefore I am
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
[EMAIL PROTECTED]
Mobile Phone: +61 (0)413 451 899Home Phone: 02 9698 8615
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Sun, Jan 12, 2003 at 07:36:57PM -0500, Matt Wilson wrote: As for providing resources - we've done this for many projects that have approached us. For example: [msw@sid openoffice]$ host bugzilla.gnome.org bugzilla.gnome.org has address 209.116.70.84 [msw@sid openoffice]$ whois [EMAIL PROTECTED] (snip out big reply pointing to Red Hat, Inc.) [msw@sid openoffice]$ host stage.mozilla.org stage.mozilla.org is an alias for hemosaur.mozilla.org. hemosaur.mozilla.org has address 66.187.233.204 [msw@sid openoffice]$ whois [EMAIL PROTECTED] (snip out big reply pointing to Red Hat, Inc.) These resources come out of projects finding themselves in need and requesting assistance. Thus far the only thing I hear from you is that XFree86 doesn't need a bug tracker... Hosting isn't the type of resource I'm referring to -- we're fine on that thanks. I mean the much more difficult to find (non-volunteer) people resources needed to make a bug tracking system really work without sapping development resources -- like IBM is doing with the Linux kernel. If you're offering something like that, then I'm all ears. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Devel mailing list changes.
On Tue, Jan 14, 2003 at 01:05:45AM +, David Woodhouse wrote: Like Reply-To:? Now the status of the list has changed, is the decision to have a Reply-To: header added also up for reconsideration? :) We have to draw a line somewhere :-) David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Sun, Jan 12, 2003 at 09:14:41PM -0500, Jeff Garzik wrote: On Sun, Jan 12, 2003 at 07:23:37PM -0500, David Dawes wrote: Since you mention those $200 Walmart systems, has anyone actually seen one? They don't have them in any Walmart I've been to -- only the $600+ HP and eMachines systems. Yes I have seen the same. Thanks for the info. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Devel mailing list changes.
[EMAIL PROTECTED] said: I'm very surprised anyone would object to this. This tag, which is common to mailman lists, is enormously useful for e-mail filtering. It certainly helps me distinguish mailing list messages from the depressingly vast array of e-mail I already get just by scanning my inbox. If for some reason you don't want to filter list mail into a separate folder for each list, and you _really_ want the subject noise, it's trivial to do -- just insert a mail filter on the SMTP sender of the mail list everyone else does, only have it insert whatever you like into the Subject line instead of filing into an appropriate folder. But please make sure you remove the noise again if you reply to such mails. The fact that GNU mailman ships with this crap on by default is a serious bug, IMHBCO. It's not 50/50, because adding it locally is so much easier than removing it locally, for those users who have a strong preference either way. It is far more of a problem to _remove_ the noise if it's been added by a misguided mail admin. You can manage to remove it for the majority of posts, but when a message is cross-posted to another such list, you get its crap also polluting the subject line too, and you can't easily filter that out. [EMAIL PROTECTED] said: The List-Id header is there precisely for the purpose of mail filtering, [EMAIL PROTECTED] said: That is why all GNU mailman mailing lists have a header line: X-BeenThere: [EMAIL PROTECTED] Both of these give false positives. Consider the situation where you have such a filter in place, but have unsubscribed from the list or are reading it with 'grep' because you've been out of the office. Your colleague/friend/cat sees a message he knows you need to see, but will probably miss due to the circumstances above. He bounces it to you, headers intact, or to another internal mailing list or something. Your mail filter then sticks it in the folder for the original list and you still don't see it. It's rare, but it's happened to me at least once, before I fixed my filters. The only 100% reliable way to filter such mail is on the SMTP reverse-path, which depending on your MTA is usually either the Sender: or Return-Path: header by the time it gets to your procmail filter. :0w:$MAILDIR/lists/Xdev/.procmail-lock * ^Return-Path:.*[EMAIL PROTECTED] |$HOME/bin/MHstore +lists/Xdev Not that it really matters _that_ much, but if you're encouraging people to filter sensibly, you might as well give a 100% reliable solution. [EMAIL PROTECTED] said: Enjoy many lists whom use the subject line listname annoyance in complete peace and harmony, and without getting sucked in to 50/50 flamewars. As I said, it's not 50/50. It's been fixed on this list now, thankfully. This leaves you tonnes more time to participate in other, much more worthy flamewars that might also seem equally pointless, but for which procmail can't help. ;o) Like Reply-To:? Now the status of the list has changed, is the decision to have a Reply-To: header added also up for reconsideration? :) /me runs... -- dwmw2 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
