[Top][All Lists]
[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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Axiom-developer] Proposal for a new development model,
Martin Rubey <=