General Discussion #294

Open
opened 6 months ago by XPhyro · 21 comments
Owner

Use this issue for general discussion that does not warrant its own issue.

Continuation of: https://web.archive.org/web/20220619191307/https://github.com/nsxiv/nsxiv/discussions/119

Use this issue for general discussion that does not warrant its own issue. Continuation of: https://web.archive.org/web/20220619191307/https://github.com/nsxiv/nsxiv/discussions/119
Owner

Should we keep this issue open or closed? I'm fine with either.


Removed some of the deadlinks in #242 and inlined the workarounds. Also locked the thread since I don't think anyone has any business directly writing anything there.


Any objections towards adding some static analyzers (cppcheck and clang-tidy) to our CI? I've played around a bit with them on this branch

Should we keep this issue open or closed? I'm fine with either. --- Removed some of the deadlinks in https://codeberg.org/nsxiv/nsxiv/issues/242 and inlined the workarounds. Also locked the thread since I don't think anyone has any business directly writing anything there. --- Any objections towards adding some static analyzers (cppcheck and clang-tidy) to our CI? I've played around a bit with them [on this branch](https://codeberg.org/NRK/nsxiv/src/branch/my_static_analysis)
Poster
Owner

Should we keep this issue open or closed? I'm fine with either.

I think it should stay open as we don't have pins here.

Any objections towards adding some static analyzers (cppcheck and clang-tidy) to our CI? I've played around a bit with them on this branch

Would be a nice addition. (Haven't yet checked the branch.)


Don't remember which one, but in some PR I also teased clang-format. If I recall correctly, I did set up a .clang-format file that resembles the current style as best it could. I should also open a PR with that at some point and we can discuss further there.

> Should we keep this issue open or closed? I'm fine with either. I think it should stay open as we don't have pins here. > Any objections towards adding some static analyzers (cppcheck and clang-tidy) to our CI? I've played around a bit with them [on this branch](https://codeberg.org/NRK/nsxiv/src/branch/my_static_analysis) Would be a nice addition. (Haven't yet checked the branch.) --- Don't remember which one, but in some PR I also teased `clang-format`. If I recall correctly, I did set up a `.clang-format` file that resembles the current style as best it could. I should also open a PR with that at some point and we can discuss further there.
Owner

Don't remember which one, but in some PR I also teased clang-format. If I recall correctly, I did set up a .clang-format file that resembles the current style as best it could. I should also open a PR with that at some point and we can discuss further there.

Yes, I remember that and was about to ask about it as well. However there's a couple things which I fear that the auto-fromatter might mess up. Feel free to open the PR so we can discuss it further over there.


There are also some spellcheckers which can auto-detect typos in non-code/comments. Might be worth it to set up something like that as well, though I'm personally not interested in it. But if there aren't any objections then we can open a new issue and tag it "up for grabs".

> Don't remember which one, but in some PR I also teased `clang-format`. If I recall correctly, I did set up a `.clang-format` file that resembles the current style as best it could. I should also open a PR with that at some point and we can discuss further there. Yes, I remember that and was about to ask about it as well. However there's a couple things which I fear that the auto-fromatter might mess up. Feel free to open the PR so we can discuss it further over there. --- There are also some spellcheckers which can auto-detect typos in non-code/comments. Might be worth it to set up something like that as well, though I'm personally not interested in it. But if there aren't any objections then we can open a new issue and tag it "up for grabs".
Poster
Owner

We used to use the Releases tab on GitHub. Are we not doing it here?

As we don't even release binary packages, shall we just do tags and no releases?

We used to use the *Releases* tab on GitHub. Are we not doing it here? As we don't even release binary packages, shall we just do tags and no releases?
Owner

I think we only did tags on github as well, but github would show it on the releases tab.

On codeberg, it shows up over here https://codeberg.org/nsxiv/nsxiv/tags

As we don't even release binary packages, shall we just do tags and no releases?

Not sure I follow, are we talking about github or codeberg?

I think we only did tags on github as well, but github would show it on the releases tab. On codeberg, it shows up over here https://codeberg.org/nsxiv/nsxiv/tags > As we don't even release binary packages, shall we just do tags and no releases? Not sure I follow, are we talking about github or codeberg?
Poster
Owner

I think we only did tags on github as well, but github would show it on the releases tab.

Just checked it, and yes, you are correct.

I guess I thought we had releases as GitHub shows this on the side panel:

GitHub Releases/Tags Screenshot

As we don't even release binary packages, shall we just do tags and no releases?

Not sure I follow, are we talking about github or codeberg?

Apparently I was describing exactly what we are doing.

