Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff.

[Trevor Saunders]

HI,

On Thu, Jul 29, 2010 at 05:54:16PM +0200, Tomas Cerha wrote:
> > 1. why not give the "oponents" commit rights on the public repo? I
> > just trying to make the maintainers life a little easier, he seems to
> > not be doing anything in this loop.
> 
> Well, yes, it may reveal as more practical this way.  We just tried to
> come out with something simple.  Let's see how it works and we may
> adjust the process based on the experience...   That is not that we
> insist on something or are paranoid or whatever.  We just need a frame.

sure, I didn't think that, it was just an improvement that came to mind, so I 
sugested it, what ever works better :-)

> > 2. if you are maintaining a feature branch on a public repo after
> > pushing that branch to a public repo it can't be rebased again,
> > because doing so would break history.  What this ends up meaning is
> > that say I start work on feature foo, and although its not complete I
> > want to show someone else what I have so I push the branch to my
> > public repo.  After this I can't rebase that branch again without
> > deleting and recreating it, I can however merge.
> 
> We usually address that by publishing new rebased versions of branches
> with the naming convention like experimental -> experimental.1 ->
> experimental.2 etc.  We may add that into the rules.

I gues that works,  it does have the downside that testers  have
to setup a new branch and pay attention for a new branch showing up,
it can work.  In any case it seems like we can work this out.

> > BTW I don't think "oponent" is the word you want there, but I think
> > everybody understands what you mean.
> 
> Ok, let's say "reviewer" then if it works better.

yeah, that sounds more descriptive :-)

Trev

> 
> Best regards, Tomas.
> 
> _______________________________________________
> Speechd mailing list
> Speechd at lists.freebsoft.org
> http://lists.freebsoft.org/mailman/listinfo/speechd