From: Ger H. <ge...@ho...> - 2024-04-05 17:28:17
|
I'm perfectly okay with Codeberg. If you check them out quickly, about page and via internet, they sound legit. No red flags for me, at least. Extra points in their favour: they're not USA based or -backed and they're rather more principled about open source than I am. :+1: It still will cost a day to drive to Berlin and back again, so that'll be a B&B and expenses at least, but hey, in Internet terms, they live around the corner from this Dutchie. The drawback is of course their obvious inability to throw money at it like github and microsoft did as they live off support/donations and we all know what that implies: you're not getting rich and you won't make the top entry at Google Search. Which sounds like the equivalent of "retarded" to many, but not to me. Anyway, @Felix: please don't say git fork (+ pull with or without pull request) is a "work-around" for patches ;-)) for fork+pull[req] is much smoother going: patches haven't worked for me for 30+ years, "merge conflicts" (3 way merge) when orchestrated via patch files is, in my continual experience, a nightmare with no sweaty wake-up moment to make it stop. cvs and svn never did well for me either; both worse than the much-appreciated OG (`rcs`, back in the day. good memories with that one.) and SF was always a bit wonky but has, for me at least, become the equivalent of showing some remarkable not-too-recently demised animal to a lady: you know there's gonna be the sound of ewwww! GitLab is a very bad UX for me; it's more expensive than github and has zero(0) features that I appreciate in/on github. Okay, that's exeggering, apologies. They have one(1): private (non-public) repositories. So I'ld rather go with some principled fellows like the codeberg bunch, who've been around for a while already -- I first heard of them around the time github was being paraded in front of Microsoft and some more-principled-than-me folks decided to pick up and leave before the new management would enter with their equivalent of a shiny white toilet sink. I am happy to report git is a huge improvement over rcs (contrary to the others I've used: cvs, svn, perforce, vss, plus a short stint with hg and some stuff I can't even recall the name of any more: mindblock) and the fork + pull/pullreq approach is way easier on the brain when you track repos or otherwise are faced regularly with 3-way merges a.k.a. merge conflicts. When git came out, I jumped on that ship pretty soon after git-for-windows came out. Of course I say this while today I'm tooled up to the nines when it comes to git: I'm largely Windows based as a dev, always been, and the combo TortoiseGit (GUI) plus Beyond Compare (happy commercial customer there for 20-odd years now!) as the merge tool on top of rcs, then git, is keeping it pretty fast and generally low brain load, particularly 3-way merges with git are much easier than with any other rcs I've touched. Plus I've got in-house scripts so I type very few direct git commands any more. Contrast that with me processing patches or even other git toolchains, like I see a lot of peeps do on Linux. nuh-uh. Anyway, all this is just my experience and resulting opinion; I am NOT the maintainer/owner of SDCC and merely a few-lines-today contributor who wants to take SDCC on a local 8-bit MCU R&D ride this year, so the best thing to have and do, is use the kit that the maintainer (Felix) feels (very) comfortable with, for he's got the continued effort to make and little thanks to show for it, so it's his preferences that matter. Sounded on SF like he likes patches, so patchfiles it was to be. I try to influence him above but that's the end of my reach and as anyone can read, shop around and compare: my 30+ years experience isn't necessarily identical to any of yours. About codeberg: thanks for reminding me they are still around; I'm all-in on github, but I emphatically don't like their increasingly caricature big-corp/MS attitude when there's a little scare that might possibly reflect on them thanks to human nature (panic behaviour): they shut down and lock out repos and people at the first hint of trouble and then third-party investigation and recovery for those involved in the aftermath is a shitshow, so I'm not leaving there but I am really interested in survival strategies in case someone overthere decides they feel triggered, so that points me at codeberg again (and a few others of the same cloth, but the others I've ran into are all USA-based and that's not exactly a compliment today. So the summer resolution here is considering donating to the CB guys and copying my main stuff over. Not a solution for my commercial/private repos yet, but we'll see. This won't be solved this week, anyway. Codeberg: As they have different funding and different ethics/principles vs. github, I don't mind if they currently possibly lack a bunch of github features that I like to have, something that I /do/ mind about with gitlab as those are just another commercial party not significantly different from github, ethics/riskwise. Anyway, that's my perspective. I'll shut up exchanging my frank view. :-) Thanks for taking care of SDCC, Met vriendelijke groeten / Best regards, Ger Hobbelt (who used the [i_a] nick back in antiquity on SF and elsewhere.) PS: periodic updates from svn into git are doable, but not easy to get right if you like nice commit histories. I've done it a couple of times but you need a Linux rig with all the tooling and some serious patience to get it right or you end up with weird commit history logs and/or other crap. Not my favorite thing to do. github's on-line web interface option to do this worked well for one-offs but is being dropped or has already dropped from the sky this month (April 2024). The fact that SF didn't make this transition option easy for the SF users from early on when git clearly became the major goto guy for RCS (DVCS) is not giving me a lot of confidence that it is simple and smooth going overthere at SF today. Besides, SVN and GIT think completely differently about branches, etc. making it a one-way street anyway if you want to stay sane. Picking up forks/pullreqs from the likes of me would then require some sort of spitting out patch sequence mechanism (`git diff, git log, git format-patch`), which is exactly what I did for this ticket. Taking that patch-producing burden from the ticket-writing SDCC dev loads extra work onto the maintainer, which is the wrong approach. Either SDCC decides one day to hop over to The Git Side and do git/pulls/pullreqs, or it's patches like today that remain the safest / lowest-cost bet maintainer-side, AFAICT. -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: ge...@ho... mobile: +31-6-11 120 978 -------------------------------------------------- On Fri, Apr 5, 2024 at 3:49 PM Sam Wilson <sam...@gm...> wrote: > It shouldn't be too hard to simply import SVN history to git and push it > every night to github. > > Then just put a note to the effect of, "we won't accept pull requests > filed against this repository". But of course, we can still fork it there, > run CI/CD pipelines there, etcetera. That opens up the possibility that > someone wants to fork on github (or whatever) it to fix some issue or add a > feature. Such a fork can still be manually applied to the SVN repository. > Is this a viable strategy? > > On Fri, 5 Apr 2024 at 14:28, Felix Salfelder <fe...@sa...> wrote: > >> Apologies, I did not mean to re-open this discussion. >> >> In order to provide a non-experimental git repo, we need a system that >> performs the export. To keep the mirror on SF up to date, a "bot" >> account on SF is required, with the permission to push to it. None of >> this won't run on SF infrastructure, see [0,1]. >> >> cheers >> felix >> >> [0] >> https://sourceforge.net/p/sdcc/mailman/sdcc-devel/thread/05841bfc-2dc0-cd9d-b988-f0c1ccfa4f4c%40spth.de >> [1] https://sourceforge.net/p/forge/site-support/25239/ >> >> >> _______________________________________________ >> sdcc-devel mailing list >> sdc...@li... >> https://lists.sourceforge.net/lists/listinfo/sdcc-devel >> > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |