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

[Trevor Saunders]

Hi,

looks good to me, but a couple little details.

On Thu, Jul 29, 2010 at 09:23:04AM -0500, William Hubbs wrote:
> Hello Hynek,
> 
> On Thu, Jul 29, 2010 at 11:48:00AM +0200, Hynek Hanke wrote:
> > On 28.7.2010 13:19, Luke Yelavich wrote:
> > > Jan mentioned that they try to follow the GNU coding style, but 
> > > generally, as long as the code is readable, and works, coding style is 
> > > not so much of an issue.
> > 
> > The GNU Coding Standards is a guideline that we took,
> > but during the evolution and due to historical reasons,
> > parts of the code divert from the standards in different
> > ways.
> > 
> > We were thinking about what to do, because although
> > it is not functionality-critical, a uniform style would greatly
> > easier cooperation and participation of other developers.
> > We decided that just after the 0.7.1 release, which shall be out
> > during the following weeks, definitely before end of August,
> > we will ask you on the speechd mailing list to submitt all
> > pending patches and then we announce a warning and
> > will reformat all the code. If we coordinate well,
> > we shall avoid merge conflicts then.
>  
>  Are you planning to stay with the GNU style?  If you are open to
>  changing the formatting, I prefer the kernel style personally, I find it
>  to be much easier to read and work with.  For more information on this
>  style take a look at the CodingStyle file in your kernel source tree.
>  Also, there is a script, called Lindent, in the kernel source tree
>  which is a wrapper for indent that sets it up to use that style, so it
>  should be easy to maintain once it is set up.  I'm not sure what editor
>  you use, but if you want to do this and you are using emacs, chapter 9
>  of the linux kernel style document tells you how to set up emacs to
>  format in kernel style.

agreed

> > Clean code indentation according to the standards
> > will then be better enforced on new patches and we
> > will try to keep the master branch clean.
>  
>  I'm not sure about GNU style, but for kernel style, Lindent does this
>  quite easily, you just have to run the script on any file you change
>  before commiting it.

being able to automate this with pre commit hooks is also a good way
to handle this.

> > > Brailcom will certainly attempt to encorporate all patches submitted from 
> > > the community. As to whether or not they will respond, I'll have to defer 
> > > to Jan/Hynek again
> > 
> > We propose the following strategy:
> > 
> > * Incomming bug fixes or small improvements will be commited
> > into the master branch immediatelly so that they are accessible
> > to other developers and will be reviewed afterwards as time
> > permits. Before release there will be a short freeze where all
> > the remaining patches pending review will be checked.
> > 
> > * New features or other significant improvements should be
> > developed in new branches, which can be placed in an own
> > Git repository of each developer.
> > 
> > When work on that feature is finished, its developers will
> > rebase their branch against master, the relevant
> > commits will be polished and well explained. This branch
> > will be reviewed by an oponent who will in turn ask the
> > maintainer to merge that feature into master.

two administrative things.
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.

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.

BTW I don't think "oponent" is the word you want there, but I think
everybody understands what you mean.

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

Trev

> 
> William
> 



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