axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] Re: Version numbers


From: Gabriel Dos Reis
Subject: [Axiom-developer] Re: Version numbers
Date: Mon, 25 Jun 2007 05:05:33 -0500 (CDT)

On Mon, 25 Jun 2007, Bill Page wrote:

[...]

| To other people reading this thread, if this disagreement is of no
| interest to you and seems off topic, then I apologize for wasting your
| inbox space and suggest that you hit the delete key now. But if you
| have enough patience, please do continue reading. 

I do not believe your posting was a waste -- although a patch to
Axiom with equialvent size would have been nice :-) :-)

More seriously, it looks like several people are "suffering" in silence.
Since, obviously, I'm part of the concerns I believe I must straight
out some points and voice some of my own concerns.

This email and the situation reminds me of the pre-EGCS stage of gcc, before
the fork was done: too much resources were spent discussing politics, not
actual technical work, and the weight of just one person ruling everything.
In the end, EGCS forked from gcc, got successful, and later reunited with
original gcc under several conditions, the most important being that the
project is collaborative, and technical decisions are made collectively by GCC
developers. 

I do not suggest Axiom to take a fork route -- it is not something I like,
but I cannot recommend people ignore that possibility.  Again, I'm not
suggesting a fork.

| [...] I think open source
| projects are a lot different than traditional computer software
| projects because in many cases *all* of the effort and the resources
| available are *volunteer*. This means among other things that it is
| not possible simply to pay someone a salary as compensation for
| "putting up with" the difficulties of working together with other
| people. Instead we must be prepared to devote at least some of our
| time trying to making sure that everyone involved feels like they are
| being treated fairly.

Yes, open source development is very different from what can been seen in some
commercial companies or a long time ago.

[...]

| In his email Tim pointed out to me that every decision he has made
| regarding Axiom was with the explicit goal of improving Axiom and that
| he had put both massive amounts of time and an ongoing sizable amount
| of money into building up Axiom, raising the quality, and promoting
| its use. I do in fact realize this is the case and have previously
| pointed out Tim's large personal contributions to other people both
| privately and on these email lists.

I acknowledge that. Furthermore, I believe that can be said of any
Axiom contributor on this list I know of, although the resources
vary in nature.

Personally, I've risked more resources into Axiom than advisable since I've
started.  It remains unclear to me at this moment whether I should continue
or just go on with my own project.  Part of this is due to resources being
spent talking more about politics than technical work.  Part of this is due to
unfocused view.  I'm not blaming anyone.

[...]

| I think Ralf and Tim are right and that I should probably call this
| new Axiom for Windows installer by a name something like:
| 
|  axiom-windows-wh-rev613.exe

I agree.

| > > Martin Rubey wrote:
| > > > I was hoping that trunk would be usable (i.e., very close to wh-sandbox)
| > > > soon, ...
| 
| Tim points out that in fact he has committed to number of changes to
| Silver that originated from build-improvements (labeled "gdr" in the
| Silver change log) and wh-sandbox (labeled "wxh" in the Silver change
| log). He admits that not everything has been merged because: 1) he has
| had to read the code from build-improvements and wh-sandbox to create
| the diff-Naur from Gold himself because no one else made any effort to
| merge changes back to gold. Further, that some changes were not
| included because either: 2) they were unstable or 3)  because he did
| not understand them.

Yes, Tim had hand cherry picked changes to both build-improvements and
wh-sandbox.  That is both good and painful.  That is good because some
changes found their way into silver, where they are supposed to
eventual end up.  It is painful for some of us because it was carefully done
so that both automated revision trackers and ChangeLog entries are
worked around, avoided.  Therefore it requires more effort to figure out
what is done than if no merge was done in the first place.  I'm not
here to blame.

>From your mail, I've sensed that some people on this list would be
thinking that I want to promote my product and contribute nothing back.  That
would be pure nonsense, because it goes against the *facts*.

Notice that I took responsability in syncing silver with Tim's private 
branches that contained the merges [in preparation of future merge from
build-improvements to silver].  I've attempted to merge some
changes to silver but I backed off when some vocal people complained.
More on this below.

