Move away from Google, Sourceforge and Launchpad

106 views
Skip to first unread message

Justin Zobel

unread,
Aug 18, 2025, 3:37:10 AMAug 18
to hugin and other free panoramic software
Google is a privacy nightmare
Sourceforge is covered in ads
Launchpad is tied to Canonical and coproate interests.

All three can be easily replaced by Codeberg, open, free, no ads, privacy respecting.

David W. Jones

unread,
Aug 18, 2025, 4:34:16 AMAug 18
to hugi...@googlegroups.com
Interesting. Neither Google, Sourceforge, or Launchpad are spamming an application user email list begging *developers* to switch to their platforms.

Justin, is this just you acting on your own, or is this the kind of "marketing" Codeberg does?

--
David W. Jones
gnome...@gmail.com
exploring the landscape of god
http://dancingtreefrog.com

Sent from my Android device with F/LOSS K-9 Mail.

Bruno Postle

unread,
Aug 18, 2025, 10:41:05 AMAug 18
to hugin and other free panoramic software
Yes, sourceforge and launchpad are not ideal, and I would like to move away from Google groups, but I don't see a good alternative for free mailing-list/discussion.

I do think it is about time Hugin/panotools switched to git. There is a lot to like about mercurial, but git won. Also switching to git would make migration away from sourceforge easier if that needed to happen.

-- 
Bruno

dudek53

unread,
Aug 18, 2025, 10:49:42 AMAug 18
to hugi...@googlegroups.com
+ 1 on git.

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhiRJ2Y8Yft5wvBmism_Jh%3DnZXXz_TJhfZsx%3D1SdML7fw%40mail.gmail.com.

David W. Jones

unread,
Aug 18, 2025, 2:49:50 PMAug 18
to hugi...@googlegroups.com
Hmm, i think the yoshimi list uses a non-Google free email list service, I forget which, will have to check on my desktop.

On August 18, 2025 4:40:40 AM HST, Bruno Postle <br...@postle.net> wrote:
> Yes, sourceforge and launchpad are not ideal, and I would like to move away
> from Google groups, but I don't see a good alternative for free
> mailing-list/discussion.
>
> I do think it is about time Hugin/panotools switched to git. There is a lot
> to like about mercurial, but git won. Also switching to git would make
> migration away from sourceforge easier if that needed to happen.
>


--

David W. Jones

unread,
Aug 18, 2025, 10:09:51 PMAug 18
to hugi...@googlegroups.com
The Yoshimi list uses freelists.org. Maybe that's an option for the
Hugin email list?

On 8/18/25 08:49, David W. Jones wrote:
> Hmm, i think the yoshimi list uses a non-Google free email list service, I forget which, will have to check on my desktop.
>
> On August 18, 2025 4:40:40 AM HST, Bruno Postle <br...@postle.net> wrote:
>> Yes, sourceforge and launchpad are not ideal, and I would like to move away
>> from Google groups, but I don't see a good alternative for free
>> mailing-list/discussion.
>>
>> I do think it is about time Hugin/panotools switched to git. There is a lot
>> to like about mercurial, but git won. Also switching to git would make
>> migration away from sourceforge easier if that needed to happen.
>>

--
David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com
My password is the last 8 digits of π.

wirz

unread,
Aug 25, 2025, 4:28:03 PMAug 25
to hugi...@googlegroups.com

> I do think it is about time Hugin/panotools switched to git. There is a lot
> to like about mercurial, but git won. Also switching to git would make
> migration away from sourceforge easier if that needed to happen.

Yes, git would be an improvement, and I'm pretty sure there is no
downside other than the one-time work of switching. I'm not saying that
isn't work of course.

What would have an even higher benefit to me would be to use a platform
where patches can be contributed through pull requests or similar,
instead of uploading patches as single files / zipped collections of
files. And the notifications on launchpad seem to be broken -- I'm
seeing that in both directions, which makes it less attractive to
contrib patches, etc. I'd probably do more if it were simpler.

But I think github should serve as a cautionary tale: I have perceived
them as beyond any doubt 10 years ago, while now I perceive github
mostly as a tool for Microsoft to collect LLM training material.

cheers, Lukas Wirz

Justin Zobel

unread,
Aug 25, 2025, 10:36:57 PMAug 25
to hugi...@googlegroups.com
On 26/8/25 05:57, wirz wrote:

I do think it is about time Hugin/panotools switched to git. There is a lot
to like about mercurial, but git won. Also switching to git would make
migration away from sourceforge easier if that needed to happen.

Yes, git would be an improvement, and I'm pretty sure there is no downside other than the one-time work of switching.  I'm not saying that isn't work of course. 

I am not a contributor, but yes I think Git is the clear winner in the VCS scope.


What would have an even higher benefit to me would be to use a platform where patches can be contributed through pull requests or similar, instead of uploading patches as single files / zipped collections of files.  And the notifications on launchpad seem to be broken -- I'm seeing that in both directions, which makes it less attractive to contrib patches, etc.  I'd probably do more if it were simpler. 

Pull Requests/Merge Requests are a great way to allow new users to easily contribute, I agree!


But I think github should serve as a cautionary tale: I have perceived them as beyond any doubt 10 years ago, while now I perceive github mostly as a tool for Microsoft to collect LLM training material.

GitHub is indeed a rather different place than it was 10 years ago, it is now an AI training source and has now been handed to Microsoft's AI team to run, which leaves a sick feeling in my stomach. Self-hosted platforms are fairly easy to set up and manage, or there are great alternatives like Codeberg (as well as plenty of others) if you don't have the time or inclination to self-host.

Regards,

Justin

T. Modes

unread,
Aug 26, 2025, 12:55:58 PMAug 26
to hugin and other free panoramic software
lukas wirz schrieb am Montag, 25. August 2025 um 22:28:03 UTC+2:

> I do think it is about time Hugin/panotools switched to git. There is a lot
> to like about mercurial, but git won. Also switching to git would make
> migration away from sourceforge easier if that needed to happen.

Yes, git would be an improvement, and I'm pretty sure there is no
downside other than the one-time work of switching. I'm not saying that
isn't work of course.

I prefer currently Mercurial. Especially the GUI provides function like a fine grained selection of chunks to commit I haven't seen in git.

What would have an even higher benefit to me would be to use a platform
where patches can be contributed through pull requests or similar,
instead of uploading patches as single files / zipped collections of
files.

Sourceforge provides merge request ( https://sourceforge.net/p/hugin/hugin/merge-requests/ ). But they are seldom used.

Thomas

Bruno Postle

unread,
Aug 26, 2025, 2:29:01 PMAug 26
to hugin and other free panoramic software
On Tue, 26 Aug 2025, 17:56 'T. Modes' via hugin and other free panoramic software wrote:

I prefer currently Mercurial. Especially the GUI provides function like a fine grained selection of chunks to commit I haven't seen in git.

I think mercurial is a better design (the git pull command is an abomination), but git won, we can't expect contributers to learn mercurial. When I have time I'll start migrating the panotools repositories, starting with the least interesting, and documenting the process.

BTW some of these repositories started in CVS, were migrated to Subversion, and then Mercurial.

-- 
Bruno

RizThon

unread,
Aug 27, 2025, 1:37:27 AMAug 27
to hugi...@googlegroups.com
I used Mercurial for years with TortoiseHg and I really liked it, but I've since switched to Git with TortoiseGit.

In TortoiseGit, you can easily choose the files you want to commit, and see the diff on the right.

There's no direct way to check/uncheck what chunk to commit, but it's possible to have a similar feature:

- right click the file then choose "Restore after commit"
- double click the file to see the diff with the previous version
- undo the chunks you do not want then save and close the diff
- commit the file, with now only the chunks you want
- after the commit, the chunks you removed are back, and you can commit them separately

It's definitely not as straightforward as with Hg, but it's possible.

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.

Douglas Wilkins

unread,
Aug 27, 2025, 11:27:16 AMAug 27
to hugin and other free panoramic software
Hi,
Git does offer the ability to patch (choose chunks) or edit (pick and choose lines) when adding files to be staged for a commit. Docs are here: https://git-scm.com/docs/git-add
Tools like TortoiseGit (when partial staging is enabled) and VS Code now support this functionality in the GUI 

Doug
Reply all
Reply to author
Forward
0 new messages