I offered a small patch to a well known project; a patch which would make request handling more interactive and less bursty. A developer whom I respect suggest a slight variation which he felt was nearly as good (his words), and requested that I write a test to prove that "nearly as good" was good enough so that this variation could be accepted into the baseline instead of the patch I was offering.
We spent more time arguing over this than it would have taken him to write this test, and so justifiably he felt very annoyed as if I were trying to get him to do my work for me.
From my own view I did not propose his patch and was damned if I was going to write a test for it to prove it was close enough to the one I wrote; further I didn't have much of a clue how to write such a test in any reasonable time.
The issue was solved by a 3rd person who committed my patch and then immediately discovered a 1 line alternative! The required behaviour had already been coded in a general form and a default struct parameter just needed setting.
As a whole the situation is hilarious, but as a participant it was very stressful and was clearly a big waste of time. The solution was reach by actions which were not those being argued for by either party.
There is a strong case that no patch is ideal, patches may reach our present mis-placed understanding of "ideal", an understanding which we dearly hope will be superseded in time with better understanding. We should not accept bad patches, but should we refuse an "OK" patch merely because we were enlightened the day before we received it instead of the day afterwards? In other words, is it THAT bad? Does the badness (which surely exists unseen in patches we like) overpower the benefit?
It may be constructive to put aside discussion of the ideal (as we each see it) and consider if there is any over-lap at all.
For instance how much compromise is Richard willing to make in order to make eLyXer more convenient to all users. The answer will not need any justification, and may even be "not a whole lot".
I believe that Alex is making compromises and multiple attempts to bring eLyXer to Lyx (because eLyXer is his project), but Richard seems to need Alex to reach even further. Can Alex reach as far as Richard needs - do we know how far that is, or do we only know that we are currently not far enough?
I suspect we are repeating what is happening all over the open source world, which is a "skunk works" of an open source project, [http://en.wikipedia.org/wiki/Skunkworks_project] - and this is doubly ironic because it this is how many open source projects began and therefore suggests that they such projects are becoming too bureaucratic to serve their users, and so new organisation springs up beneath them.
To illustrate further, Ubuntu is now more recognizing the requirement for "community supported software" - some of us thought that was what Open Source / Free Software largely was, but clearly there are different types of community. We have the alternate DAG and rpmfind.net rpm repositories to provide RPMs dropped us "unimportant" or badly maintained by major distributions.
In the context of this discussion what we may find is a Lyx+ package which more and more people will install on top of Lyx, that has it's own installer, and which eLyXer would be part of.
I've got my literate programming packages which avoid the need for noweave entirely, and which supports parameterized chunks:
http://repo.or.cz/w/newfangle.gitbut in light of discussion here I don't highly rate the effort I anticipate will be required to make it part of Lyx - because after all it scratches MY itch because Lyx roadmap does not co-incide with my own, and therefore it does not co-incide with the Lyx roadmap.
So the actual consideration with respect to eLyXer perhap should not compare the temporary "mess" that will be required to add eLyXer into Lyx as-it-is-now, but that as a strategy it may sustain a continual lack willing contributors offering improving features - and ironically the lack of willing developers to make the "ideal" changes to Lyx is the main objection to this change.
as an example:If Richard requires changes that Alex will not meet, then Lyx will suffer, not Alex and not Richard. If this sort of thing keeps happening (and I don't have any reason to suspect that it will) Lyx will suffer terminally at the hands of other projects, not just because of the features that are refused, but in the features that are not offered.
It is better to be "alive" than "perfect"; if alive, a thing can be perfected.
I consider that a local-file javascript controlled WYSIWYG html editor could be downgraded to a WYSIWYM editor; something that was not simply possible 15 years ago, and the xhtml could be transformed into Latex.
http://www.w3.org/2004/04/xhlt91/This reduces the problem of a LaTeX wysiwym editor largely to javascript problem, as the xslt part (my strength) has already been solved.
So I predict that if we do not work together, we will be overtaken by a bunch of web java-script-kiddies.
Of course the Lyx devs may not care about this - after all Lyx is their project - but thats the point, if Lyx is only their project and not also enough the Lyx users project, then Lyx users may instead take something which can be their project, and contribute to that instead of Lyx.
In fact, can you believe, someone was even working on converting LaTeX to XHTML using XSLT!
http://my.opera.com/White%20Lynx/blog/show.dml/240601 In fact, crazy crazy, have you seen the MathDox editor? http://www.activemath.org/workshops/MathUI/09/proc/Cuypers-Knoppers-Brouwer-MathdoxEditor-MathUI09.pdf Try online, http://www.mathdox.org/new-web/MathDoxEditor/index.php?include=matheditor and the formula editor? http://www.mathdox.org/new-web/MathDoxEditor/index.php?include=formulaeditor The revolution is already at our doors! Sam * Alex Fernandez wrote, On 15/09/09 07:49:
And, not entirely unexpectedly, a simple contribution becomes yet another flamefest... Well, let's get straight i0nto it. On Tue, Sep 15, 2009 at 3:57 AM, rgheck <rgh...@bobjweil.com> wrote:And why is that a good thing? Why does it matter, from LyX's point of view, how elyxer is distributed? Why should LyX adjust itself to the requirements of some downstream library? This is very much the opposite of how things are normally done. YOU (downstream) adjust to US (upstream), unless you have a very good reason to the contrary, and I do not see one. Which is why I was asking.I want to think that you are being deliberately obtuse, as opposed to spontaneously. Because this is an instance of ME (eLyXer) adjusting to YOU (LyX) and distributing my software in a different way to solve a problem in LyX. LyX needs a bit of glue code anyway to adapt to eLyXer. You want to minimize this glue, fine. I will try that with the next version. But this glue code would be restricted to Python code anyway.(I see even less of a reason to worry about this given the progress on native HTML output, which everyone who has considered the question and who knows anything about the matter knows is the only sensible option, long term.)Ha ha ha.It seems to me that there is a general failure here to understand something:[... blah blah blah ...]cannot or will not understand that. What's so unclear here? Problems integrating elyxer with Windosw$ are YOUR problems, not OUR problems.Way to help your users, Rich.File a bug with Micro$oft, then. Don't like the fact that they don't give a &()^&)( if you file a bug? Try using a real operating system. Micro$oft's problems are not LyX's problems. Period.I'm a Debian user myself, but thank you. I was just trying to solve a problem for the Windows integrator.Maybe this problem could be solved by using the Qt framework in a way we presently aren't. Qt hides a lot of our cross-platform problems. And if it doesn't, then you should look into some other issue in src/support/. That is where the issues about spaces in filenames should be handled, NOT in shipping some special library that is really needed only on Window$ and then hacking the LyX sources to deal with this platform-specific problem.The problem doesn't even come near Qt code -- it's all in the Python parts. Yes, reconfiguring and launching converters is done in Python. You might try one day to understand a problem before proposing solutions. It really makes a difference.Frankly, I find the entire attitude behind that suggestion to be just weird (which is the nice way of putting it). Does no one around here understand anything about FOSS and its principles?No, you are the only one that knows how it works: take a patch that is offered and reject it without knowing what it does and why. Ignore the necessities of your users. And be sure to try to scare any contributors away. I'm embarrassed that you are part of it.I do know about libraries, thank you. (Linux is kind of big on libraries.) In this case, however, so far as I can tell, the library makes absolutely no independent sense. It is a hack. The whole point of a library is that it's something that is shared, i.e., something whose functions might be called from lots of different sorts of programs. Which programs other than LyX and elyxer do you imagine will be calling this library?Let me see. Any Python programs that want to? Even if you know about the concept of a library, you fail to grasp its utility: package classes so that they are used elsewhere.As for end-user installation, this is a packaging issue. If it's a Window$ problem, talk to the Window$ packagers. Don't make those of use who use software whose bugs we can handle deal with THEIR issues.Well, that's what I did: listened to Windows packagers and try to come up with a solution.And yes, I would and have said say exactly the same thing about Mac OSX. The issues with LyX running on Snow Leopard (or whatever) illustrate precisely what's wrong with the closed-source development model, from our point of view.Once again you fail to grasp even the slightest thing related with the matters at hand. The issue with LyX on Mac OS X has nothing whatsoever to do with closed source development, but with how Mac OS X package installation works. It is well known and well documented, and it would work on Linux if anyone cared to adapt it. The clue train apparently left long ago.Yes, well, I wondered why you said anything, then, since you clearly aren't offering to help, and so are apparently just whinging. If LyX has fewer developers than are required to deal with all the enhancement requests that get made, let alone all the bugs that get reported, then, well, I seriously doubt that this is OUR problem. Pretty much every FOSS project is resource starved. Yes, I know that you previously offered to "help". But we are not going to let people who know nothing about LyX hack their way through the code to solve some pet problem of theirs. And that ain't gonna change.Very constructive, Richard. Don't let anyone come near your code to solve their pet problems. Let us forget about "scratch your itch" and all that bullshit: http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s02.html Only the Heck of a way to do something is allowed: reject the offered patch, and then propose the would-be contributor to help YOU in YOUR pet project. Exercise for the reader: figure out why LyX has few developers. I had fun with the discussion, but it is not really any nearer getting the missing bits integrated and I have other things to do (like tend to user reports), so I will have to decline to engage in any further conversation unless there is some constructive progress from either side. Alex.
