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 11:28:09 +0200

Ralf Hemmecke <address@hidden> writes:

[...]

| > It is good to have unstable branch where experiments are
|  > conducted.
| 
| Yes, I think that is good. You will probably suggest that for those
| experimental branches there might be other people responsible not you.
| 
| GNU ARCH lets you do this easily.

yes, I guess so :-)

|  > but I think we need one branch that is unstable but not too unstable.
| 
| That's a good point. It sounds like a three stage system.
| 
| A golden branch that will be the stable version. (axiom--main--1)
| A silver branch that will be the almost stable branch (that is where you
|      opted for maintaining)
| Several experimental branches, where one person (or a group of people)
|      agrees on how they do development until the experiment becomes
|      resonably stable to be ready for the silver branch.
| 
| I would like that. No matter if you take my (perhaps naive) suggestion
| or anything else, but we should make clear an development model for
| Axiom that is easier to learn and includes *public* review before Tim
| gets the final decision.

You make a good point.  

| > | 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.
| 
| You get my full support. And to the others: That is a generous offer
| we should not reject that and let long years of experience with gcc
| enter into the Axiom world. We need even more people like Gaby.

Thanks for the kind words.

| > | 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...)
| 
| Although I by now somehow think I can live with tla, I believe that we
| should not prevent you from doing things with SVN. If you are willing
| to maintain the silver branch using SVN, I see no point why we
| shouldn't accept that.

There are tools to convert CVS repositories to SVN ones; I don't know
whether similar tools exist for converting tla archive to SVN.  The
issue is whether Tim is OK with that idea.

| Of course, SVN has some weaknesses (especially not being able to do a
| star-merge), but since you could live with CVS for many years, I am
| sure you can cope with that missing feature anyway.

I understand.

[...]

| > | >    * 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." :-)
| 
| But for public review, I must see the patch applied somewhere. I am
| not a machine that can read native "diff" output. Sorry, but I think
| you need to teach a bit. And in order not to hide this course inside
| the mail archive, it would be just great, if you could open up a page
| on AxiomWiki and let us know. (Thanks in advance.)

OK.  I'm currently attending the C++ commitee meeting (Berlin) where it
is easier for me to read/write mails from a terminal than launching a
browser (slow connection).  So, I'll try to honor your request tonight
(assuming I finished by then what I had to do).  If I don't get a
chance to do it (I'll try hard), there is no chance I'll do it before
the week of 16 April when I'm back to work place.


I'm glad we can work out a plan to make a live branch.

-- Gaby




reply via email to

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