[EMAIL PROTECTED] writes:

| > Well, patches are supposed to be posted when they are ready for
| > "prime time" use. For "personal" experimentation we don't require
| > that (should we?)
| 
| Well, clearly "personal" experimentation is a non-issue.
| 
| I'm not claiming that anyone has an obligation to share their
| local changes. Indeed, the license does not require this either.
| However, working together on a common project tends to imply sharing.
| But real sharing involves work to "get it off your desk" and into
| the common distribution.

This is true in general, including your changes to Gold we don't see
until the Big Day.  I'm trying to single you out.  We all have local
experimental trees that would do more harms if published than kept local.

[...]

| Challenge 1: SIMPLE CHANGES, such as removing the C prototype
|   code is clear, tedious, harmless, and requires no explanation.
|   I've already picked up these changes and made sure they happen
|   in every file.

Those changes are clearly beneficial in isolation.  Please note also
that because Gold and Silver have gone, until very recently, into very
uncertain status, it was hard to do anything useful.  Changes should
first go into Silver before being picked up and lifted to Gold.  We,
at least me, don't know which branch is Silver and what is its
status.  I don't know which is going to be Gold and its day-to-day
status, i.e. preview of what is to be Gold.  Under those
circumstances, it is hard to do anything useful to Silver and Gold.


| Challenge 2: LESS OBVIOUS CHANGES, such as eliding "member" from
|   the boot code. This change was made with no documentation added
|   to the source code making it impossible to (a) guess why and
|   (b) test. Furthermore, there are no test cases so even if I
|   understood it I'd have to develop the test cases again (assuming
|   you had them in the first place) from scratch.

I don't remember any patch eliding "member" from the Boot code.

[...]

| > The axiom-commit mailing list has the history of all commits
| > to SVN -- when they are not truncated due to SF policy
| 
| The axiom-commit mailing list posts are essentially worthless as a
| Gold-merge resource. I can reclaim the same information in more detail
| by doing 
|    diff -r --brief build-improvements gold

Those changes that would go into Gold, are ideally, diffs between
Silver and Gold.  However, I no longer know what is Silver and what is
Gold. 

| What's missing is the (a) changesets (b) documentation (c) tests
| 
| The "changeset" mentality is that all of the changes necessary to
| produce a final single effect are packaged in a single set of patches.

The "changeset" mentality must make room for incremental improvements;
that is a necessity when you don't have the power (e.g. resources) to
make change in one shot in a timely manner and remain useful.  Users
are more tolerant of incremental improvements than may be assumed.

[...]

| Since I'm in the midst of reverse-engineering the build-improvements
| and wh-sandbox branches it would be a good time to consider packaging
| up changesets for functionality you consider complete and ready. I know
| it takes you away from "interesting" axiom tasks. The whole build process
| has already cost me several weeks so I understand.

It is not a matter of taking me away from "interesting" axiom tasks than
asking me to allocate time today or this week when I have none to
solve the fuzzily defined problem.  I was travelling last week
attending (important) ISO C++ meetings, which made me fall behind
class schedules which I need to catch on this week, plus the usual
deadlines that come hard when time is short.


I need the following:
  (a) a clear mark of what is Silver, what is Gold
  (b) I would like to be able to propose diff between Silver and Gold
      for inclusion in Gold
  (c) I would like to have patches applied directly to Silver,
      assumming the general community is interested.  I.e. I would like
      to see more testing of "gold preview".

Can we work that out?

-- Gaby


_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer

Reply via email to