Comment author: @gasche

The PR you link to discusses a patch ( ocaml-cross/opam-cross-windows#5 ), but this patch is specific to cross-compiler targeting Windows.

What we would like to have upstream is a more general support of a host/target distinction, with those values specialized according to the target rather than the host. But those patches will come from people working on cross-compilation already.

Do you know if anyone is working on this more general approach? Could your Windows work then be rebased on top of that?

I'm tempted to "suspend" the PR as a way to mark that maintainers are unlikely to work on that in the short term, and that external contributions, in particular from people already working on cross-compilation, woud be warmly welcome.

Comment author: @whitequark

Yes. The patch is a hack. It is a hack and not a proper patch because I have no earthly clue as to how to do it decently.

I am unaware of anyone else working in that direction or even being aware of the problem.

Comment author: @whitequark

@gasche Huh? Why did you mark this as "resolved"? This is absolutely not resolved in any way, what you did was just made sure that the issue will be promptly forgotten.

Comment author: @gasche

I believe that "suspended" is the right status for this PR, and this is accessible under the "resolved" parent status. The status name is indeed misleading (the issue is not resolved), but it has the intended consequence that maintainers will not come back to the issue on each new release, but rather wait for someone (maintainer or not) to make progress and reopen the case.

In my mind "resolved > suspended" should be interpreted as "this issue is not going to move by itself, if you care about it you should probably work on it yourself".

Comment author: @whitequark

Well, that's a probably the second most hostile and unproductive way to regard an issue like this after closing it with a comment saying "we don't give a damn". In fact, you've just guaranteed that if I ever fix this myself, I won't bother upstreaming it.

Comment author: @dbuenzli

Gabriel, this way of proceeding makes little sense to the end-users of the OCaml system, unless, in that particular case, the dev team doesn't give a shit about cross-compilation which AFAIK is not the case given the recent improvements that were merged.

The BT is already hard to search for issues so if we start marking as resolved, issues that are not we are not going anywhere. If this is a BT usability issue for release managers please find another way to resolve it (e.g. by tagging it with 'needs help' so that these bugs can be easily ignored by them).

This feels like sweeping issues under the carpet.

Comment author: @gasche

whitequark, I'm not sure why you are reacting this strongly. I moved the issue back to "confirmed" land, with apologies for making unpleasing triaging choices.

I guess you and Daniel are right that this resolution makes little sense. In fact I just found out that moving a "resolved > suspended" issue back into non-resolved land keeps the "suspended" bit, which is... interesting and could be of use in the future.

I think the important bit here is the "cross-compilation" tag which I added, which guarantees that as soon as someone starts working more thoroughly on cross-compilation they will be able to find the issues that would need fixing. If you see a cross-compilation issue that lacks the tag, please add it or ping me to do so, it's helpful.

(Indeed, the dev team is interested in improving cross-compilation in general.)

Comment author: @damiendoligez

@gasche:

1. the Status and Resolution fields are completely orthogonal, I don't know why you think something has to be "resolved" to make "suspended" available.
2. For this kind of PR, I set the Target Version to "later", which means "we are not working on this in the short term but contributions are still welcome". This takes the PR out of the release workflow.

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

I think there was an effort to fix this systematically, but I don't know if this issue is fully fixed, and I couldn't quickly determine if it is.

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

Stop with the stale labels already.

Agree with @whitequark. In Rizin project we also initially enabled the stalebot but after year of use it was considered an annoyance and harmful since not all old issues are irrelevant even after many years of existence. Closing all bugs will not happen anyway, thus the number of opened issues should not be gamified, in my opinion, and issues treated as a kind of knowledge base, sometimes actionable and useful, even with workaround information.

Drew DeVault wrote a good article about it: https://drewdevault.com/2021/10/26/stalebot.html

It is plainly disrespectful to anyone who spends their time investigating and filing bugs. Especially considering that this specific issue has a long history of maintainers being disrespectful!

Anyway, I am going to harass people here about the stalebot until they fix it or ban me.

I agree that the stale bot is bad and I would rather have it go away -- I agree with the post by Drew. There is obviously disagreement about this among compiler maintainers; some maintainers want to close PRs/issues that are going nowhere, and the stale bot helps with that.

I am pretty sure that "harass[ing] people here" is not going to improve the situation in any way; please don't do that.

The bug still exists today, and it is still the case that it is waiting for someone working on cross-compilation to be solved properly.

To my knowledge the best documentation of cross-compilation today is in the Diskuv documentation by Jonah Beckford. It documents several limitations, including the one in the present issue report.

I am closing this issue because it will make the stale bot go away, which is fine, and not prevent discussion in any way. If someone actually starts working on cross-compilation for OCaml, they should feel free to reopen.

https://github.com/ocaml/code-of-conduct/blob/main/CODE_OF_CONDUCT.md

Closed #7250 as completed.

The "completed" here perfectly complements the attitude that brought the stalebot online.

I'll make sure to close all of the other issues I've opened, since it's clear that no one cares about them and there is no point in doing anything else.

Thank you, @gasche.

Two comments:

• A repeating pattern in this discussion is maintainers using imperfect (or downright bad) tools, and infrequent contributors being offended by the messages generated by those tools. As a maintainer, I find it harsh to blame me because the default way to do something sends a "resolved" message that in fact does not work in this particular situation. (This happened with both Mantis, our previous bugtracker, and now Github.) I think that you do have a point that triaging tools embody attitudes towards contribution, but I would prefer to be given the benefit of the doubt that most of it is unintentional -- it is not like there is a perfect, convenient bugtracker that never sucks and that we can easily adopt. Some aspects could be improved with people working on that (for example the stale bot itself clearly should not mark issues as "resolved"), but maintenance resources are scarce (see this discuss post) and no one volunteered to spend time on the bugtracker.

• You @whitequark have made impressive experiments of bringing the compiler well outside the comfort zone, and generated bug reports out of that. I am very glad for this work, but it is also true that most frequent contributors have other priorities and no one has volunteered to specifically work to fix those issues. There is progress from time to time (for example, at least the cross-compilation situation is better documented now; on the Unicode front @xavierleroy made nice progress with Recognize UTF8-encoded Latin-1 letters #11717 and Modest support for Unicode letters in identifiers #11736 ; but Modest support for Unicode letters in identifiers #11736 is blocked on a filepath issue with no volunteer to do the work). I wouldn't say that "no one cares about your issues", but I personally care about more things that I can work on by myself, so either people volunteer to help or many things stay in limbo for years.

• but I would prefer to be given the benefit of the doubt that most of it is unintentional -- it is not like there is a perfect, convenient bugtracker that never sucks and that we can easily adopt.

I apologize for my earlier remarks (both the recent one and the one made many years before), I agree that I was out of line in both cases, and I'll make sure to approach the project in a different manner from now on.

That being said, I must mention that I only do so because you are someone I have a lot of respect personally as a result of many interactions over the years (on here, on #ocaml IRC, on StackOverflow and probably elsewhere).