EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Merges: 3.14.12 vs 3.15
From: Andrew Johnson <[email protected]>
To: Jeff Hill <[email protected]>
Cc: "'Core-Talk'" <[email protected]>
Date: Thu, 24 Jun 2010 16:36:56 -0500
Hi Jeff,

On Thursday 24 June 2010 15:16:25 Jeff Hill wrote:
> > If I understand Jeff's position correctly (correct me
> > if I'm wrong Jeff) he says that minor releases should
> > only contain bug fixes and no new features.
>
> Yep, that’s still my perspective. From my viewpoint we should be especially
> careful to not mix up patches with new features. For two reasons. One, we
> don’t ever want a situation where the user looses confidence about
> installing patches because they might introduce new bugs. Second, we work
> on a special type of software which people depend on. A selling point of
> EPICS is that we have maintained a certain level of quality in the past.
> Sometime a conservative approach is necessary.

In recent years the role of the 'bug fixes only' series has been played by the 
Known Problems page for each 3.14.x release and the associated patches linked 
from that page.  The branch lp:~epics-core/epics-base/3.14.11+patches makes 
the fully-patched 3.14.11 code available for download using Bazaar, but I do 
admit this is a fairly recent product.  In the days of using CVS I don't think 
anyone was willing to maintain such a branch, but it should be easier to do 
with Bazaar.

> Maybe the solution is to have three independent release series: maybe we
> should have the stable production release, the near term features release,
> and the evolution release. With that approach we can have an independent
> release series on all three versions simultaneously. With this approach it
> needs to be very clear to everyone involved where we are headed. That is,
> it needs to be very clear that day-to-day support of the production release
> will after some longer period of time go away, the near term release will
> be eventually declared to be the production release, and the evolution
> release will eventually become the near-term feature release. What do you
> think?

The way I see it, 3.14.11+patches is our stable production release, the 3.14 
series is our near-term features release, and the other branches in Bazaar 
demonstrate the directions we might go in.  Using a DVCS and publishing lots 
of branches allows us to to avoid having to choose a single direction for 
evolution before the development on each is finished; I see that as much more 
Darwinian (and less risky) than the old CVS approach of having a single branch 
for future evolution.

> Lastly, I have to say that its disturbing that my new server with server
> based event filtering isn't even discussed as an option for the list for
> any release. I have been working very hard to get this finished. Yes, its
> new code, but if regression tests are reasonably exhaustive and we are
> clear about how and where new releases should be used then I don't see a
> problem.

As Ralph pointed out, your work is not yet suitable for merging, and you 
haven't posted a merge proposal for it (he is wrong about the code visibility 
though, your changes are on the cvs-trunk branch).  The branches I discussed 
are all listed at https://code.launchpad.net/epics-base/+activereviews as they 
have open reviews.  I'm not ignoring your work, but it's up to you to bring it 
up for discussion with a merge proposal once it's ready for merging.  (Note 
that it will have to be re-based onto the 3.14 or a future 3.15 branch first 
though, and I would recommend doing it in a series of branches which will be 
easier to review.)

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harald Welte



Replies:
Re: Merges: 3.14.12 vs 3.15 Ralph Lange
RE: Merges: 3.14.12 vs 3.15 Jeff Hill
References:
Merges: 3.14.12 vs 3.15 Andrew Johnson
RE: Merges: 3.14.12 vs 3.15 Jeff Hill

Navigate by Date:
Prev: Re: Merges: 3.14.12 vs 3.15 Ralph Lange
Next: Re: Merges: 3.14.12 vs 3.15 Ralph Lange
Index: 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Merges: 3.14.12 vs 3.15 Ralph Lange
Next: Re: Merges: 3.14.12 vs 3.15 Ralph Lange
Index: 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·