> I think we only did tags on github as well, but github would show it on the releases tab. Just checked it, and yes, you are correct. I guess I thought we had releases as GitHub shows this on the side panel: ![GitHub Releases/Tags Screenshot](https://i.imgur.com/GUvcp7B.png) > > As we don't even release binary packages, shall we just do tags and no releases? > > Not sure I follow, are we talking about github or codeberg? Apparently I was describing exactly what we are doing.
NRK added the
discussion
label 6 months ago
Owner

Might wanna garbage collect these pulls https://github.com/nsxiv/nsxiv/pulls (can't do it myself, account still "suspended")

Also might be a good idea to make another repo, nsxiv-archive and pull in all the threads just to make sure we don't loose these discussions again due to random wipes.

EDIT: Probably want to "enable" issues and discussions before doing the "migration" and then disable them afterwards. Though I'm not sure if gitea is able to migrate "discussions" or not.

Might wanna garbage collect these pulls https://github.com/nsxiv/nsxiv/pulls (can't do it myself, account still "suspended") Also might be a good idea to make another repo, `nsxiv-archive` and pull in all the threads just to make sure we don't loose these discussions *again* due to random wipes. EDIT: Probably want to "enable" issues and discussions before doing the "migration" and then disable them afterwards. Though I'm not sure if gitea is able to migrate "discussions" or not.
Poster
Owner

Might wanna garbage collect these pulls https://github.com/nsxiv/nsxiv/pulls (can't do it myself, account still "suspended")

Done.

Also might be a good idea to make another repo, nsxiv-archive and pull in all the threads just to make sure we don't loose these discussions again due to random wipes.

Looks like the reason those appeared is that your profile is back. Weird that it's still telling you you're suspended.

EDIT: Probably want to "enable" issues and discussions before doing the "migration" and then disable them afterwards. Though I'm not sure if gitea is able to migrate "discussions" or not.

It can't migrate discussions.

> Might wanna garbage collect these pulls https://github.com/nsxiv/nsxiv/pulls (can't do it myself, account still "suspended") Done. > Also might be a good idea to make another repo, `nsxiv-archive` and pull in all the threads just to make sure we don't loose these discussions *again* due to random wipes. Looks like the reason those appeared is that your profile is back. Weird that it's still telling you you're suspended. > EDIT: Probably want to "enable" issues and discussions before doing the "migration" and then disable them afterwards. Though I'm not sure if gitea is able to migrate "discussions" or not. It can't migrate discussions.
Poster
Owner

Can't name it nsxiv-archive for some reason, so I went with nsxiv-record. Will try to rename after migration is done.

Edit: Trying to rename now gives me a 500 error.

Can't name it `nsxiv-archive` for some reason, so I went with `nsxiv-record`. Will try to rename after migration is done. Edit: Trying to rename now gives me a 500 error.
Owner

Edit: Trying to rename now gives me a 500 error.

Same here, but no matter, nsxiv-record works well enough. Probably want to disable issues on github again now that migration is done.

It can't migrate discussions.

I think the only one worth migrating was the general-dev discussion. Could try to use something like https://archive.is or https://archive.org to archive it.

> Edit: Trying to rename now gives me a 500 error. Same here, but no matter, `nsxiv-record` works well enough. Probably want to disable issues on github again now that migration is done. > It can't migrate discussions. I think the only one worth migrating was the `general-dev` discussion. Could try to use something like https://archive.is or https://archive.org to archive it.
Poster
Owner

Archived and edited it into the original comment.

Archived and edited it into [the original comment](https://codeberg.org/nsxiv/nsxiv/issues/294#issue-136545).
Poster
Owner

Assuming it's possible (I don't have access to CI), should we make running CI on PRs require approval from a maintainer?

Currently we're wasting some Codeberg resources running all our CI suite on PRs like #330.

Assuming it's possible (I don't have access to CI), should we make running CI on PRs require approval from a maintainer? Currently we're wasting some Codeberg resources running all our CI suite on PRs like #330.
Owner

Assuming it's possible (I don't have access to CI), should we make running CI on PRs require approval from a maintainer?

Currently we're wasting some Codeberg resources running all our CI suite on PRs like #330.

I've thought the same sometime before. It's possible to tell woodpecker to skip some pipelines depending on which file changed 1. So we can skip the build and analysis pipeline if none of the *.c *.h files changes.

However it's only supported for Github and Gitlab at the moment and not for Gitea.


Seems like there's an option for manual CI approval to run.

image

But I wonder if it's going be to more trouble than it's worth or not, since our CI runs are rather cheap and complete under a min-ish.

> Assuming it's possible (I don't have access to CI), should we make running CI on PRs require approval from a maintainer? > > Currently we're wasting some Codeberg resources running all our CI suite on PRs like #330. I've thought the same sometime before. It's possible to tell woodpecker to skip some pipelines depending on which file changed [^0]. So we can skip the build and analysis pipeline if none of the `*.c *.h` files changes. [^0]: https://woodpecker-ci.org/docs/usage/pipeline-syntax#path However it's only supported for Github and Gitlab at the moment and not for Gitea. --- Seems like there's an option for manual CI approval to run. ![image](/attachments/0e3f9125-27f1-4206-b338-efc9b493ba84) But I wonder if it's going be to more trouble than it's worth or not, since our CI runs are rather cheap and complete under a min-ish.
5.0 KiB
Owner

