Now that we've had a full, frank, and open debate about William Sit's proposal I have a counter-proposition. It can be summed up in a single word:
Contribute. A contribution to an open source project is one in which a developer submits a diff-Naur patch that fixes a bug or adds a feature. The diff-Naur patch is against either the shipping version or the upcoming version. It's not a novel concept. It is used by hundreds of projects. Posted today is a 40kb patch to SBCL for ANSI-compatible modern casing (similar to the axiom downcase). Posted today are diff-Naur changes to GNU binutils. These are changes in my email stream inbox. They contain diff-Naur changesets by people who contribute to the projects. People who did the hard work of tracking a bug and developing a fix or the tedious work of changing a global feature in hundreds of files. Waldek, of course you support William's proposal. It implies that you have no work to do and that I have to refit all of my changes into your code base. Pretty sweet deal. Do you really find it beyond your powers to decode the changes you made to fix hyperdoc? Did you document the way hyperdoc works so we can all understand? Is the changeset way too subtle? Or just a lot of hard, tedious work that might slow you down? It took the bettter part of the last 6 months teasing out clean, single-issue diff-Naur changesets of the "Waldek" branch and contributing them to silver. I know it is time-consuming and slow. But your "contributions" were made despite a glaring lack of effort on your part to contribute. Waldek, your work is very valuable and we pay close attention to it. It is likely that you are well-intentioned and are not trying to co-opt the rest of the project. You can contribute if you would only take the time. It would improve the trunk considerably. Gaby, it is highly annoying that you continue to spout sarcasm about "your view" of the project. To quote you today: >>(BillPage) So, please don't downcase all file names >(Gaby) You understand the value of incremental improvements. > I wish we were more in sharing that view. (Please don't say I don't understand what you wrote.) Yet you made a valuable, massive, monolithic change to the build system. At no time did you try to incrementally improve the trunk by submitting diff-Naur patches. Now you have the problem of creating an autoconf changeset that will make the purely syntactic downcase changeset look puny. If you really believed in that philosophy we would have seen a stream of diff-Naur patches from you against the trunk. But there has been no "incremental" stream of changsets. We know that making these changesets is time-consuming and slow. It took the better part of the last 6 months teasing out diff-Naur patches of the "BI" branch and contributiong them to silver. Thus your "contributions" were made despite a glaring lack of effort on your part to contribute. Gaby, your work is very valuable and we pay close attention to it. It is likely that you are well-intentioned and are not trying to co-opt the rest of the project. You can contribute if you would only take the time. It would improve the trunk considerably. Bill Page, your comments about downcasing files is very poorly founded. A mono-cased Axiom would eliminate the port issue to Windows (something dear to your heart, according to you). It would also establish the beginnings of a system-wide standard of using monocase everywhere. Thus code can reliably down-case a string and expect that they get the right filesystem names. Do you find that global downcasing will cause a disruptive impact on your code contributions? It hardly seems so. You claim to only want to spend your time on new algebra (wouldn't we all?). The downcase issue will have little impact on your new algebra. But it will make future Windows ports easier. It is time consuming and slow to figure out how to build Axiom on Windows. But you're the primary Windows person on the project. It would be nice if you did more than just point at some repository that contains a "windows port" and tried to figure out how to diff-Naur the changes as a contribution. It would also be nice if you didn't criticize changesets that don't impact you. William, "contributing" to a project also implies supporting stated project goals. You write > Let's forget about documentation for the moment because documentation > slows development effort. Yet one of the PRIMARY Axiom goals is documentation. Every file is literate. Sure it is time-consuming and slow. I know because I have been doing literate documentation. You write: > I know you are worried about correctness, but we can develop a plan > to verify correctness by co-opting resources from the mailing list > and parceling out specific tests to individuals. Your regression > tests can still be run after each major build. Umm, no. It takes a lot of time to construct those regression tests. Try it sometime. Where is the regression test suite for your code? If you won't write it then who can you "co-opt" from the mailing list to write it? Who best understands your algebra code? You write: > So if it is not too difficult, merging your changes into wh-sandbox > would be the fastest way to a new release that "just works" Oh, really? So it "just works" as in: <http://wiki.axiom-developer.org/366Gcl267CrashesBuildingWhSandbox/diff> from today's mailbox. wh-sandbox crashes in build. We're not talking about "just works" here. You write: > The lack of documentation is not a big problem because it would be a > waste to document code that is not final. You mean, like documenting the fast changing partial differential code you wrote 20 years ago? Is documenting that code a waste of time? You already have the technical papers written. Is it that hard to adapt them to produce even minimal documentation? All of these remarks are stinging and pointed. So were the remarks directed at me. Raise your eyes. Look toward cooperating by contributing your time and energy to goals that go beyond the personal. Spend SOME of your time on documenting/merging/testing your work. We need to start working like SBCL, like GNU binutils, like Linux, like every other project. There are no quick fixes. It is all hard work. We need to change the "best-branch-wins" attitude so we can work together to build a great system. So we've entertained the "Sit Proposal". Now it is time to entertain the "Daly Proposal". We don't need a web page to vote. Here's how to submit your vote.... Figure out a needed feature (e.g. Hyperdoc fix), make a diff-Naur changeset, document, test, and post it. Contribute. Tim _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
