Move project from sourceforge to codeberg #408

kollo commented 2021年03月03日 13:28:13 +01:00

I have moved the sources of my projects to codeberg already. All fine. But I also like to move the rest, which is currently and has been for a very long time hosted on sourceforge, also to codeberg.

However, some features are missing. What I would need is:

1. a forum for discussions (for users of the software, not developpers, so not siutable for an issue tracker),

2. a sort of blog (for the news about the repository),

3. a per-repository web page. Also see issue #218 and #371. (maybe per organization would do),

4. some feedback options like reviews (0 to 5 stars or so, could be handled by a dynamical web page) this is minor important because we have the "Favorit" feature,

5. A storage place for binary distribution packages, like .deb packages, .apk files etc. It would be great (but not necessary) if they would be build automatically from the sources.

I know that these topics are currently under discussions at codeberg, and that codeberg.pages at least support web pages on a per "Organisation" basis. But having solved this, would make me and probably others moving completely to codeberg.

In promoting codeberg, I would also state, that one of the biggest features of codeberg is german law. No patriot-act, cryptography is not forbidden, no export restrictions, etc...

I have moved the sources of my projects to codeberg already. All fine. But I also like to move the rest, which is currently and has been for a very long time hosted on sourceforge, also to codeberg. However, some features are missing. What I would need is: 1. a forum for discussions (for users of the software, not developpers, so not siutable for an issue tracker), 2. a sort of blog (for the news about the repository), 3. a per-repository web page. Also see issue #218 and #371. (maybe per organization would do), 4. some feedback options like reviews (0 to 5 stars or so, could be handled by a dynamical web page) this is minor important because we have the "Favorit" feature, 5. A storage place for binary distribution packages, like .deb packages, .apk files etc. It would be great (but not necessary) if they would be build automatically from the sources. I know that these topics are currently under discussions at codeberg, and that codeberg.pages at least support web pages on a per "Organisation" basis. But having solved this, would make me and probably others moving completely to codeberg. In promoting codeberg, I would also state, that one of the biggest features of codeberg is german law. No patriot-act, cryptography is not forbidden, no export restrictions, etc...

6543 commented 2021年03月03日 16:24:15 +01:00

To 5.: we have release assets

1.: a codeberg matrix server is currently in discusion ...

To 5.: we have release assets 1.: a codeberg matrix server is currently in discusion ...

kollo commented 2021年03月03日 16:37:45 +01:00

Sounds good. Can someone point me to instructions on how to use the release assets?

Sounds good. Can someone point me to instructions on how to use the release assets?

fnetX commented 2021年03月03日 17:23:46 +01:00

Can someone point me to instructions on how to use the release assets?

In your project, go to the release tab and add a new release. You are allowed to upload files there.

Thank you very much for your feedback.

> Can someone point me to instructions on how to use the release assets? In your project, go to the release tab and add a new release. You are allowed to upload files there. Thank you very much for your feedback.

kollo commented 2021年03月03日 17:59:48 +01:00

Thank you!

I have tested it. Probably I need to get used to it, but it seems to have worked. However the user experience is different. Maybe I need to create my own dowload page on the Projects homepage referencing the most recent release.... Hm...

Usually I have made debian packages for 64bit and also 32 bit for each release (tagged in the commits). SOmetimes I also compile a WINDOWS setup.exe, but not for each tagged release, because I am lazy and the compiling process takes time.

How do others handle this? Is there a best practice?

For reference, my test is here:
https://codeberg.org/kollo/X11Basic/releases

Thank you! I have tested it. Probably I need to get used to it, but it seems to have worked. However the user experience is different. Maybe I need to create my own dowload page on the Projects homepage referencing the most recent release.... Hm... Usually I have made debian packages for 64bit and also 32 bit for each release (tagged in the commits). SOmetimes I also compile a WINDOWS setup.exe, but not for each tagged release, because I am lazy and the compiling process takes time. How do others handle this? Is there a best practice? For reference, my test is here: https://codeberg.org/kollo/X11Basic/releases

fnetX commented 2021年03月03日 18:07:14 +01:00

by the way, it is in the docs, but a bit tricky to find under "citable code" ...

I can't say anything about this in practice, I'm sorry. I'm usually contributor to FLOSS projects, haven't maintained something with releases yet.

You could add a link to a release which hasn't got complete assets linking to an older one which has. Just as an idea.

by the way, it *is* in the docs, but a bit tricky to find under "[citable code](https://docs.codeberg.org/collaborating/citable-code/)" ... I can't say anything about this in practice, I'm sorry. I'm usually contributor to FLOSS projects, haven't maintained something with releases yet. You could add a link to a release which hasn't got complete assets linking to an older one which has. Just as an idea.

kollo commented 2021年03月03日 18:33:25 +01:00

Looking at the link (citable code) I have the impression, that the use case for these releases is different. It is made to download a specific snapshot of the code, or reference a specific commit. That is reasonnable. But al though one can add binary files here, I do not think that the feature was adapted to binary distributions, at least not in the way this is usually done.

Ususally means: Have a folder for each of the platform (linux, android, windows) and inside the packages (.deb, .apk, setup.exe) for different version-releases, the most recent ones on the top.
At least this is what I originally expected.

However this could come handy if the compile process is fully automated such that always all platforms are served. (Is this what is commonly referred as CI-Integration? Unfortunately I do not have experience with this other that e.g. f-droid handle this automatically).

Maybe it is just a matter of documentation of the "pest practice use" of that feature.

Looking at the link (citable code) I have the impression, that the use case for these releases is different. It is made to download a specific snapshot of the code, or reference a specific commit. That is reasonnable. But al though one can add binary files here, I do not think that the feature was adapted to binary distributions, at least not in the way this is usually done. Ususally means: Have a folder for each of the platform (linux, android, windows) and inside the packages (.deb, .apk, setup.exe) for different version-releases, the most recent ones on the top. At least this is what I originally expected. However this could come handy if the compile process is fully automated such that always all platforms are served. (Is this what is commonly referred as CI-Integration? Unfortunately I do not have experience with this other that e.g. f-droid handle this automatically). Maybe it is just a matter of documentation of the "pest practice use" of that feature.

kollo commented 2021年03月03日 18:38:38 +01:00

Found an obstacle: I cannot create two different releases for the same tag. (I wanted to have 1.27-59 debian 32bit and another 1.27-59 windows). I must make a common release for both platforms. I can add two files, but the name cannot reflect the platform individually.

Maybe the release feature is fine for small projects which only support a single platform. I think I could use it on some of my other repositories.

Found an obstacle: I cannot create two different releases for the same tag. (I wanted to have 1.27-59 debian 32bit and another 1.27-59 windows). I must make a common release for both platforms. I can add two files, but the name cannot reflect the platform individually. Maybe the release feature is fine for small projects which only support a single platform. I think I could use it on some of my other repositories.

fnetX commented 2021年03月03日 19:04:28 +01:00

Well, the usecase for the releases is (as you mentioned) to provide a snapshot of the code with all the files for all platforms. People will see a new release and select their platform, rather than selecting their platform and the release.

Codeberg hasn't got that many projects using release assets yet, but have a look at some projects over at GitHub, like Go-Mail-Admin or Caddy for example. You'll see that you can look at the version and what changed and decide whether you want to go for stable or the next release candidates etc and then select your download file accordingly.

Gitea is kinda more like GitHub as a platform, so many things will be strange when moving from more traditional websites like sourceforge, launchpad etc.

Well, the usecase for the releases is (as you mentioned) to provide a snapshot of the code with all the files for all platforms. People will see a new release and select their platform, rather than selecting their platform and the release. Codeberg hasn't got that many projects using release assets yet, but have a look at some projects over at GitHub, like [Go-Mail-Admin](https://github.com/kekskurse/go-mail-admin/releases) or [Caddy](https://github.com/caddyserver/caddy/releases) for example. You'll see that you can look at the version and what changed and decide whether you want to go for stable or the next release candidates etc and then select your download file accordingly. Gitea is kinda more like GitHub as a platform, so many things will be strange when moving from more traditional websites like sourceforge, launchpad etc.

fnetX commented 2021年03月03日 19:12:14 +01:00

To extend to your original list:

a sort of blog

Many repos actually use the releases like a blog, at least for the stuff directly related to the product (not for things like "we had a dev meeting" though). AFAICT there's no way to subscribe to releases on Gitea yet, that's a feature that might be missing ...

a forum for discussions

I've seen many projects use an issue tracker as forum still, but in a separate repository. If you have an organization, you could create a "Forum" or "Discussion" repo and use this issue tracker. I think this is well enough for most purposes and has the advantage that you can a) stick to the very same platform, no need to get used to a new UI and different features and b)refer issues in discussion threads and vice versa.

Note that you can also link an external issue tracker, this comes in handy if you think you need an external tool (which provides differnt features, or you develop on multiple platforms) or if you want multiple repositories (like frontend, backend, helper-tools, library-xy) to share the same issue tracker.

