S Woodside wrote:To add to this, sorry for the spam but I think this is relevant/important. A lot of the discussion on this list seems to assume that those involved consider modifying the AxKit code itself to be a reasonable solution ... to me that's just not an option. Sure, I could probably do it (after a week of learning more perl) but I'm not interested and I'd rather spend my time learning XSLT etc. So suggestions of the nature of "it could be hacked to make that work" are somewhat unhelpful.
I won't speak for anyone else here but I do understand your frustration.
Maybe I'm missing something here. Maybe there's a perl culture aspect, where people are expected to hack on their tools, even "end-users".
Reality is, though, that AxKit is an Open Source project and that implies several things: First, that it is a volunteer effort-- every line code is the result of someone either needing to meet their own specific requirement, or having a good idea and enough free time and chutzpah to implement it.
I understand that, and indeed I have contributed although in a peripheral way, by providing OS X / fink instructions and a bit of work on the Wiki. But perhaps I need to be hacking on the perl code to really qualify?
Second, AxKit being OSS means that, sometimes, more is expected of its users. Granted, patching the AxKit source is not always an option for for everyone (even if they do know Perl) but if a person can't patch, the very least they can do is provide a detailed report that includes a reproducible test case, stripped down to the minimum needed to expose the suspected bug.
[...]
Perhaps you might explain how a known problem on a particular version of a particular Linux distribution is exactly an "AxKit problem"? It looks like none the the AxKit commiters run this particular flavor (I don't), so there's no way for us to to even duplicate the problem, let alone create a work-around for potato's braindeadedness. What do you honestly expect us to do?
I never claimed that it was an "AxKit problem" or that anyone on this list should do anything about it. I do find it a bit odd that no one else is running on Debian 2.2 any more, but hey, whatever, it's pretty old.
[...]
Next we have the "AxKit and xsltproc give different results" post...
Here you provide copious amounts of information, but never once simply state *what* the differences are, nor do you even attempt strip things down to a minimal case that duplicates the problem. Do you honestly expect that we should not only help you solve your problem, but help you define what the problem is in the first place?
Simply saying "I see nothing obviously" wrong would have helped. It will certainly take time to create a minimal test case and I can short-circuit that if I package it up (which I did) and someone else says "no, your htaccess has the wrong bit set". Am I wrong in trying to eliminate the possibility of an obvious error before I start serious debugging?
For the record, I found a bug in LibXSLT that I worked out through the XSL-list (since it was exposed in xsltproc). I posted a fairly hefty test case first and people asked for a slimmed down version so I provided that. Eventually the bug was fairly simply exposed and Daniel gave me a workaround and fixed it in CVS. I was not particularly irked because I was doing something fairly obscure with XSLT.
I could easily nuke you back to the Stone Age for what I consider to be a selfish and demanding attitude, but I won't. For the most part, I find the ideas that you put forth here to be an interesting part of the chorus and I'd hate to lose them. That said, however, you need to seriously re-examine your expectations about value, collaboration, and whose job it is to solve your problem du jour.
Well maybe I just set up an incorrect set of expectations when I joined the list. AxKit is on 1.6.1 and it's not claimed to be beta software. It seems to be in production use in at least a few systems. Normally (it seems to me) at this stage an end-user isn't expected to hack the code in the tool in order to make it work, but that's the strong sense I get of what's expected here.
On the other hand, if that's part of the perl culture then maybe that's why more people aren't using it... Flame away if you want, I have fire-proof underwear.
simon
-kip
-- www.simonwoodside.com -- 99% Devil, 1% Angel
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
