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

[William Hubbs]

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.

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

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

William

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://lists.freebsoft.org/pipermail/speechd/attachments/20100729/60b15552/attachment.pgp>