| I think that what Tim says is true but I believe that Martin is
| concerned about higher level functionality like the fixes to Hyperdoc
| and the ability to compile his "guess" package. Personally I find that
| both build-improvements and wh-sandbox are much more stable than Gold
| and that they build on more platforms, so they seem like a natural
| choice for Martin.

That is perfectly sensible to me.  For everybody, except a few tiny
minority, wh-sandbox as it stands is a natural choice.  The reason is simply
because most people will be users and they are interested in high level
functionalities and less bugs.  People concerned with possible competition
between silver and wh-sandbox should be working together with both wh-sandbox
and silver maintainers to move forward.

| I am not sure why Tim does not understand the changes that where made
| in these branches. Most (all?) of the changes made by Gaby and Waldek
| were announced on axiom-developer email list and the detailed patches
| are sent to axiom-commit. I think that if anyone has questions about
| the changes it would be best to ask the authors via the
| axiom-developer list.

All the changes made to the SVN repository can be retrieved or viewed as
patches.  The mails sent to axiom-commit are just informative, and sometimes
they are truncated because of size limit.  However, they do indeed
contain most information.  I would expect that anyone who has looked
at build-improvements who does not understand a specific part would ask
his specific questions that I'd try to address. Just saying "I don't
understand the autoconf change" is not specific enough, sorry.
Although the documentation is not perfect, I've tried to explain what is going
on so that others can make changes.  I know of at least two Axiom
contributors who have changed the Autoconf-based build machinery -- I'm not
claiming that is a proof that it is good enough for all purposes.

| > > Martin Rubey wrote:
| > > > but that doesn't seem to be happening.
| >
| 
| As an explanation of why this is not happening Tim said that we should
| consider the two ways that people generally contribute changes to open
| source projects. The first is to create a branch, make a series of
| modifications, merge those modifications into a local copy, test those
| changes, package up the changes into a changeset, and post those
| diff-Naur changes against the trunk. He says that his is the way it is
| done in linux, gcc, apache and SBCL. For example:
| 
http://sourceforge.net/mailarchive/message.php?msg_name=75cb50350706181211g1740af8dg155a401
| 
| The second method is to create a fork: take the main body of code and
| make your own competing branch, marketing it with new features. You do
| not make an effort to contribute your code back to the trunk. You
| simply "walk off" with the collective effort and promote your own
| private version.
| 
| I would prefer the first method but as I said in my previous email, I
| am afraid that we are closed to the second method right now.

In fact, I have a different opinion:
  (1) the above dichotomy is overly simplifying.
  (2) I don't believe anyone is taking the second approach, at least, I know
      I'm not taking the second approach.

| Although it is true that they are not *exactly* diff-Naur patches, all
| of the posts to axiom-commit are in fact diffs against the original
| trunk of SVN at SourceForge which corresponded to patch-50 which is
| what "Silver" used to be. I there must be at least 500 of these emails
| in the axiom-commit archive. It seems to me  that both Gaby and Waldek
| originally believed that Tim (or anyone else motivated to update Gold
| and Silver would use these diffs.

I strongly believe that the requirement of manually applying someone else
patch which is already present in the repository is curious and
backward.  The task can be automated with far less risk of errors
by using the tools we already have:  I've merges trunk to build-improvements,
build-improvements to gdr-sandbox, gdr-sandbox to build-improvements,
build-improvements to silver, daly to silver with one single command.
Furthermore, I have the assistance of the source version system to undo any
changes at anytime without errors.  People who take the merge from the active
branches to trunk/silver seriously should give serious thought to
automated merges.  That said, however, there must be a requirement
of sending patched to the list for consideration.
As a matter of fact, I did propose such policy a year and half ago.

| Tim explains why there has been no conversion of Gold to using
| autoconf by pointing out that there is no diff-Naur, there is no
| documentation, there is no effort to promote any changes back to the
| main line of code by anyone else.

If that is Tim's explanation, then that explanation can be safely ignored as a
non-explanation. To my view, it is closer to fantasm than anything else.

On this list, I've stated several times that when build-improvements
is ready for merge to silver, I'll announce it and request review.
It came as a surprise to me when I realized that Tim had privately
hand cherry picked changes from both build-improvements and wh-sandbox.
While, the documentation is not perfect, it is untrue that there is
no documentation.  And I would expect that if Tim does not understand a
specific part of the changes I made, he would ask a specific question.

In fact, when I started working on the Axiom source code, I was asking
many questions about parts of the code not documented that I did not
understand.  I stopped because I had the sense that most of the answers I got
were not useful to me.  I don't think we have reached that point with
build-improvements yet :-)

