Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 24 Jun 2010 17:33:01 -0600

> 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

But, known problems patches currently reflect only 
a limited subset of quick fixes for known issues, 
and not all of the other patches available in a 
point release?

So, under the proposed approach to point releases, after 
installing such patches the net result remains a release
with both the patches and also new features and this 
might lead some users to conclude that they are better
off with an un-patched release if the bug isn't (yet)
directly experienced by the EPICS system manager.

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

So the primary difference is that there are many
evolutionary branches and no mechanism to start 
deciding ahead of time on a single branch that 
will become our future. So lots of work can occur 
with little confidence (substantial risk) that 
any of it will ever be used. Also with a designated
evolution branch users see where we are headed 
and can try out one single branch that reflects 
that trajectory.

> As Ralph pointed out, your work is not yet 
> suitable for merging, and you haven't posted 
> a merge proposal for it

That’s definitely true. I'm not proposing a 
merge of the new serer at this time.

> I would recommend doing it in a series of 
> branches which will be easier to review

I definitely plan to break up the merge into 
components. Perhaps like this.

o several independent merges for libCom
o data access
o the server (or both the server 
	and data access together)

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]]
> Sent: Thursday, June 24, 2010 3:37 PM
> To: Jeff Hill
> Cc: 'Core-Talk'
> Subject: Re: Merges: 3.14.12 vs 3.15
> 
> 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System