To extend to your original list: > a sort of blog Many repos actually use the releases like a blog, at least for the stuff directly related to the product (not for things like "we had a dev meeting" though). AFAICT there's no way to subscribe to releases on Gitea yet, that's a feature that might be missing ... > a forum for discussions I've seen many projects use an issue tracker as forum still, but in a separate repository. If you have an organization, you could create a "Forum" or "Discussion" repo and use this issue tracker. I think this is well enough for most purposes and has the advantage that you can a) stick to the very same platform, no need to get used to a new UI and different features and b)refer issues in discussion threads and vice versa. Note that you can also link an external issue tracker, this comes in handy if you think you need an external tool (which provides differnt features, or you develop on multiple platforms) or if you want multiple repositories (like frontend, backend, helper-tools, library-xy) to share the same issue tracker.

kollo commented 2021年03月03日 19:37:00 +01:00

Hm, Ok. I see. One could paste the release notes into the text area of a release. But "news" is different. F.ex. I announced the new location of the source code repositories under "news". This is not related to any release.

I have not used organizations so far, but for X11-Basic (with many flavours) it is probably worth creating one. I hope, the URLs will not change if I move the repositories into the organization. Lets see. i think I need to simply try. As far as I have understood, an organization is a group of devellopers maintaining a group of repositories which belong together. So instead of the username, the repositories are grouped under the organizations name.

A forum usually has different sections (e.g. Help, Installation, compiling, example programs, offtopic, etc...) Would I need a separate repository inside the organization to have separate issues for this? I Know, the philosophy here is more like using labels.

Hm, Ok. I see. One could paste the release notes into the text area of a release. But "news" is different. F.ex. I announced the new location of the source code repositories under "news". This is not related to any release. I have not used organizations so far, but for X11-Basic (with many flavours) it is probably worth creating one. I hope, the URLs will not change if I move the repositories into the organization. Lets see. i think I need to simply try. As far as I have understood, an organization is a group of devellopers maintaining a group of repositories which belong together. So instead of the username, the repositories are grouped under the organizations name. A forum usually has different sections (e.g. Help, Installation, compiling, example programs, offtopic, etc...) Would I need a separate repository inside the organization to have separate issues for this? I Know, the philosophy here is more like using labels.

kollo commented 2021年03月03日 20:00:41 +01:00

I have played around some more with the releases. At least for MQTT-Hyperdash this was quite handy https://codeberg.org/kollo/MQTT-Hyperdash/releases so I now can get rid of the corresponding sourceforge project (was used only to provide the binary deb packages).

I have played around some more with the releases. At least for MQTT-Hyperdash this was quite handy https://codeberg.org/kollo/MQTT-Hyperdash/releases so I now can get rid of the corresponding sourceforge project (was used only to provide the binary deb packages).

fnetX commented 2021年03月03日 20:33:11 +01:00

For sure, an issue tracker is not a fully-featured replacement for forums. But I simply believe that we do not need to reinvent the wheel again.

We'll most likely provide a Chat / Channel solution (→Matrix) and while it's of course possible to discuss about a forum feature in Gitea or hosting something like a public Discourse for Codeberg member, I think this is something projects should probably do by themselves if they really need to.

Also, in my experience, those forums are usually places where people hesitate to register to, since they don't want to bother with yet-another-platform. And even the new GitHub Discussions feature (which is essentially a forum in addition to the issue tracker) seems to confuse people so far. They post requests there first which are then copied into issues, and they post issues which are then closed in favor of forum threads. And some users don't notice the new tab at all ^^

So my proposal here: Let's check if the current (and planned) features work for you and / or everyone else and see what's really missing. We can of course discuss at any time about what we should change / add.

Thank you for your feedback so far.

PS: Blogging can of course being done with the Codeberg pages feature. There are plenty of static site generators out there so far, many of them being as lightweight as saving a markdown file and running a command. Even the Codeberg Docs are deployed via Codeberg pages :-)
I recommend you try this out for an organization or create your personal blog with a folder per project (or mix them all together or whatever fits your style ✌️)

For sure, an issue tracker is not a fully-featured replacement for forums. But I simply believe that we do not need to reinvent the wheel again. We'll most likely provide a Chat / Channel solution (→Matrix) and while it's of course possible to discuss about a forum feature in Gitea or hosting something like a public Discourse for Codeberg member, I think this is something projects should probably do by themselves if they really need to. Also, in my experience, those forums are usually places where people hesitate to register to, since they don't want to bother with yet-another-platform. And even the new GitHub Discussions feature (which is essentially a forum in addition to the issue tracker) seems to confuse people so far. They post requests there first which are then copied into issues, and they post issues which are then closed in favor of forum threads. And some users don't notice the new tab at all ^^ So my proposal here: Let's check if the current (and planned) features work for you and / or everyone else and see what's really missing. We can of course discuss at any time about what we should change / add. Thank you for your feedback so far. PS: Blogging can of course being done with the Codeberg pages feature. There are plenty of static site generators out there so far, many of them being as lightweight as saving a markdown file and running a command. Even the Codeberg Docs are deployed via Codeberg pages :-) I recommend you try this out for an organization or create your personal blog with a folder per project (or mix them all together or whatever fits your style :v:)

