Re: New sequencer release 2.2.8

[Mark Rivers via Tech-talk <tech-talk@aps.anl.gov>]

Well said, those were my thoughts as well.

Mark


Sent from my iPhone

> On Dec 12, 2019, at 12:41 AM, Ben Franksen via Tech-talk <tech-talk@aps.anl.gov> wrote:
> 
>> 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
> <pEpkey.asc>