Re: [Axiom-developer] Re: typo in src/boot/Makefile.pamphlet

[Gabriel Dos Reis]

"Page, Bill" <address@hidden> writes:

| On Tuesday, April 04, 2006 10:56 PM Gabriel Dos Reis wrote:
| > ...
| > Somehow I understood that the "wider" public will see only
| > the two-month interval, while the developers could see
| > immediate patches (I'm mostly initerested in the other
| > changes that were suggested and applied, not in the "end"
| > thingy). Since the developers have write access, I believe
| > it would relieve the burden on you if they could check-in
| > patches, after public review and we have procedure for that
| > (we already have procedure for producing and testing patches).
| > 
| 
| Ah, now wouldn't it be wonderful if we actually had a group
| of Axiom developers who were willing and able to do what you
| suggest!

I've seen the group of people interested in "hacking" Axiom growing,
so I believe the group of "core" people can grow too, if the entry
barrier is not too high.

| As far as I know, in two years I am the only one
| besides Tim who has ever committed anything to the main
| branch and I haven't done that in over a year... :(
| 
| I think we need a theory to explain why what you suggest has
| not happened yet. Here are some possible explanations (in no
| particular order):
| 
| 1) the literate programming (pamphlet) format is more effort
|    that most people are willing to commit to the project.

Though pmaphlet format might not be the best on the planet, I do buy
the "literate programming" idea.  My experience with other projets is
that divergence between documentation and codes is one of the most
fertile and worst source of bugs and maintaince nightmarre.

| 2) Tim's manual, re-check-everything-twice is intimidating
|    to other developers -- nobody wants to commit their
|    "mistakes" to the archive.

I think the current centralization indeed has some weaknesses we can
improve on.  

If I can share my exprience with GCC, we have basically various level
of maintainers

   * maintainers with global write privilege:  these people have been
     hacking on the compiler for sufficient time that they have
     demonstrated a good understanding of the main structure.  They
     can modify any area of the compiler, though they will try hard
     not to overrule specialized maintainers.  

  * component maintainers:  these are people would have contributed
    components of the compiler (say front-end, middle-end, back-end,
    build machinery, targets) and know those areas very well.  They
    can commit patches to those areas without asking "permission".
    They "own" that area. A component maintainer when contributing to
    an area outside its "blessed kingdom" needs review and approval
    from the specialized component maintainers.

  * write after approval: these people are typically "new" or
    occasional contributors and have no special expertise or no
    immediate interest in endorsing component maintainership.


Interestingly, we may not that the old gcc project "died" precisely
because there was only one person who could commit and make the
release.  The EGCS experience (which later was renamed GCC) was
successful precisely because the maintainership was distributed and
vitality was prominent in the sense that applied patches were
instantly available -- many people work incrementally, so they want to
submit something first and improve on it in successive passes; that
work only when there it no too long delay between reviews and actual
availability of patches.

| 3) Setting up and using arch with sftp write access is too
|    complex. It's easier to just let Tim do it.

Somewhere, we need someone who keeps track of the permission,
copyright and all that stuff.  I believe Tim is doing an excellent job
there.  However, I also believe we need a less intimidating set up
proceudre and version control system (yes, that is a taboo subject,
but we do need to do something about it).

| 4) There are not enough people who have sufficiently deep
|    experience with the Axiom source code and those that do
|    are already too busy doing other things.

this usually comes with time, provided that the entry barrier is not
too high.  At least, that is what I have observed for GCC over a
decade.  GCC is really complex and intimidating. 
It is amazing to see how people come in, first intimidated by
the very complex structure of GCC, and gradually builds understanding
and expertise.  Key factors for that, I believe, are:

   * instant availability of patches applied to mainline

   * public informative review that helps gain understanding of why
     things are the way they are, possible improvements, and things
     that should not be tried.  That is very essential to attain
     critical mass of people understanding the system.

     I've learnt a lot about Axiom through discussions between you,
     Tim and others. I think that should happen more often, on patches
     -- not just in abstract ;-)

| 5) The centralized source code repository model sucks. The
|    current multiple-branch approach in the Axiom archive is
|    not being used effectively. People are still unwilling to
|    take responsibility for maintain a particular centrally
|    accessible branch.

I'm not sure.  The current centralized source code repository is
good.  What we need is more vitality in the source code.  Two months
without seeing any changes in the trunk source sounds like a death.
We need to show that the trunk is alive.  The more you show activity,
the more likely you'll attract people.  The easier you make it for
people to change codes, submit patches and get them 
review, the more you attract people.

| I think we need cures for some (or all) of these potential
| problems before Axiom development can approach anything like
| the development model for gcc.

I do not expect perfect match with GCC model (there are many aspects
of it I do not like but that is a different debate), but I think we
can address those problems today without too much of pain, provided
we're willing to lower the entry barrier.  For example, I hope to
succeed in attracting students to Axiom, but that would succeed only
if they are not intimidated. 

My two cents.

-- Gaby