hw commented 2021年03月03日 22:15:48 +01:00

2. a sort of blog (for the news about the repository),

Have you seen https://codeberg.page yet? (content can get generated with any static website generation tool, Hugo etc, for https://blog.codeberg.org we are using pelican).

3. a per-repository web page. Also see issue #218 and #371. (maybe per organization would do),

Pages repos can be per-organization.

4. some feedback options like reviews (0 to 5 stars or so, could be handled by a dynamical web page) this is minor important because we have the "Favorit" feature,

Currently stars are binary only.

5. A storage place for binary distribution packages, like .deb packages, .apk files etc. It would be great (but not necessary) if they would be build automatically from the sources.

Releases are discussed above, of course pages repos can get "abused" for less constrained content. If you do so, please keep in mind that git keeps a history, please properly remove unused binary blobs when they are becoming large (prune them from history).

I know that these topics are currently under discussions at codeberg, and that codeberg.pages at least support web pages on a per "Organisation" basis. But having solved this, would make me and probably others moving completely to codeberg.

Every feedback welcome!

> 2. a sort of blog (for the news about the repository), Have you seen https://codeberg.page yet? (content can get generated with any static website generation tool, Hugo etc, for https://blog.codeberg.org we are using pelican). > 3. a per-repository web page. Also see issue #218 and #371. (maybe per organization would do), Pages repos can be per-organization. > 4. some feedback options like reviews (0 to 5 stars or so, could be handled by a dynamical web page) this is minor important because we have the "Favorit" feature, Currently stars are binary only. > 5. A storage place for binary distribution packages, like .deb packages, .apk files etc. It would be great (but not necessary) if they would be build automatically from the sources. Releases are discussed above, of course pages repos can get "abused" for less constrained content. If you do so, please keep in mind that git keeps a history, please properly remove unused binary blobs when they are becoming large (prune them from history). > I know that these topics are currently under discussions at codeberg, and that codeberg.pages at least support web pages on a per "Organisation" basis. But having solved this, would make me and probably others moving completely to codeberg. Every feedback welcome!

kollo commented 2021年03月04日 08:04:09 +01:00

Well Ok, thank you for showing me the options. I think some of it will resolve once I have learned to use the codeberg.pages. Lets see how it turns out. I am open to new stuff, so maybe one need not stick too much with the old methods. Forum and Wiki was the thing 15 years ago. Wiki also used to be great back then (the time wikipedia launched). I remember the opentom tom wiki, which was quite active.
But all has gone long ago.

Sourceforge also used to be great and state of the art -- in 2002.
But today it is hardly a ghost of what it once was.
Most of it (concerning code developpment) converged to git. Thats
OK.

However I have some doubts using the matrix server/channel for user interaction. I have not the time to be online 24/7. And having everything in one single timeline .... I think offline communication is better. But I'll give it a try.

Well Ok, thank you for showing me the options. I think some of it will resolve once I have learned to use the codeberg.pages. Lets see how it turns out. I am open to new stuff, so maybe one need not stick too much with the old methods. Forum and Wiki was the thing 15 years ago. Wiki also used to be great back then (the time wikipedia launched). I remember the opentom tom wiki, which was quite active. But all has gone long ago. Sourceforge also used to be great and state of the art -- in 2002. But today it is hardly a ghost of what it once was. Most of it (concerning code developpment) converged to git. Thats OK. However I have some doubts using the matrix server/channel for user interaction. I have not the time to be online 24/7. And having everything in one single timeline .... I think offline communication is better. But I'll give it a try.

hw commented 2021年03月04日 10:43:55 +01:00

project wikis are enabled in the project settings tab.

project wikis are enabled in the project settings tab.

kollo commented 2021年03月05日 08:56:41 +01:00

Some feedback to this from my side today:

Now that I have created a codeberg.page and an organization for my project, I am quite happy with that.

• The Homepage could be reproduced, having it generated simply from files in a repository is fine, keeping the histary, also fine (if not wanted one can force-push to clear the history. I do not expect anybody to fork or clone the pages repo).

• Having the "distribution files" from sourcefoge in the release assets looks OK to me. However there are some points which I have to get used to (and also the users of the software). But It is not too bad and one probably can live with that. (the feature: "subscription to releases" would be good.)

• A blog is not essential, can be realized with some page generator, however new entries would be barried under a lot of other technical stuff in the timeline of the projects activity. Wikis, I think, are a thing from the past and probably not really needed.

What is left: I have no good solution for the "user forum" or say "discussion" replacement yet. But I will give the matrix chat a try, and maybe create another repository where the issue tracker can be used. Instead of forum categories, labels can be used. That issues can be closed might be a very good feature, thats a downside of the forum as it is now.

There is no feedback solution, rating or ranking of the Software. I know that this is not essential, but I am (maybe like many others) a bit narcistic or competitive or like to have the quality of the software recognized. Hw shall good software be identified?

Some feedback to this from my side today: Now that I have created a codeberg.page and an organization for my project, I am quite happy with that. * The Homepage could be reproduced, having it generated simply from files in a repository is fine, keeping the histary, also fine (if not wanted one can force-push to clear the history. I do not expect anybody to fork or clone the pages repo). * Having the "distribution files" from sourcefoge in the release assets looks OK to me. However there are some points which I have to get used to (and also the users of the software). But It is not too bad and one probably can live with that. (the feature: "subscription to releases" would be good.) * A blog is not essential, can be realized with some page generator, however new entries would be barried under a lot of other technical stuff in the timeline of the projects activity. Wikis, I think, are a thing from the past and probably not really needed. What is left: I have no good solution for the "user forum" or say "discussion" replacement yet. But I will give the matrix chat a try, and maybe create another repository where the issue tracker can be used. Instead of forum categories, labels can be used. That issues can be closed might be a very good feature, thats a downside of the forum as it is now. There is no feedback solution, rating or ranking of the Software. I know that this is not essential, but I am (maybe like many others) a bit narcistic or competitive or like to have the quality of the software recognized. Hw shall good software be identified?

6543 commented 2021年05月16日 01:49:46 +02:00

@Tealk CI is comming, just not time when :D -> #78, #428

@Tealk CI is comming, just not time when :D -> #78, #428

Tealk commented 2021年05月16日 01:51:24 +02:00

@Tealk CI is comming, just not time when :D -> #78, #428

Thanks, I was just about to open a separate issue and ask if there are any external providers.
Because I want to continue to publish the whole thing under the known domain.

Is there an external service that can do this?

> @Tealk CI is comming, just not time when :D -> #78, #428 Thanks, I was just about to open a separate issue and ask if there are any external providers. Because I want to continue to publish the whole thing under the known domain. Is there an external service that can do this?

fnetX commented 2021年06月09日 22:24:14 +02:00

Is there something left for the docs, actually? I guess I added the label about the "Releases" part, but that's already documented. Tell me if I missed something, otherwise I'll close this some day.

Is there something left for the docs, actually? I guess I added the label about the "Releases" part, but that's already documented. Tell me if I missed something, otherwise I'll close this some day.

kollo commented 2021年06月10日 07:54:30 +02:00

Well, I have still not completely moved. I have douplicated the WEB-Page, put the files into the releases (got used to the new structure here). But I have still no place for the discussion/forum, the news section and user rating/feedback. I dont see this as urgent, however, the forum is of concern. I have tried matix (unstructured chat) and this seems not to be usful, at least no good replace for a forum. Matrix is maybe like twitter or Watsapp. I have never used these. There is a test running using a discussion sub-repository. The idea is to use the issue section for discussions. Technically this seems OK to me, but the user acceptance was zero (however I have only very few contributors to discussions anyways). However, I am looking forward to continous integration and automatic build and deploy processes in codeberg.

And finally: srangely enough there seems no way to delete a project from sourceforge (not your problem), hm...

Well, I have still not completely moved. I have douplicated the WEB-Page, put the files into the releases (got used to the new structure here). But I have still no place for the discussion/forum, the news section and user rating/feedback. I dont see this as urgent, however, the forum is of concern. I have tried matix (unstructured chat) and this seems not to be usful, at least no good replace for a forum. Matrix is maybe like twitter or Watsapp. I have never used these. There is a test running using a discussion sub-repository. The idea is to use the issue section for discussions. Technically this seems OK to me, but the user acceptance was zero (however I have only very few contributors to discussions anyways). However, I am looking forward to continous integration and automatic build and deploy processes in codeberg. And finally: srangely enough there seems no way to delete a project from sourceforge (not your problem), hm...