axiom-developer
[Top][All Lists]
Advanced

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

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


From: Gabriel Dos Reis
Subject: Re: [Axiom-developer] Re: typo in src/boot/Makefile.pamphlet
Date: 06 Apr 2006 10:27:55 +0200

Ralf Hemmecke <address@hidden> writes:

| Hi Gaby,
| 
| I am happy that you raised that problem.
| 
| On 04/05/2006 06:30 AM, Gabriel Dos Reis wrote:
| 
| > and expertise.  Key factors for that, I believe, are:
| >    * instant availability of patches applied to mainline
| 
| Well, it should be very simple that any patch that is sent to Tim is
| immediately applied to a branch axiom--main-unstable--1
| That would be the hottest branch and always up-to date.
| The axiom--main--1 branch would be the stable line. Code can only
| enter there if it has survived public review on the unstable branch.

I agree. Well, almost.  Almost because I do not believe *every* patch
should be applied to the branch.  I believe patches that survive
public review should be immediately applied.  It is good to have
unstable branch where experiments are conducted, but I think we need
one branch that is unstable but not too unstable.

| In fact, we could have (and actually we have) several unstable
| branches already. There are already different people responsible for
| them and a policy of how to update things there is completely
| open. But you are right. It would be nice to have the "hottest" branch
| available.

I'm willing to take responsability for that, but I need general
agreement from the community (especially from Tim) for having that
sort branch with the intent that patches applied there will move to
the stable branch when they have survived enough testing and satisfy
The Master (Tim!) taste.

| I think that flexibility of tla is a bit too much. There are simple
| guidelines missing of how to do things efficiently without the need to
| read several hundred pages. (I am trying to learn already since I
| would like to contribute code.)

Can we move to SVN? (yes, it is a taboo subject but...)

| >    * 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.
| 
| Since I have no idea about how this works, could you be a bit more specific?

Well, in general a victim sends a patch for review.  Component
maintainers and/or maintainers with global write privilege (Tim, for
instance) review the patch publically.  If the patch is fine, they say
"OK" (that is rare when the victim is not very familiar with the
system).  Otherwise, they technically comment on what are wrong
about the patch and suggest directions for improvements. If the patch
is outrageous, let say the patch suggests to sink Axiom, then an
answer might be "don't propose that again." :-)

-- Gaby




reply via email to

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