Better Pre-Split Naming

[friedmud]

Rationale

All of the rationale (and code changes) are over here: libMesh/libmesh#1455

The idea is change the naming scheme for pre-split checkpoint files to make them easier to deal with

Impact

Will change the naming scheme in a backwards incompatible way so a warning will need to go to users.

[permcody]

Please don't mess with the template, even if you dislike it. The three sections are required by the NQA-1 process. I'm for your requested change here though.

[friedmud]

Sorry - don’t dislike it - not sure why I removed it here. It’s not always clear what the delineation is between the first two sections though. Is there an explanation somewhere of what you’re hoping is in each one?

…

On Tue, Oct 17, 2017 at 4:23 PM Cody Permann ***@***.***> wrote: Please don't mess with the template, even if you dislike it. The three sections are required by the NQA-1 process. I'm for your requested change here though. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#10088 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA1JMQ5wQ3tkM5UuD7J-WXFaAiwVNpraks5stQy2gaJpZM4P5zJH> .

[permcody]

The problem is we are using the issue for two fundamentally different things. 1) reporting bugs, which is where the three sections are important. The what, how to reproduce, and the impact 2) enhancements, which is much more of a grey area because NQA-1 assumes that once software is deployed, the development is more or less complete. However, they also understand that there is no such thing as “done” software so enhancements are spelled out as well in the process. You are supposed to report the “what”, the reason for the what, and the impact of the new feature, which is what people are terrible at doing. If we’d really think about design, maybe we’d identify how adding a new feature impacts the existing framework. For instance adding a new system seems like almost no impact because it’s new, but then we partially add it to the coupling interfaces so you can use it. The impact is that it only works in a subset of use cases or it breaks some sanity check that you aren’t aware of, etc. I’m still trying to come up with a better way to describe these processes and make it easier for concurrent development and maintenance. I wish Github would allow use to customize the issues interface a little more. I’d like to see issue reporting and feature enhancements in separate ways (e.g. buttons). On Thu, Oct 19, 2017 at 8:10 AM Derek Gaston <notifications@github.com> wrote:

…

Sorry - don’t dislike it - not sure why I removed it here. It’s not always clear what the delineation is between the first two sections though. Is there an explanation somewhere of what you’re hoping is in each one? On Tue, Oct 17, 2017 at 4:23 PM Cody Permann ***@***.***> wrote: > Please don't mess with the template, even if you dislike it. The three > sections are required by the NQA-1 process. I'm for your requested change > here though. > > — > You are receiving this because you authored the thread. > > > Reply to this email directly, view it on GitHub > <#10088 (comment)>, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/AA1JMQ5wQ3tkM5UuD7J-WXFaAiwVNpraks5stQy2gaJpZM4P5zJH > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10088 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC5XIPupqhn7rHwcoa_N_ykXVevwL7Kpks5stzw2gaJpZM4P5zJH> .

[andrsd]

In GitLab, you can actually have several different templates for filling in issues. I made one for bugs and a different one for enhancements (in RELAP-7). github needs to copy that :-)

[permcody]

Awesome! I didn't know that. Let's hope Github follows suite.

…

On Thu, Oct 19, 2017 at 12:21 PM David Andrs ***@***.***> wrote: In GitLab, you can actually have several different templates for filling in issues. I made one for bugs and a different one for enhancements (in RELAP-7). github needs to copy that :-) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10088 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC5XIEWmdww3WrcViXY9HycDA501jec7ks5st3brgaJpZM4P5zJH> .

[permcody]

This was addressed with changes in libMesh and #10623.