Re: [Axiom-developer] Maintainers

[Gabriel Dos Reis]

root <address@hidden> writes:

| > | > 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.

If something is missing from the patch, then it must be discussed on
the list; have the author take care of it instead of you having
conversation with yourself, mangling the patches and require author
that what you applied did not go beyond reason.  The only exception I
can think of this is that of automatically generated files that need
not be included in the patch (case in point configure.ac -> configure).

But, again that should not be your responsability of mangling
patches and have people check that the applied mangling is correct.

| > 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? 

Please don't be afraid of the specific breakage so that we work out
the details.   

If build-improvements changeset goes in first, then you have to take
that into account in preparing your following patch that you don't
break existing semantics without good reasons.  If build-xml goes in
first then it is my responsability to make sure that I don't break
existing semantics without good reasons.  That procedure is not
different from any other patches.  It is a no-brainer.

| 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.

Not only that.  Every author has the responsability of making sure
that his changes does not break the whole system and does not prevent
further progress of the whole system.  It is not an individual-thing.
It is a collective product. 

|  but the
| owner of the silver branch is responsible for making sure that ALL
| changesets are checked.

The owner of silver branch has to make sure that the whole system does
not fall apart.  For this to be workable, he has to make sure that
every contribution is made to the point that the whole system is still
coherent.  But, that does not imply that he has the burden and
responsability to mangle patches and afterward has people guess what
was done is faithful to their ideas.  Rather, it should be explained
to the contributors how their contributions should be structured to
ensure that the whole system is functionning, so that others can
contribute too.

| Further, the silver owner has to deal with
| convincing me that the changes should get accepted into gold.

That is a very different issue.  

[...]

| 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.

that is an interesting analogy, but:
  (1) Did anyone suggestion anything along those lines?
  (2) for an anology to be meaningful, you have to explain how Axiom
      relates  a conference and why that analogy is sound to lead to
      any meaningful conclusion.


-- Gaby