[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailc
From: |
Trevor Saunders |
Subject: |
Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff. |
Date: |
Thu, 29 Jul 2010 10:56:31 -0400 |
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
- [Opentts-dev] Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff., (continued)
- [Opentts-dev] Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff., Tomas Cerha, 2010/07/28
- [Opentts-dev] Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff., Trevor Saunders, 2010/07/29
- [Opentts-dev] Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff., Tomas Cerha, 2010/07/29
- [Opentts-dev] Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff., Trevor Saunders, 2010/07/29
- [Opentts-dev] Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff., Rui Batista, 2010/07/29
- [Opentts-dev] Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff., Tomas Cerha, 2010/07/29
- Message not available
- [Opentts-dev] Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff., Chris Brannon, 2010/07/29
- [Opentts-dev] Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff., William Hubbs, 2010/07/29
Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff., Hynek Hanke, 2010/07/29
- Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff., William Hubbs, 2010/07/29
- Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff.,
Trevor Saunders <=
- Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff., Tomas Cerha, 2010/07/29
- Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff., Trevor Saunders, 2010/07/29
- Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff., William Hubbs, 2010/07/29
[Opentts-dev] Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff., Tomas Cerha, 2010/07/29
Message not available[Opentts-dev] Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff., Trevor Saunders, 2010/07/29
[Opentts-dev] Speech-dispatcher, OpenTTS, and the outcome of my discussion with Brailcom staff., Bill Cox, 2010/07/29