Currently we're wasting some Codeberg resources running all our CI suite on PRs like #330.

See #331 for a solution.

> Currently we're wasting some Codeberg resources running all our CI suite on PRs like #330. See #331 for a solution.
Owner

Btw, does GitHub allow changing the workflow directory location? E.g instead of .github/.... -> misc/.github/... ? Woodpecker allows you to configure the directory woodpecker looks into. So if GitHub does as well then we can unify all of the junk (ci configs, clang-format, etc) under some sort of misc dir.

Btw, does GitHub allow changing the workflow directory location? E.g instead of `.github/....` -> `misc/.github/...` ? Woodpecker allows you to configure the directory woodpecker looks into. So if GitHub does as well then we can unify all of the junk (ci configs, clang-format, etc) under some sort of `misc` dir.
Poster
Owner

Btw, does GitHub allow changing the workflow directory location?

According to the docs:

Workflows are defined in the .github/workflows directory...

It doesn't mention any configuration.

> Btw, does GitHub allow changing the workflow directory location? According to the [docs](https://docs.github.com/en/actions/using-workflows/about-workflows#about-workflows): > Workflows are defined in the .github/workflows directory... It doesn't mention any configuration.
Owner

Codeberg now supports the "allow edits by maintainer" feature. Though it doesn't seem to be ticked on by default.

Codeberg now supports the "allow edits by maintainer" feature. Though it doesn't seem to be ticked on by default.

Hello. I want to contribute to project, but I'm not a programmer myself, as you might already know. I can translate something into Ukrainian, maybe translate all of the docs? Do you need it?

Hello. I want to contribute to project, but I'm not a programmer myself, as you might already know. I can translate something into Ukrainian, maybe translate all of the docs? Do you need it?

Hello. I want to contribute to project, but I'm not a programmer myself, as you might already know. I can translate something into Ukrainian, maybe translate all of the docs? Do you need it?

I think this can be debated and maybe add some translations.

Adding them on the website could easily be the first step, if there is appeal for this.

The discussion would be adding them in the repo as a man page, which requires additional files into the repo. since there is etc/ maybe this can be afforted.

I think translations has been discussed before but I cannot find the issue.

ping @NRK @eylles

> Hello. I want to contribute to project, but I'm not a programmer myself, as you might already know. I can translate something into Ukrainian, maybe translate all of the docs? Do you need it? I think this can be debated and maybe add some translations. Adding them on the website could easily be the first step, if there is appeal for this. The discussion would be adding them in the repo as a man page, which requires additional files into the repo. since there is `etc/` maybe this can be afforted. I think translations has been discussed before but I cannot find the issue. ping @NRK @eylles
Owner

I think translations has been discussed before but I cannot find the issue.

Yes, I remember too, but it was on the "github discussion" tabs, so it's not available anymore.


But to repeat what I said back then: Adding translation would add significant overhead for the maintainers:

  • The same document needs to be maintained in different languages.
  • We may not have a maintainer that knows the language in order to maintain/review the translation.
  • The documentation might change, which means that all the translation will become outdated - unless we keep the code and all translation in sync.
  • This also adds significant overhead for other people who are trying to contribute a feature but don't know X language to update it's docs.

For these reasons, I'd vote no for having translations. The cost is just too high for little value (since there are automatic translators available, e.g google translate, which do a good enough job).

> I think translations has been discussed before but I cannot find the issue. Yes, I remember too, but it was on the "github discussion" tabs, so it's not available anymore. - - - But to repeat what I said back then: Adding translation would add significant overhead for the maintainers: * The same document needs to be maintained in different languages. * We may not have a maintainer that knows the language in order to maintain/review the translation. * The documentation might change, which means that *all* the translation will become outdated - unless we keep the code and *all* translation in sync. * This also adds significant overhead for *other* people who are trying to contribute a feature but don't know X language to update it's docs. For these reasons, I'd vote no for having translations. The cost is just too high for little value (since there are automatic translators available, e.g google translate, which do a *good enough* job).

some proyects use a chart representing the languages (eng, es, it, fr, ...) and the quality (0-100%) of the translations.

I think nsxiv is too simple to have translations, in that manner given the 'new' options that nsxiv has over sxiv I would argue that translations can be helpful. I may add that the man page isn't as complex as man git or man sshd.

If there is enough interest/traffic in this then I think we can roll something similar to nsxiv-patches, being community maintained (not in the maintainers hand) and if so only in the website.

some proyects use a chart representing the languages (eng, es, it, fr, ...) and the quality (0-100%) of the translations. I think nsxiv is too simple to have translations, in that manner given the 'new' options that nsxiv has over sxiv I would argue that translations can be helpful. I may add that the man page isn't as complex as `man git` or `man sshd`. If there is enough interest/traffic in this then I think we can roll something similar to `nsxiv-patches`, being community maintained (not in the maintainers hand) and if so only in the website.
Sign in to join this conversation.
No Milestone
No Assignees
4 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: nsxiv/nsxiv#294
Loading…
There is no content yet.