axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] Maintainers


From: root
Subject: Re: [Axiom-developer] Maintainers
Date: Sat, 4 Nov 2006 01:54:34 -0500

> | > But, the check-in would have been approved after review, not before!
> | 
> | Actually, both. 
> | 
> | The check-in needs to be reviewed before it is committed back to the
> | axiom--silver--1 branch to make sure it doesn't break other pending
> | changes.
> | 
> | The check-in needs to be reviewed after it is committed by the author
> | to make sure their changes are all correctly applied and by the silver
> | maintainer to make sure that nothing broke.
> 
> Only because you have introduced an unnecessary step.

or you left out an important step. even programs do this in several
steps with different responsibilities. think of databases. when you
insert or modify a record there are pre-scripts and post-scripts that
run to validate the change even though you claim it is correct.
sometimes a change you make gets rejected for reasons you didn't expect.




> 
> Patch is reviewed, and accepted.  Author has the responsability to
> check in as approved.  Period.
> 
> Now, if you introduce that walk-around, people have to check that you
> did not mess up their changes.  This is compounded by the fact that we
> know of this changes only after a day, when possibly other changes
> have been applied too.  Remove the unnecessary step; make the source
> live. 

so if you add build improvements as a changeset and i add an ant
build-xml as a changeset who is responsible for mediating the
breakage?  we both have our reasons. you want BI because it follows
standard GNU practice. i want ant because i've written java-based
regression testing (no, i haven't written such a thing).

it is really a separation-of-concerns issue.  every author has a
vested interest in making sure his changeset is accepted.  but the
owner of the silver branch is responsible for making sure that ALL
changesets are checked. Further, the silver owner has to deal with
convincing me that the changes should get accepted into gold.

think of it as a human-mediated "svn merge" with rationality.
the machine may think the changeset is ok but not the human.

if we're developing literate programs for the humans rather than
patch files for the machine somebody has to review the result.
you wouldn't expect a conference chair to allow anyone to submit
a paper without review, nor are they allowed to change it after
it has been accepted.

t






reply via email to

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