Re: [Gnu-arch-users] tla-pqm 0.2

[Joshua Haberman]

On Fri, 2003-10-17 at 12:39, Colin Walters wrote:
> On Fri, 2003-10-17 at 13:56, Joshua Haberman wrote:
> > You don't want
> > to be developing on a tree that is missing longstanding changes from
> > other contributors, do you?  As I see it, doing a star-merge on a
> > development branch is not part of the process of submitting one or more
> > changesets, it's a periodic operation to perform on personal branches.
> 
> Er...we're not talking about automating merges into the personal branch,
> we're talking about automating them *from* the personal branch.
> 
> In other words, I meant that you do the star-merge into the central
> branch on the client, and then send the resulting changeset to the
> server.  This is instead of just sending a merge request to the server,
> which would do the star-merge itself.

I think this highlights my incomplete understanding of arch's
star-merge.  Specifically: how is a star-merge from A to B different
from sequentially applying to B all changesets that A has that B doesn't
have?  Doesn't every branch have a list of all changesets that have ever
been applied to it, directly or indirectly through a merge?

Why is it wrong to think of a merge request as a submission of a
sequence of changesets that already exist on the development branch?

I understand what your point, once I understand the above distinction.

> > Also think of contributors who don't have permission to write to the
> > canonical branch.  They should be able to submit merge requests or
> > changesets and have the people who do have write access approve or deny
> > them.
> 
> Yes...I think the way to implement this though would be to have the
> people who can approve changesets run their own tla-pqm instances.  Then
> instead of submitting merge requests to example-dev, the sub-satellite
> developers submit them to the main developers.

This is undesirable for the projects where I would like to use Arch.  It
presupposes that for a particular changeset there is a developer with
write access who is known to be capable and willing to review a
particular patch.  What I think is more likely are situations where
there is a generic patch that any of several developers could review and
accept, and whoever has time to review the patch queue first should
accept/reject it.

Josh