Re: [Axiom-developer] Problem building SIlver Axiom on Gentoo Linux

[Gabriel Dos Reis]

root <address@hidden> writes:

| > However, the only meaningful way people can productively "play" with
| > th silver branch is when it is not far from the gold. 
| 
| I have several systems that are very, very far from Gold.
| They include interpreter rewrites, algebra rewrites, browser
| rewrites, etc. The only way to make progress is to move away
| from Gold, mangle functionality, prove it, merge it, test it,
| and then promote it. This takes months.

Yes, but I was specifically talking of this

   #  patched. fixed in the next release. --t

Whatever that "next release" is, I strongly believe that that patch
ought to be in silver too -- because it is fixing a problem that is also
present in silver.  

If you can't apply the patches because of system packages issues,
please just send it to the list. 

| My impression was that SVN was going to be a place where people could
| clone Silver and do their own subsystem, say to explore ideas like
| working with Sage or a complete rewrite using ALLPROSE..

That is correct.  However, it would be a good use if they don't have
to clone all the problems that are known to be already fixed...

| I don't have
| the time to look at the Sage idea but someone could do this in SVN and
| let people play with it. Once it works the way people like then the
| effort to merge it into Silver and promote it to Gold can start.

That is a very good thing to do, indeed.

| >                                                        Nobody would
| > want to waste its time on a system that is *for sure* very remote from
| > the gold.  
| 
| We had a very long email thread about update rates to Axiom.
| The issue was striking a balance between "immediate fixes" and
| "reasonable workload". After much discussion we agreed that a
| new copy of the system would be released approximately once every
| 2 months. This is not immediate (notice that Gold has not changed
| since April, despite fixes being applied). This is not slanted
| toward a reasonable workload (6 months).

I don't propose we change that "regular best effort".  The only thing
that I'm suggesting is that, when we have a problem in both Gold and
Silver and you have a fix for it (against Gold), just send the patch
to the list.

| So patches get collected and the Gold copy is built/tested/ported
| every 2 months or so. I missed the goal this past month due to
| preparation for ISSAC and now, due to updates caused by ISSAC.

that is quite reasonable: you are doing too many things and I don't
know where you find the time to handle all that :-)

| Gold gets released every couple months. Silver can do a simple
|   diff -r --brief Gold Silver
| to see exact changes.

That would not be workable because:
  (1) silver contains the "immediate" fix;
  (2) not everything in Silver will end up in Gold;
  (3) the diff between Gold and Silver after two months, in general is
      not just what Gold added.

| Given the rate of change it isn't possible for Silver to drift
| far from Gold.
| 
| 
| On the other hand, Silver can do immediate patches if someone is
| willing to do them. My objection to immediate patches in Gold is
| that it takes me several days to "release" a Gold system (due to
| testing and porting). I don't want to release a broken system.

I believe everybody agrees on Gold being very very stable.  The
description of Silver (and my understanding of it) is that it contains
immediate fixes (though it must be stable), and only when the fixes
mature enough and uncrontroversial, they can move to Gold.
One of the reasons I volunteered to maintain Silver is precisely to
help share the workload.

| If I took on the responsibility of doing immediate patches to 
| Silver that would completely negate the whole "update rate"
| balance discussion.

In that case, just send your patches against Gold (i.e. when you say
"fixed in next release").

| You can't just throw a patch at a system.
| You have to check it. That takes time even for simple patches.

All that is understood.

| For instance, I have a simple fix to the Makefiles for libXpm
| that makes the system compile correctly on FC5. However, it
| breaks Redhat systems. So if I just applied the patch to Silver
| without testing some of the users would have broken code.

I understood that.  Nobody suggested you apply the patches to Silver
without testing.

| ; We all agree that we don't have enough resource; the last
| > thing we want to do is to waste the scarse resources in many wasteful
| > forks. 
| 
| Resource is exactly the point of the "reasonable update rate" issue.
| There are things that only I can do and these are things that I should
| spend time doing. There are things that others can do (like apply
| patches to Silver) and these are things that I should not be doing.

We can test and apply the patches if we *have* them.  Please, just
send your version against Gold.

-- Gaby