[...]

| Since I have been promoting the autoconf style of build process for
| Axiom to Tim for several years, Tim asked me why I did not do this
| work myself. I replied that I was very glad when someone came along
| (Gaby) who was motivated and obviously knew enough about how to do it
| - much more than me! The situation is that really I do not want to be
| doing this kind of development. Since I am not very good at it, it
| wastes my time and there is never enough time. I would very much
| prefer to be an Axiom user/developer who discusses mathematics and
| writes new algebra code for example in category theory and in
| applications to physics. But here I have been stuck for nearly 5 years
| now - just getting to the point where this is becoming possible.


I very much disagree with that view. I too would very much perfer to be
an Axiom user/developer who discusses mathematics and write algebra code for
example in category theory and applications to various fields of 
computational science.  However, I also realize that I cannot just wish
someone else come and does the dirty job for me so that I can theorize without 
getting my hands dirt.  I'm not a developer.  I'm a mathematician.
I earned my degree in Differential Geometry.  I'm highly interested
in computational mathematics.  Since *I need tools* and they are lacking, I
have to build them.  That is why I have my hands dirt with C++, GCC, Axiom,
etc. 

[...]

| > > Bill Page wrote:
| > > > It seems the contrary to stated intentions, the update of the Gold and
| > > > Silver versions of Axiom effectively remains under the control of only
| > > > one person -- Tim.
| >
| 
| Tim says that this is a "lie" and referred me to his email:
| 
| http://lists.gnu.org/archive/html/axiom-developer/2006-11/msg00282.html
| 
| He says that history shows that no one stepped up to build a new
| version of Axiom and no one committed any changes to Axiom over the
| period of 3 months from November to January even though everyone
| (inculding me) had write access. During that time Gaby and Waldek
| continued working on their own branches.

If that is the explanation, then I believe Tim is oversimplifying
the actual facts and that *helps nobody*.

[...]

| > > Bill Page wrote:
| > > > Tim remains the primary bottleneck for getting these changes done.
| > ...
| > > > Perhaps this is not his intention however I think his approach of using
| > > > a separate repostory (based on git) and insisting on doing all updates
| > > > via manual patches, effectively discourages other developers from
| > > > contributing directly to Gold or Silver versions.
| >
| 
| What Tim wrote in reply seemed to indicate that he was angry that I
| should make this sort of claim. He said that it was equivalent to
| claiming that he personally should decode how autoconf works,  how the
| new boot is supposed to work, and how the ansi version is supposed to
| be merged. Tim repeated that no one besides him makes any effort to
| ensure that the main trunk is updated.

That is untrue, and I'm disappointed that Tim is reported to make that claim. 

My personal view on this matter is that many people here don't seem to
appreciate the notion of approximation and incremental improvements.  I seem
to be living in the imperfect world of practical needs and I have the sense of
talking with people who lives in perfect world.  I have ideals but I also 
know that I can only approximate them, and incrementally tend to that ideal
limits.

The build-improvements and wh-sandbox are the results of approximations and
incremental improvements.  People who would like to discuss them are invited
to reflect on the notion of approximation and incremental improvements.

