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
address@hidden
http://lists.nongnu.org/mailman/listinfo/axiom-developer