Clarify where stuff happens #291
Comments
|
Thanks for pointing these issues out. The git repos have changed over time but not all web page references where correctly updated. https://wiki.gnome.org/Apps/Smuxi is not really obsolete, because the Smuxi website does not have a public wiki and there are designs that Smuxi hasn't implemented yet, so that content is still relevant. I just tried to update the wiki page to clarify the repo location but it says the page is immutable :/ The canonical git repo is this one on GitHub. All codes changes are also pushed to gitlab.gnome.org, but also used as translation source for translations that are contributed and pushed directly by language teams in GNOME. In addition to the GNOME translations there are languages that have teams on Transifex, the po files reflect that: Behind https://smuxi.im/repositories/show/smuxi is git.qnetp.net which was the first git repo before the canonical repo was moved over to GitHub but then kept as a mirror. It is now redundant because gitlab.gnome.org is already a mirror in case anything bad happens to the GitHub repo (it is a commercial service after all so I don't want to fully rely on it). I changed https://smuxi.im/repositories/show/smuxi to redirect to this GitHub repo to clear this confusion. So translations are pulled from 2 different sources: GNOME and Transifex. The translations are merged back into the GitHub repo from time to time, usually before a release so that all translations are part of releases. Since the last release in February this year, 1 language has been updated (Slovenian) in the gitlab.gnome.org repo, which I just merged. Hope this clears some things up! I wonder how we can get the repo location fixed on https://wiki.gnome.org/Apps/Smuxi any pointers? |
Sorry, but this is not going to work. If a team from GNOME is caring for smuxy translations, they don't want that suddenly a different team may overwrite their work, or contribute with different rules (glossary, conventions, etc.). And I guess the reverse might also be true. And there is always the possibility teams from both sources work in parallel, which will be time wasting. So sorry again, but you will have to make a choice. If you keep merging translations from Transifex, then we'll remove smuxi from l10n.gnome.org. |
|
@meebey: Hi, could you please make a choice? Thanks a lot in advance. |
|
As there has not been a reply by @meebey, I propose to archive https://gitlab.gnome.org/GNOME/smuxi/ and archive https://l10n.gnome.org/module/smuxi/ , and to replace content on https://wiki.gnome.org/Apps/Smuxi and https://wiki.gnome.org/Apps/Smuxi/Design etc by a link to https://smuxi.im/ instead. |
|
@aklapper we have reviewed the translation situation of the Smuxi project and will no longer import translations from Transifex, but GNOME-only as these are the native and active translation groups. Smuxi is free software for the GNOME desktop from the start on and adheres to all GNOME standards. The Transifex integration has been removed from the source tree in 9c30bf2 |
|
@aklapper the only outstanding part I see is that I want to update the links on the https://wiki.gnome.org/Apps/Smuxi page to be consistent with what was clarified here but the wiki does not let me. Do you know whom I need to reach out to to get the needed write permissions? GNOME sysadmin team perhaps? |
|
You need to be added to https://wiki.gnome.org/TrustedEditorGroup |
|
@afranke it is "MircoBauer" |
|
You should now be able to edit. |
|
@afranke that did trhe trick, thanks! So I have updated the links and removed the outdated part regarding Transifex translations. Should be all correct now. |
|
https://smuxi.im/contribute/ is still mentioning Transifex as the tool to translate Smuxi. |
|
@claudep good catch, fixed: meebey/smuxi-web@3ddbfcd |
|
👍 |
|
https://smuxi.im/documentation/hacking/ points at github for cloning, while https://wiki.gnome.org/Apps/Smuxi claims the repository is at GNOME gitlab. |
|
@afranke oopsy, updated Apps/Smuxi with clarification as well. 👍 |
|
Sorry about the mess, over the decades things have changed and some pieces got updated while others haven't.... Thanks for pointing out the inconsistencies, appreciated! |
|
There is an issue tracker at https://smuxi.im/issues . There is an issue tracker at https://github.com/meebey/smuxi/issues/ . There is an issue tracker at https://gitlab.gnome.org/GNOME/smuxi/-/issues Please define one issue tracker, disable other issue trackers, and check the docs to link to that one issue tracker. Thanks. |
|
This ticket should remain open until things have been clarified. |
|
There also still two repositories: Github and GNOME Gitlab. The later is labelled mirror on the wiki page, but Damned lies is still directed at it. That doesn’t work, translators should working against the canonical repository. (Having a read-only mirror is fine and out of scope here). @claudep would Damned Lies be able to commit to Github, if Mirco decides to keep it as the canonical one? |
Only direct commits to Git repos is supported currently by Damned Lies, not through pull requests. So in theory it would be possible to commit to GitHub, but without the safeguards GNOME GitLab has in place to limit the scope of automatic Damned Lies commits, it is a bit risky. |
|
Good point about the different issue trackers. Redmine is the defacto canonical tracker (was used early on) but it has a barrier for people to use so I accept reports via GitHub as well. This open issue is a good example of the better UX, as no additional account is required with the Smuxi project. The GNOME GitLab issue tracker is now disabled, this one was redundant. Regarding the git repo, the GNOME one is the canonical one in the context of translations. All GNOME devs and translators have direct write access to it to submit contributions. So for DamnLies I guess it is correct to point it to the GNOME gitlab repo. |
|
We don’t work off mirrors. I made that clear in #291 (comment) The situation as I’m writing this, for anyone reading this in the future, is that the repo on GitHub hasn’t seen any activity for the past 8 months while translations have kept coming to the GNOME GitLab repo. I’m putting an end to this madness: the module has been archived on Damned Lies and we won’t be providing translations anymore. |
|
+1 the most sensible things to do for now. |
|
+1. Thank you, afranke. |
I am not sure why my statement above is seen as git.gnome.org is a mirror of github.com/smuxi which it is not. git allows branches and work to co-exist in different places where you keep merging over time. Thinking about this, is the concern that the source code of git.gnome.org is behind github.com/meebey/smuxi for some time? I tend to "fetch gnome, merge gnome, push *" when I prepare release candidates so a few weeks before the actual release to give translators time. |
|
Actually, looking at my .git/config, I continously push to both git repos: [remote "origin"] Thus the source code of git.gnome.org is never behind... What is behind is are the translations on github.com/meebey/smuxi (transitively till I prepare a new release candidate) but why would be that a problem if GNOME treats git.gnome.org as the canoncial source of translations which we previously agreed on? I value the work of the GNOME translation team a lot, so I want to spot the issue and fix it. |
|
Maybe I miss something but would DamnedLies pointing to git.gnome.org/GNOME/smuxi to use it as the canonical repo resolve the matter? So this GitHub repo is mostly just for release preparation (GH actions, etc) and issue tracking? |
|
For the records, "git.gnome.org" has not existed for a few years.
To put it simple: If you want to use GNOME infrastructure, then I'd expect the issue tracker, code repository, translation workflow to use GNOME infrastructure. Anything else creates fragmentation and duplicated efforts.
Please see the first sentence in #291 (comment) |
|
For the record: Smuxi has been a GNOME git repo since 2014 till 2024 when @afranke decided to archive it. $ git log | grep -B 2 -i "'gnome/master'" -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- |
|
The idea of a single git repo is not secure in my book, as my https://github.com/meebey/smuxi repo or GitHub altogether (in theory, at least) could go down or disappear. Thus, Smuxi always had more than 2 git repos to address single-points-of-failure risk. With GNOME/Infrastructure#1321 the GNOME repository is no longer available to push updates to it. |
|
Sure, however GNOME GitLab is not a public free backup service for GitHub repositories. |
The current situation is quite confusing, and I would even call it broken.
Website
https://smuxi.im/ exists and seems actively maintained (let’s ignore the 2004-2016 copyright notice in the footer). https://wiki.gnome.org/Apps/Smuxi also exists. @aklapper attempted to fix it a bit, but apart from that it had not seen any update since 2014.
If you consider the wiki page obsolete, can you please make a clear statement about it so we change it to redirect people to the right place with up to date information?
Repository
There is this Github repository right here, which seems to be the most current. Then there is the GNOME Gitlab repository which does not have the latest code changes, but has relatively recent activity (from earlier this year). And finally the wiki page gives us https://smuxi.im/repositories/show/smuxi which seems to be lagging a bit behind the Gitlab repo.
Having outdated mirrors is bad enough, especially if they don’t advertise the canonical one, but the Gitlab repo and the Github one have even diverged now. There are recent code commits in Github that are not in Gitlab, and there are translation updates in Gitlab that are not in Github.
Please fix this.
Translations
The website directs at Transifex, but smuxi is also present on Damned lies. The git history shows commits from Damned lies contributors, even as recent as last January, but as I said above the latest ones have not made their way to Github.
If you intend to keep Transifex and stop taking DL contributions (which would be in line with the repository being here and not on GNOME Gitlab), then please state it explicitely so we can remove the module from DL and avoid wasting translator effort.
The text was updated successfully, but these errors were encountered: