Migrated Bugzilla content and header names/angle brackets

It seems the Bugzilla migration into GitHub has led to problems in the display of code.

For example:

#include

struct SleepState {

appears instead of

#include <atomic>

struct SleepState {

in Atomic operation emits an __atomic_* call rather than an instruction for trivial structure · Issue #46921 · llvm/llvm-project · GitHub.

It seems to me that the original is not retrievable by through the GitHub web interface unless if someone is logged on with access to edit issues.

GutHub comments are rendered as markdown. We imported the text from Bugzilla as-is as there was a huge mixture of plain text, custom markup and markdown. The original text is still there, but not rendered by GitHub properly. I went ahead and rewrite the text in proper markdown. Now everything is there. The original is available from bugzilla in any way – you just need to click on the link in the header.

Is there a concern that someone who does not have access to editing the issue won’t be able to see the original text via GitHub?

Thank you.

Is Bugzilla going to remain available for such cases in the future? Do we know how long?

1 Like

This is how GitHub works. We cannot change their markdown render.

This is exactly why bugzilla is still there in read-only mode. We hope it will be long enough to all similar issues to be resolved.

But, if we are able to work with them, we can request “view raw markdown” for people without edit access, no?

1 Like

No idea. I do no see anything like this in GitHub roadmap and I’m not aware about such GitHub feature – so you might want to contact GitHub support asking for such feature.

It would be better if the relationship with GitHub was handled by the foundation / the IWG.

Otherwise saying that each individual LLVM contributor should talk to the generic GitHub support is acknowledging that we shouldn’t expect that the LLVM project as a whole plans to have a line of communication about feature requests. Basically @reinterpretcast wrote “if we are able to work with them” and the answer here implicitly looks to me like “we aren’t”.
This looks quite important to me to clarify at a time where we discuss moving to pull-requests and what to expect then.

2 Likes

@mehdi_amini You are quite right. GitHub is a huge company. It is not a startup that could implement some feature for users in ~week. Practice shows there is no way we could influence their roadmap and even if something is on their roadmap we cannot rely on ETAs.

So, long story short: while we can ask something we should not rely / expect that something actually will be implemented.

1 Like