I am importing all the the issues from https://github.com/NixOS/nixpkgs. (Currently I am using git-bug from PR #585).

When the import is finished the number of open and closed issues in git-bug and on github do not match. For example, github has 4298 open and 15884 closed issues in nixpkgs but git-bug shows the following:

$ git-bug ls --status open | wc -l
    4317
$ git-bug ls --status closed | wc -l
   15865

This is caused by github having issues which are closed, but which seem to not have a ClosedEvent (as described in their API https://docs.github.com/en/graphql/reference/objects#closedevent). An example of such an issue is https://github.com/NixOS/nixpkgs/issues/90920. You can also see that when looking at the issue on the github website (the last link). Closed events usually have an issue-closed item in their timeline. This issue does not have that.

Well, maybe the "closed" field on https://docs.github.com/en/graphql/reference/objects#issue in the Github API is supposed to handle that. I will have to try.

Any idea how that's even possible on the github side?

Thanks for your work, it's really useful.

Any idea how that's even possible on the github side?

No, I don't know.

I am importing all the the issues from https://github.com/NixOS/nixpkgs. (Currently I am using git-bug from PR #585).

Is there any chance you could push your git-bug import of nixpkgs somewhere public?

I have been trying to do the same import for the last two weeks. Something has broken on github's side and is still broken; see #740 and #749. I am getting kinda desperate (and disappointed with github). Now that I'm submitting to nixpkgs this is no longer a theoretical issue for me.

Is there any chance you could push your git-bug import of nixpkgs somewhere public?

I don't have it anymore, sorry.

Anybody knows if that's still an issue, especially in the newly released v0.8.0 ?

Michael Muré (MichaelMure) added label area/bridge 3 years ago

This bot triages untriaged issues and PRs according to the following rules:

• After 90 days of inactivity, the lifecycle/stale label is applied
• After 30 days of inactivity since lifecycle/stale was applied, the issue is closed

To remove the stale status, you can:

• Remove the lifecycle/stale label
• Comment on this issue

github-actions (github-actions) added label lifecycle/stale 1 year ago

sudoforge added label area/bridge/gitlab 1 year ago

sudoforge removed label area/bridge 1 year ago

github-actions (github-actions) removed label lifecycle/stale 1 year ago

This bot triages issues in order to help the maintainers identify what needs attention, according to the following lifecycle rules:

• After 90 days of inactivity, lifecycle/stale is applied
• After 90 days of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied

This bot will not automatically close stale issues.

To remove the stale status, you can:

• Remove the stale label from this issue
• Comment on this issue
• Close this issue
• Offer to help out with triaging

To avoid automatic lifecycle management of this issue, add lifecycle/frozen.

github-actions (github-actions) added label lifecycle/stale 1 year ago

This bot triages issues in order to help the maintainers identify what needs attention, according to the following lifecycle rules:

• After 90 days of inactivity, lifecycle/stale is applied
• After 90 days of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied

This bot will not automatically close stale issues.

To remove the stale status, you can:

• Remove the stale label from this issue
• Comment on this issue
• Close this issue
• Offer to help out with triaging

To avoid automatic lifecycle management of this issue, add lifecycle/frozen.

github-actions (github-actions) added label lifecycle/rotten 8 months ago

github-actions (github-actions) removed label lifecycle/stale 8 months ago

sudoforge removed label lifecycle/dormant 7 months ago