Menu
▾
▴
sdcc-devel
|
From: Felix S. <fe...@sa...> - 2024-04-04 14:05:54
|
On Thu, Apr 04, 2024 at 03:15:06PM +0200, Felix Salfelder wrote: > On Wed, Apr 03, 2024 at 08:40:46PM -0000, Ger Hobbelt wrote: > > (And if you find time to migrate out of SF into some git-based realm :+1: ;-) ) > > SDCC is already mirrored to codeberg [1] for the reasons you outlined. > > Best wishes > felix > > [1] https://codeberg.org/sdcc/ Resending to sdc...@li.... For some other reason my previous message did not come through, maybe this one does.. |
|
From: Ger H. <ge...@ho...> - 2024-04-05 10:32:07
|
Cool! Hadn't found the SDCC codeberg repo on my own, sorry. Didn't pop up on my Google search radar. :-( Anyway, message received. Excellent. Cheers, Ger On Thu, 4 Apr 2024, 16:06 Felix Salfelder, <fe...@sa...> wrote: > On Thu, Apr 04, 2024 at 03:15:06PM +0200, Felix Salfelder wrote: > > On Wed, Apr 03, 2024 at 08:40:46PM -0000, Ger Hobbelt wrote: > > > (And if you find time to migrate out of SF into some git-based realm > :+1: ;-) ) > > > > SDCC is already mirrored to codeberg [1] for the reasons you outlined. > > > > Best wishes > > felix > > > > [1] https://codeberg.org/sdcc/ > > Resending to sdc...@li.... For some other reason my > previous message did not come through, maybe this one does.. > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
|
From: Steve S. <ste...@gm...> - 2024-04-05 10:55:08
|
My naive question is "why another git hoster?" can't we leverage the SF.net git repo ? I do not have much issues with SF.net hosting outside that it uses SVN ;-) -- Steve Schnepp On Fri, Apr 5, 2024 at 12:32 PM Ger Hobbelt <ge...@ho...> wrote: > Cool! Hadn't found the SDCC codeberg repo on my own, sorry. Didn't pop up > on my Google search radar. :-( > > Anyway, message received. Excellent. > > Cheers, > > Ger > > > On Thu, 4 Apr 2024, 16:06 Felix Salfelder, <fe...@sa...> wrote: > >> On Thu, Apr 04, 2024 at 03:15:06PM +0200, Felix Salfelder wrote: >> > On Wed, Apr 03, 2024 at 08:40:46PM -0000, Ger Hobbelt wrote: >> > > (And if you find time to migrate out of SF into some git-based realm >> :+1: ;-) ) >> > >> > SDCC is already mirrored to codeberg [1] for the reasons you outlined. >> > >> > Best wishes >> > felix >> > >> > [1] https://codeberg.org/sdcc/ >> >> Resending to sdc...@li.... For some other reason my >> previous message did not come through, maybe this one does.. >> >> >> _______________________________________________ >> 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 > |
|
From: Felix S. <fe...@sa...> - 2024-04-05 11:30:01
|
On Fri, Apr 05, 2024 at 12:54:21PM +0200, Steve Schnepp wrote: > My naive question is "why another git hoster?" can't we leverage the SF.net > git repo ? > I do not have much issues with SF.net hosting outside that it uses SVN ;-) Here's some food for thought. Without write permissions you can't use a git repo to share patches. Codeberg allows private clones as a kind of workaround for this, and has a "clone repo" button that streamlines the use. Also, in order to get in touch with SDCC devs via sf, you need to accept sf terms and conditions and privacy policy. This is not needed when using codeberg. I would expect the mailing list to accept messages from non-subscribers, and allows attachments. Note how this will only help contributors willing and able to deal with patches manually, and also use email. cheers felix |
|
From: Steve S. <ste...@gm...> - 2024-04-05 12:43:24
|
(removing the ticket email address, as it's more relevant to devel@ anyway) While I do not want to start any hosting holy wars, here is my own food for thought. I also promise I won't discuss more than this email unless someone asks something about it :-) I would argue that no-one knows codeberg, even less so about this initiative. If the real purpose is to make it easier for anyone to contribute, I'd argue that the network effect would be much bigger if we leverage github, as imperfect as it may be. My point is more "either move to git on SF.net or directly bite the bullet and move towards github". Using an obscure hosting will just add more obscurity to this already obscure SDCC project ;-). I mean, many use sdcc without knowing it, but contributing to it is rather unappealing for newcomers. That fact may be wanted. Then let's not change anything, SVN is perfectly fine. Or do we want to attract more casual contributors such as me that we might convert to long term ones? For that, one cannot really fight against github, or at least gitlab if you really want to avoid github, because in the end, it's all about the "network effect". Using the mailing lists is something I don't do as much as before, and feels now much less natural to me, especially if that's the only way to interact with other fellow devs. But since I'm interested (while not skilled) I did force myself to it since SF.net isn't exactly unknown either. Not super modern, but not unknown. Yet I won't create yet another account on codeberg, which I don't have a clue on who is owning it, and I won't really bother to be honest. Yet, as said, I might not be the target of wanted contributors. Cheers, -- Steve Schnepp On Fri, Apr 5, 2024 at 1:30 PM Felix Salfelder <fe...@sa...> wrote: > On Fri, Apr 05, 2024 at 12:54:21PM +0200, Steve Schnepp wrote: > > My naive question is "why another git hoster?" can't we leverage the > SF.net > > git repo ? > > I do not have much issues with SF.net hosting outside that it uses SVN > ;-) > > Here's some food for thought. > > Without write permissions you can't use a git repo to share patches. > Codeberg allows private clones as a kind of workaround for this, and has > a "clone repo" button that streamlines the use. > > Also, in order to get in touch with SDCC devs via sf, you need to accept > sf terms and conditions and privacy policy. This is not needed when > using codeberg. > > I would expect the mailing list to accept messages from non-subscribers, > and allows attachments. Note how this will only help contributors > willing and able to deal with patches manually, and also use email. > > cheers > felix > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
|
From: Felix S. <fe...@sa...> - 2024-04-05 13:27:36
|
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/ |
|
From: Sam W. <sam...@gm...> - 2024-04-05 13:49:08
|
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 > |
|
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 > |
|
From: Felix S. <fe...@sa...> - 2024-04-05 18:35:21
|
On Fri, Apr 05, 2024 at 07:27:51PM +0200, Ger Hobbelt wrote: > I'm perfectly okay with Codeberg. [..] Thanks for your supportive words. I've just installed cronjob that pushes a couple of times a day. I might end up adding more immediate sync with webhook or so. I do not need it right now -- don't hold your breath. > Anyway, all this is just my experience and resulting opinion; I am NOT the > maintainer/owner of SDCC [..] Neither am I. Whether or not a maintainer will consider a patch presented as a git commit remains entirely up to them. Make it easy. Squash and rebase to trunk. Write a useful commit message, be kind, stay calm... Best wishes felix |
|
From: Philipp K. K. <pk...@sp...> - 2024-04-06 10:27:29
|
>> Anyway, all this is just my experience and resulting opinion; I am NOT the >> maintainer/owner of SDCC [..] > > Neither am I. Do we even have the concept of an owner or maintainer of SDCC as a whole? We do have maintainers of individual ports, and a maintainer of the simulators. I guess Felix is by now practically the maintainer of the preprocessor. Philipp |
|
From: Ger H. <ge...@ho...> - 2024-04-05 18:12:53
|
🥳 forked repo with the patches now up on codeberg: https://codeberg.org/GerHobbelt/code same branchnames as mentioned in the tickets. Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: ge...@ho... mobile: +31-6-11 120 978 -------------------------------------------------- On Thu, Apr 4, 2024 at 4:06 PM Felix Salfelder <fe...@sa...> wrote: > On Thu, Apr 04, 2024 at 03:15:06PM +0200, Felix Salfelder wrote: > > On Wed, Apr 03, 2024 at 08:40:46PM -0000, Ger Hobbelt wrote: > > > (And if you find time to migrate out of SF into some git-based realm > :+1: ;-) ) > > > > SDCC is already mirrored to codeberg [1] for the reasons you outlined. > > > > Best wishes > > felix > > > > [1] https://codeberg.org/sdcc/ > > Resending to sdc...@li.... For some other reason my > previous message did not come through, maybe this one does.. > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
Thanks for helping keep SourceForge clean.
X