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

[Hynek Hanke]

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.

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.

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

Best regards,
Hynek Hanke