Experimental Physics and
Industrial Control System

Ben Franksen via Tech-talk <[email protected]> · Thu, 12 Dec 2019 09:41:48 +0100

Am 11.12.19 um 23:12 schrieb Michael Davidsaver via Tech-talk:
> On 12/11/19 9:55 AM, Johnson, Andrew N. via Tech-talk wrote:
>> On 12/11/19 11:01 AM, J. Lewis Muir via Tech-talk wrote:
>>> On 12/11, Benjamin Franksen via Tech-talk wrote:
>>>> (I just received the third bug report and the second fix for this
>>>> problem. Apparently a lot of people use that platform for development
>>>> nowadays and nobody looks at the "known problems" page in the docs...).
>>> Yes, that's because the "known problems" page concept is weird, IMO.
>>> EPICS does it too, and I've complained about that previously.  People
>>> expect that if you know about a problem, you will fix it and make a new
>>> patch release.
>> The EPICS core developers don't maintain Known Problems pages of Base releases any more, although some sites would prefer that we did. The idea of them was to provide patches that sites could apply to existing installations instead of their having to install a complete new version with an updated version number and then have to reinstall (or at least re-configure and build) everything downstream of Base. Unless you have an automated configure+build system like Sumo the latter can take a lot more effort.
>>
>> Mark Rivers pointed out that Red Hat do provide a Known Issues page, but I think that's just for the things they know about at release-time; I don't think they update those as new issues are discovered after the release, which is what I used to do for Base.
> 
> As one person who has been pushing against the "known problems" page, I should say something.
> 
> A known problems page doesn't take the place of patch releases.  It doesn't take
> the place of VCS commit messages.  And it (should) necessitate additional testing to make
> sure the net number of bugs has actually been reduced.  All I see only extra (unfunded) time,
> something that Andrew, Ralph, and myself do not have in abundance.  I would rather see that
> time spend on overheads which can't be avoided, or... maybe even some development.
> 
> Of course, there is no reason why the work of maintaining a known problems page has
> to be done by Andrew.  Anyone can occasionally look through the recent VCS history
> for bug fixes.  I did this while at NSLS2 for the debian packaging, also found it
> a good learning experience.

I should probably say something here, since this started with the sequencer.

I don't like to maintain a "known problems" page either, and I agree
that it is better to provide patch releases more often. On the other
hand, making a new release always involves a certain amount of
administrative overhead. In my case, while some of the process is
automated, there remain a few things I have to do manually: (1)
increasing the release number in the configuration, (2) adding release
notes, (3) adding the new version to the Installation page of the docs,
(4) recording this as a patch, (5) tagging the repo, (6) run the build
and tests to make sure if haven't forgot anything, (7) running the
automation that publishes the new release, (8) send an announcement
email to tech-talk.

I guess creating a new release of EPICS base involves much more work.

Adding an item to the "known problems" page and publishing the docs is a
lot more light-weight and requires less care.

So there is a tension here between releasing often and how much time you
are willing to spend with project administration. Normally I wait until
I have accumulated at least a hand-full of patches before I make a new
release, except if there is a critical bug. As I stated in the
announcement, I wasn't aware that nowadays MacOS is a popular
development platform, so I did not take the build problem quite as serious.

Cheers
Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System