[Opentts-dev] Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff.

[Trevor Saunders]

Hi,

> > being able to automate this with pre commit hooks is also a good way
> > to handle this.
>  
>  I'm not sure I know much about this.  I've never seen how well
>  automating something like this works.

I'm not sure about on the master repo, that seems possibly risky, but on 
personal repos I think it should be fine.

> Actually you can rebase.  What you can't do is, after you rebase, you
> can't push back to your branch for feature foo.  In other words, the
> rebase _MUST_ be the last step.  Once that is done, you should never
> push back to the remote branch for feature foo.  You can continue to
> commit locally to the branch, but do not publish the changes back to the
> remote branch.

fair point.  it does mean however that once the feature is agreed to
be a good idea the patches have to be sent as email or something
instead of pulling from the public repo.  So basically what I mean is
this 1 its not a big deal and if things are done right should rarely
come up, but it could be an issue we'll work out in the future if
there is a need.

> > BTW I don't think "oponent" is the word you want there, but I think
> > everybody understands what you mean.
> 
> I wasn't going to bring this up, but I agree, I think reviewer or
> something similar would be a better word.  An "opponent", to me, is
> someone who would do everything possible to make sure my work _NEVER_
> got into the tree.

lol

Trev

> 
> > 
> > > > 
> > > > The oponents must be well familiar with the architecture and
> > > > code, but can be from outside Brailcom. The role of the
> > > > maintainer is more to lead and steer, but he will not in detail
> > > > review all the submitted code, will trust the given opponent,
> > > > and will in turn concentrate to resolve all merge/patch requests
> > > > fast, communicate well and keep the whole thing running smooth.
> > > > 
> > > > This is important to keep the master branch reasonably
> > > > stable for every developer and not create merge conflicts
> > > > while still allowing fast integration of new features into master.
> > > > 
> > > > I would further like to clarify, that we plan to get better
> > > > in publishing the roadmap, planned features, priorities, the
> > > > decisions that were made and why, so that we are all
> > > > better informed on what is happening and where we are
> > > > going.
> > > 
> > > This all sounds very good.  I believe that with this level of
> > > communication we can get many things done. :-)
> > > 
> > > I have one question though.  Say someone posts a patch to the mailing
> > > list.  I think it is a good idea to reply back to the mailing list so
> > > that the person who posted the patch knows what we did with it.  If we
> > > apply it to the tree they should know that, andif we do not, it would
> > > probably be helpful to them for us to explain to them why we couldn't
> > > apply it.
> > > 
> > > Also, this would help other developers because we all would know then
> > > that the patch had been processed.
> > > 
> > > What do you think?
> > 
> > Since there is a list to which commits are auto anounced I think the
> > only issue is telling people what is wrong with patches that don't get
> > applied, but I don't think any body would mind the extra mail saying
> > commits are applied.
> 
> The mail serves a couple of purposes.  Besides letting contributors know
> that their patches have been accepted, it gives us a chance to
> publically thank them for their work and to let the other developers
> know that the patches have been applied so that they don't spend any
> time working on them.

sure

Trev

> 
> William
> 



> _______________________________________________
> Opentts-dev mailing list
> Opentts-dev at lists.opentts.org
> http://lists.opentts.org/listinfo.cgi/opentts-dev-opentts.org