Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Fri, 25 Jun 2010 11:30:19 -0400

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