axiom-developer
[Top][All Lists]
Advanced

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

[Axiom-developer] Proposal for a new development model


From: Martin Rubey
Subject: [Axiom-developer] Proposal for a new development model
Date: 14 Jul 2007 22:11:09 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

Dear all,

below you find a first draft of a new development model I would like to propose
for axiom.  It does break with some of the current rules, but I still hope it
will be approved.  The most crucial shift is to a more democratic view, that
splits branches into two classes, according to whether decisions are taken by
the community as a whole or by the maintainer only.  In this model, there are
two special "branches", namely "Gold" and "Silver", which are both community
driven -- but possibly maintained by a single person.

I would like to emphasise that I do value branches a lot.  I think it is great
to have the axisp branch and wh-sandbox, especially because they probably
represent rather different views on how things should be done.  Accordingly, in
the model I propose, at one point in time, "trunk" can follow mostly one view,
at some later point, if it proves useful, another view.

Since decisions are taken by the community and having several branches around
is encouraged, I hope that this model minimises bad emotions and will not leave
anybody badly hurt when for some reason "her favourite code" is taken out of
trunk and replaced by somebody else's code.

I will also put this proposal on MathAction, SandboxDevelopmentModel, so that
everybody can easily comment on it, and also vote (using a comment).

Before you approve or disapprove, please try to envision how you will feel if
your favourite patch does not make it into trunk, because there is a vote
against it, and how you will feel if some large change takes place in trunk you
are not happy with.  Furthermore, will you be able to vote, independently and
without being afraid of other peoples reactions?

As I learned in the last two weeks, but also within the project together with
Ralf, emotions play a very important role, and although dictatorship has its
merits in software development, it is time to evolve.

To make my intentions clear: I will definitively stay in the axiom community,
if "silver" will be "community driven" in future.  That's the crucial point for
me, and this point is most elaborated in the model below.  Feedback is welcome.

I sincerely hope,

Martin

-------------------------------------------------------------------------------

Axiom is a free computer algebra system, developed by a community of computer
scientists, mathematicians, physicists and other interested people.  On this
page we describe the development model we adhere to, in order to enable
cooperation and minimise the danger of arguments and bad emotions.

goals:

  * documentation using the ideas of literate programming.
  
  * correctness has highest priority, but usability is important.

  * attract mathematicians and computer scientists.


setting:

  * for some of us, axiom is a hobby, for others part of their work

  * the axiom community consists of all people subscribed to axiom-developer

  * the axiom foundation is a board of three members, appointed for one year


Axiom is developed in many branches, by many individuals.  We can think of two
different models for branches:

  * "community driven branches"

    although possibly maintained by a single person, decisions concerning such
    branches are taken by the community as a whole.  Patches should first be
    sent to axiom-developer.  They can be applied if nobody disagrees within a
    reasonable period of time.  If there is disagreement on whether a
    particular patch should be applied or not - especially concerning "large"
    patches, a vote among the axiom community decides.  Although everybody in
    the community can vote, we urge people to vote only on subjects they feel
    that they understand well.  In any case, care should be taken to reach
    consensus.  In some cases it may be more useful to start another branch
    that is kept in sync.  "Community driven branches" should be regularly
    synchronised with "silver".

  * "privately driven branches"

    decisions concerning such branches are taken by the maintainer.  However,
    the maintainer is encouraged to regularly synchronise with "silver".


There are two special branches that are "community driven", namely "Silver" and
"Gold":

  * "Silver" (also known as "trunk" in the subversion repository) is the stable
    branch.  Patches are eligible only if they do not break usability of axiom.

    For this branch, we strongly encourage developers to document their
    findings.  However, if a patch greatly improves the usability of axiom, it
    may still be eligible, in the hope that documentation will follow.  In
    certain cases, it may be unknown why a modification of the source fixes a
    bug.  Then, an appropriate notice should be added to the documentation.

  * "Gold" contains the latest release of axiom.  Any member of the axiom
    community may suggest on axiom-developer that "Silver" is released, i.e.,
    becomes "Gold" after a short freezing period.  It may prove useful to
    create a release branch.  The person that suggested the release is also
    responsible for picking a release number, and the creation of tarballs,
    debian packages, etc. of this particular release.  Of course, it may
    delegate the work involved.


tools:

in general, we try to accommodate different work flows if possible.  To allow
cooperation, however, we insist on the following tools:

  * for "community driven branches" we use a subversion repository

  * the documentation is written in LaTeX, using noweb or a compatible tool.
    It should not be necessary to use a special editor to modify documentation
    and sources.

  * to track issues and patches, we use the IssueTracker.  We urge contributors
    to send patches that adress a particular issue not only to axiom-developer,
    but also to IssueTracker.





reply via email to

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