modernize test suite tooling?

[cartazio]

for various reasons, this is absolutely a valid thing

eg, tasty + hedgehog for various reasons seems like a sane strawman

[lehins]

IMHO there is no point of switching to hedgehog, since there is already a whole collection of properties implemented using QuickCheck. Plus I don't see it being a tremendous improvement.

Never used tasty before, but from the looks of it switching to it from test framework should be a piece of cake.

[Shimuuar]

I too don't see any real benefit in switching to hedgehog. In my very limited experience it only better than QC if you need to generate complicated distribution of test data. Otherwise it only require more boilerplate for same effect

Switch to tasty would be simple since API is almost same. Recently I switched statistics from teset-framework to tasty

[cartazio]

sounds sane to me.

[cartazio]

yeah, i actually did a "migrate to tasty" as part of the release cutting for 0.12.1 series, it was a pretty easy shift and it seems to be largely the same system,

[lehins]

@cartazio That is very nice that you did that, but now this work is not on master! Would I be out of line to ask for us to agree on a process that all new changes, including from you would be added through PRs to master only? Picking and and choosing commits or adding changes directly to feature branches were the reason why we had so many problems in v12.0 releases in the first place.
Sticking to this process gives all a chance as well to review new changes and guarantees that we will never get into a situation that some work that was released never even got into master.

Also we need to reset v0.12 branch to releases/v0.12.1, I can do it if you like. This way we can cherry pick from master into v0.12 branch all changes that need to be backported in the future.

[cartazio]

I created a releases/0.12 branch which should be renamed releases/0.12.0 Trust the tags, and use a git gui tool (or something like sublime merge) and I think the workflow will be a tad clearer. But agree it’s not obvious via strictly cli presentations Agreed the norm should be more code review. Certainly a thing I need to do. It’ll be easy to reflect the test suite changes into master. I’ll do that in a few days. Need to catchup on everything else now that Picking and choosing didn’t create problems as such. But everything must needs be documented to the point of obviousness for current past and present contributors. I agree When confused about this stuff, the best way to address it is to message me on one the 4-5 communication apps / protocols I’m on. I tend to explain things best in a conversational context, which is also suitable for protean pre docs for some of these things. ;)

…

On Sat, Feb 1, 2020 at 10:29 AM Alexey Kuleshevich ***@***.***> wrote: @cartazio <https://github.com/cartazio> That is very nice that you did that, but now this work is not on master! Would I be out of line to ask for us to agree on a process that all new changes, including from you would be added through PRs to master only? Picking and and choosing commits or adding changes directly to feature branches were the reason why we had so many problems in v12.0 releases in the first place. Sticking to this process gives all a chance as well to review new changes and guarantees that we will never get into a situation that some work that was released never even got into master. Also we need to reset v0.12 branch to releases/v0.12.1, I can do it if you like. This way we can cherry pick from master into v0.12 branch all changes that need to be backported in the future. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#278?email_source=notifications&email_token=AAABBQRXJN6DEBFCPTJDTMDRAWINZA5CNFSM4KN7C22KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKQ7TMA#issuecomment-581040560>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAABBQSCZZOSMIZ5UW6JOSLRAWINZANCNFSM4KN7C22A> .

[Shimuuar]

I agree with @lehins that working directly on release branch is very confusing for everyone. It works for one developer but confusing for when there many. For starters it's easy to miss and too easy to make some obvious but wrong assumption.

Also we should leave v0.12 branch alone. Resetting long lived public branches is just wrong IMO. And yes branches for 0.12.* releases are a mess. But given release history it's to be expected.

[cartazio]

we'll get better, practice helps

[Shimuuar]

Since #309 is merged issue could be safely closed