RE: Possible deadlock in serial.c

[Gary Thomas <gary at mlbassoc dot com>]

On Wed, 2003-05-21 at 13:10, David Marqvar (DAM) wrote:
> > > > I don't think that there will be any patches made to the 2.0 branch
> > > > now that it has been "released".
> 
> > > Does that mean that the ecos-v2_0-branch will *not* be touched at all
> from
> > > now on?
> > > It comes as a surprise to me since I would expect bug-fixes with
> relevance
> > > for eCos 2.0 to be committed to this branch as well - thus only new
> > > features/major revisions would be kept solely in the latest branch.
> 
> > If there are really serious bugs that can be fixed on that branch, it
> > may happen.  I don't expect it though - we [as mostly volunteers] don't
> > have the resources to keep the branch up to date, nor do we expect to
> > ever have a follow-on release from the branch.
> 
> I understand - what I suspected ;-)
> 
> > The trunk is kept quite stable and has many improvements already that
> > aren't in the 2.0 release.  Is there something that keeps you from 
> > using it?
> 
> Nothing really. My feelling is (as usual :) - that the trunk is pretty
> stable!
> We are currently using it.
> 
> Initially I just assumed that it would work the same way as with the linux
> kernel - when a new stable kernel branch is created a lot of patches still
> go into that branch while the main/risky development moves on the trunk. I
> guess you know much about that!
> 
> Maybe I should just stick with the trunk and then keep an eye on changes in
> the core modules we use.
> Later we may create our own stable version to be used with stable realeases
> of our own software, while we continue to use the trunk version for
> development.
> We may then watch changes in the trunk and only move the ones we want to our
> own stable branch.

I keep my own CVS tree for local development.  I merge the public 
sources to it as they change.  When I need to start a new project, 
I base it on my local repository which I can tag, etc.  That way
I can reliably develop and deliver code, no matter what the public
tree does.  Of course, whenever possible my local changes are pushed
out to the public tree as well.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates