fixed test/core_multifile_actions.py

[paolopas]

• fix JAM_SEMAPHORE test does not seem correct. #164
• added test/semaphore.py for testing of JAM_SEMAPHORE, due to actual b2 shell limitations the test does not work on non-posix platforms, and therefore is disabled

[grafikrobot]

@paolopas given the previous confusion regarding my updating the PRs for testing and cleanups would it be okay to:

1. Mark PRs draft initially.
2. I will comment and you can make any changes you want while it's in draft.
3. When all done with changes and approved, you change it to ready (undraft).
4. I can then go in and do my updates to merge it.

Does that sound reasonable?

[paolopas]

1. Mark PRs draft initially

I certainly should have marked #542 as a draft, and thank you for pointing it out, and sorry for the mix-up.

2. I will comment and you can make any changes you want while it's in draft

who can stop it?

3. When all done with changes and approved, you change it to ready (undraft)

Once I was sure I was done, I closed the PR and submitted one that I consider final, which is this one. It is ready as you see.
I'd rather make a new PR than pile up commits on an already dirty branch. If you have a lot of changes and tests, you might forget something, and it's not a given that you'll be able to clean up the branch from the code of the various tests.

4. I can then go in and do my updates to merge it.

When making changes, however, you should be careful to avoid the problems in #540, because otherwise I can't continue working on the same branch either, in addition to the risks of compromising the work done. Unless you're sure you don't need to ask me for any further changes.

So yes, it's all reasonable but I can't accept your protocol, if I think a PR is fine as it is I submit it without marking it as a draft.
René, I understand your point, and I will be careful not to make your job more difficult. Please do the same.

[paolopas]

René, I don't want to sound abrupt, and I want to reassure you that we don't need to invent a new reporting system or a new shared protocol to collaborate safely and effectively.

I understand that, after what happened a dozen PRs ago (or more), you're worried that I might do further commits to a PR branch. But aside from the fact that I try to avoid it, if it were to happen, I have the tools to determine whether the branch was modified by you and not proceed anyway. And it seems to me that in fact the problem has not occurred again.

On your part, however, it is sufficient that you do not abuse a topic branch if you then ask me to continue working on it.

As you can see, we don't have to invent anything that forces us to work differently than usual.

[paolopas]

continues on

1. actions/runs/21852631393 see 0b0f44e
2. actions/runs/21930438661 see 0222121
3. actions/runs/21957475488 see a8f537a
4. actions/runs/21967132380 see db868c3