This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
RE: Possible deadlock in serial.c
- From: Gary Thomas <gary at mlbassoc dot com>
- To: "David Marqvar (DAM)" <DAM at tt dot dk>
- Cc: eCos patches <ecos-patches at sources dot redhat dot com>
- Date: 21 May 2003 13:18:55 -0600
- Subject: RE: Possible deadlock in serial.c
- Organization: MLB Associates
- References: <E70B4FA554FB6C44BC7FAC9A9CE0CBC436D53D@ntex.tt.dk>
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