Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Mon, 28 Jun 2010 18:51:17 -0600

> > 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
> 
> The known problems patches are pure bug fixes. After applying those, the
> result will have the bugs fixed, but no new features.

I admit to being a bit confused by this. As I recall, in the past the "Known Problems" patches were only quick fixes for a very limited set of issues, and these patches were intended for application only against the latest R3.14 branch. Presumably, under a scenario where R3.14 point release contain new features, the net result would contain also the new features in addition to all of the patches (some of the patches coming from the "Known Problems" patches and the rest being already included in the point release). 

The bottom line is that if we are to successfully (therefore efficiently) produce both a patched version and a new features version then presumably we would need to keep these in different branches in the source code control?

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: [email protected] [mailto:core-talk-
> [email protected]] On Behalf Of Ralph Lange
> Sent: Friday, June 25, 2010 9:30 AM
> To: EPICS Core Talk
> Subject: Re: Merges: 3.14.12 vs 3.15
> 
> On Thu 24 Jun 2010 19:33:01 Jeff Hill wrote:
> >> 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?
> >
> 
> Correct.
> 
> > 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
> 
> The known problems patches are pure bug fixes. After applying those, the
> result will have the bugs fixed, but no 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.
> >
> 
> That depends on the system type (development/production), local upgrade
> cycles, and institute policies, and can safely be left to the local
> EPICS manager, who will have the choice of applying bug fixes or not,
> switching to a new release or not.
> 
> >> 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.
> 
> Features are important, not branches.
> Launchpad provides a rich set of mechanisms to collaboratively work on
> feature specification (blueprints), implementation (shared development
> branches), and integration into release series (merge proposals /
> reviews).
> 
> I don't think "having a single development branch" and "deciding ahead
> of time what features will go in" are good collaborative mechanisms for
> software development.
> 
> > So lots of work can occur
> > with little confidence (substantial risk) that
> > any of it will ever be used.
> 
> The process is completely open: anyone is free to download and use any
> of the available branches. So - whoever needs a feature can use it
> anytime.
> 
> Work that has an agreed-upon and reviewed specification and a tested and
> reviewed implementation will have a high chance of being included in the
> development series and/or backported to stable series.
> 
> > Also with a designated
> > evolution branch users see where we are headed
> > and can try out one single branch that reflects
> > that trajectory.
> >
> 
> We will have a designated evolution branch, so users will be able to see
> what will be in the future of the stable series. Blueprints and
> development branches are visible, so users can see what other ideas are
> around and have a look at their progress.
> 
> The main change and big advantage over the old system is that a "heavy"
> feature can be developed, implemented, and tested completely independent
> from all other developments. It does not block the evolution branch for
> a possibly long time, with the development itself being completely
> visible at all times.
> 
> So - actually users can see much better where we are headed.
> 
> Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System