| So I explained that what I meant was that I thought his (Tim's)
| actions have discouraged other people who potentially could contribute
| to Axiom Gold in parallel with Tim. I pointed out that he has not
| convinced anyone else to "play by your rules" and he has not
| compromised enough to allow them to change their own approach to be
| compatible with his. So, the consequence is that Tim is still the only
| one doing it. I easily be wrong about other people's motivations here,
| but I do not think that this is a "lie".

I've said it many times and I'll repeat it again: having many "main"
repositories is a good recipe for confusion.  That does not mean we should not
have mirrors -- we just need one main repository.

| In fact I doubt that anyone besides Tim feels confident enough to do
| update trunk. The manual process that Tim has described for how he
| does it is very unlike the process used by anyone else that I know.

In fact, I can update trunk (and I have done so many times), but:
  (1) between the period where Tim semi-retired, I deliberately did
      nothing to silver/trunk because last messages from Tim on the matter
      was clearly based on mis-communication and I would surely not going
      to do anything that would be construed as evidence to the
      misinterpretation.  And I was glad it came back.

  (2) I've recently updated trunk so that I can continue work on my
      (windows) machine and contribute code.  But some vocal people
      have complained and I backed out my changes.  I based my decision
      to back off the basis that if people have such strong opinions
      and are so vocal about modifying trunk then they surely have
      the resources to do the work I was trying to do.  

      No, Tim did not ask me to back off, but he did not say "no" either
      when I offered to back off.  He has plans for a giga patch that would
      solve everything so I've rather waited.  

[...]

| > > > Bill Page wrote:
| > > > (See for example recent revisions submitted by Gaby which he asked
| > > > to revert pending something similar to be done by Tim.)
| >
| 
| I think Tim's reply to this is very important.
| 
| He said that he had planned to work with the change that Gaby had
| submitted and the
| fact that Gaby later withdrew it was *not* based on his request.

That is true: Tim never asked me to back off the change I made.
The complain came from more vocal people who did not take any step in 
solving the problem I was attempting to solve.  I guess solving the problem
they thought I erroneously solved would have been against the law.

| (Check the mailing list). He said that I should get your facts
| straight when you are making disparaging remarks about him in public.

Is "you" referring to me (Gaby)?

| I am very sorry about this. I do hereby state publicly that I was
| wrong about that. I also get the impression that there were more
| people than me who may have gotten the wrong impression about that
| interchange so I am glad that Tim has set the record straight.

Again, Tim never asked me to back off.  I first offered the reversion, but got
no answer.  and since some people felt strongly about it, I reverted
to the state the branch was.  I suspended any work on silver until 
the problem I was trying to solved get solved by people with more
resources than me and those people who have strong opinion about how it should
be solved.  It does not mean I'm not going to contribute anything
back to silver.

| > > Martin Ruber wrote:
| > > > I have the feeling that "trunk" and "branches" is somewhat unfitting
| > > > for the Axiom project. Currently, wh-sandbox seems most useable to me.
| >
| > Bill Page wrote:
| > > Although no one has named it as such, I think effectively we have the
| > > situation of a "fork" in the Axiom sources.
| 
| Tim pointed out to me that he has previously written to the email list
| about this. He says that when one joins an open source project and
| wants to "contribute" then it it is your responsibility to make sure
| that your work gets merged into the main line (first Method above).

Obviously that remark is addressed to Waldek and me.  If Tim believes
that none of us is willing to contribute changes back, then I believe Tim is
seriously wrong about us.  I would not ask for a public apology, but I would
like to invite him to refrain from such statements in the future.

| But no one has done this. And we now see 3 different things being
| called "axiom"... Gold, build-Improvements and wh-sandbox. He says
| this is a "fork" because there is no acknowledgment that this work
| should go back into the main line.

That is simply contrary to any facts that can be found about both
build-improvements and wh-sandbox.  I've stated repeatedly 
that I would like build-improvements to eventually get merged to
silver.  Waldek has even outlined components that would be merged
to build-improvements branch, and later up to silver.  Statements
like the above are just plain gratuitous injustified insults to people 
with interest in contributing to the whole Axiom project.  I don't see how
that is a help. :-(

-- Gaby




reply via email to

[Prev in Thread] Current Thread [Next in Thread]