Menu
▾
▴
amforth-devel
|
From: Erich W. <ew....@na...> - 2020-11-02 19:37:04
|
Dear AmForthers, some time ago (2020-08-02), Mark Roth suggested to come up with a "road map". Now while mapping unknown territory is a challenge of sorts, it might be not that difficult in this case. This my personal point of view, it might change anytime without prior notice. 1. Accumulate all commits since Jan 2019 and call it *release 6.9* That I have done. :) 2. Document the exact steps that were needed to create "a release". Well yes, I have these lines, but not in shape and maybe not complete. It should be added to the repository nonetheless. 3. Add testing scripts --- I have a set of scripts for that, but I have not run this stuff yet. However, in my opinion adding a working test suite is far more important at the moment, than anything else. This includes preparing some hardware with 4 relevant target boards in order to simplify the process. 4. Call this *release 7.0* 5. Convert and Move Repository Currently it looks like I would have to convert the svn repository to a git repository with a tool like svn2git. This is a process I would like to avoid, so if someone knows how to convert the repository "server side", or even how to export the complete svn repository on sourceforge into a big file ... all hints are kindly appreciated. I would then move to sourcehut.org. Why? - I do have an account there already - sourcehut offers accounts for a very reasonable amount of money. - sourchut works without javascript! Can you believe this? No? Try it. For me this is a major step in the correct direction. [1] - I would order and pay for a new project account - I would like to add at least two collaborators with full access from day one. Volunteers? This is going to include more things than just converting the repository: - possibly convert the releases/N.M directories into branches - create a new space for the webpage - automate generation of the webpage, serverside if possible - document how to locally generate the documentation --- well, the stuff you have to install before "cd doc; make all". - look into the use of javascript and possible ways to reduce that, should it be desirable - create an archive for (some of) the old tarballs - archive and transfer the mailing list content - create a new mailing list - automate the generation of a release - document the release process - start using the bugtracker (preferably with connection to the mailing list) - test the branch-edit-pull.request-merge workflow - possibly convert "Opinion" into a prober blog? - setup a redirection notice on sourceforge, close everything else down. - possibly dissolve amforth/community into a ./contrib/ subdirectory, test the stuff again and document it better https://sourceforge.net/p/amforth/community/HEAD/tree/ And this list is not complete. 6. Call this *release 8.0* 7. Remove arm msp430 riscv for the sake of simplicity -- unless someone speaks up to offer help. Carsten has offered support for arm and riscv --- Thank you! msp430 anyone? 8. Fix and automate the creation of the reference cards - include ALL available WORDs (not only the ones in a particular build) - include the exact file path(s), where WORD is defined - possibly add a Forth equivalent (.asm WORDS) - possibly a pointer to a worked example In order to achieve that I would rework the existing perl script AND add any missing file headers, possibly in a new/enhanced format. If we get this far, then imho we have /advanced considerably/. Does this sound like a worthwile plan? I'm sure there are other ideas and suggestions. Point 5 is huge and needs to be broken into smaller steps. I would appreciate any response, and if you could include, which target you are using, all the better. Still reading? Thank you for your precious time. Happy forthing, Erich [1] I'm using torbrowser most of the time. I'm using firefox to work at amforth.sourceforge.net. However, NoScript or uMatrix do an excellent job, but break the sf.net webpage routinely. I do not see all the buttons and what not unless I really switch off NoScript. This is not, what I prefer. -- May the Forth be with you ... |
|
From: Tristan W. <ho...@tj...> - 2020-11-02 21:36:39
|
Hello Erich, AmForthers, > Does this sound like a worthwile plan? Yes, very much so. I would be interested in progressing further with AmForth for RISC-V. The existing AmForth target board HiFive1 has been discontinued [1] - though there is the upgraded HiFive1 Rev B [2]. Are there any views on which RISC-V board(s) should be considered for AmForth? I like the idea of converting "opinion" into a proper blog, perhaps extending it to some more general Forth ideas/resources. Best wishes, Tristan [1] https://www.sifive.com/boards/hifive1 [2] https://www.sifive.com/boards/hifive1-rev-b On 02Nov20 20:36, Erich Wälde wrote: > > Dear AmForthers, > > some time ago (2020-08-02), Mark Roth suggested to come up with a > "road map". Now while mapping unknown territory is a challenge of > sorts, it might be not that difficult in this case. > > This my personal point of view, it might change anytime without prior > notice. > > 1. Accumulate all commits since Jan 2019 and call it *release 6.9* > That I have done. :) > > 2. Document the exact steps that were needed to create "a release". > Well yes, I have these lines, but not in shape and maybe not > complete. It should be added to the repository nonetheless. > > 3. Add testing scripts --- I have a set of scripts for that, but I > have not run this stuff yet. However, in my opinion adding a > working test suite is far more important at the moment, than > anything else. > > This includes preparing some hardware with 4 relevant target boards > in order to simplify the process. > > 4. Call this *release 7.0* > > 5. Convert and Move Repository > > Currently it looks like I would have to convert the svn repository > to a git repository with a tool like svn2git. This is a process I > would like to avoid, so if someone knows how to convert the > repository "server side", or even how to export the complete svn > repository on sourceforge into a big file ... all hints are kindly > appreciated. > > I would then move to sourcehut.org. Why? > > - I do have an account there already > - sourcehut offers accounts for a very reasonable amount of money. > - sourchut works without javascript! Can you believe this? No? Try it. > For me this is a major step in the correct direction. [1] > - I would order and pay for a new project account > - I would like to add at least two collaborators with full access > from day one. Volunteers? > > This is going to include more things than just converting the > repository: > > - possibly convert the releases/N.M directories into branches > - create a new space for the webpage > - automate generation of the webpage, serverside if possible > - document how to locally generate the documentation --- well, the > stuff you have to install before "cd doc; make all". > - look into the use of javascript and possible ways to reduce that, > should it be desirable > - create an archive for (some of) the old tarballs > - archive and transfer the mailing list content > - create a new mailing list > - automate the generation of a release > - document the release process > - start using the bugtracker (preferably with connection to the > mailing list) > - test the branch-edit-pull.request-merge workflow > - possibly convert "Opinion" into a prober blog? > - setup a redirection notice on sourceforge, close everything else > down. > - possibly dissolve amforth/community into a ./contrib/ > subdirectory, test the stuff again and document it better > https://sourceforge.net/p/amforth/community/HEAD/tree/ > > And this list is not complete. > > 6. Call this *release 8.0* > > 7. Remove arm msp430 riscv for the sake of simplicity -- unless > someone speaks up to offer help. > > Carsten has offered support for arm and riscv --- Thank you! > > msp430 anyone? > > 8. Fix and automate the creation of the reference cards > > - include ALL available WORDs (not only the ones in a particular > build) > - include the exact file path(s), where WORD is defined > - possibly add a Forth equivalent (.asm WORDS) > - possibly a pointer to a worked example > > In order to achieve that I would rework the existing perl script > AND add any missing file headers, possibly in a new/enhanced > format. > > > If we get this far, then imho we have /advanced considerably/. > > > > > Does this sound like a worthwile plan? > > I'm sure there are other ideas and suggestions. > > Point 5 is huge and needs to be broken into smaller steps. > > > I would appreciate any response, and if you could > include, which target you are using, all the better. > > > Still reading? > Thank you for your precious time. > > Happy forthing, > Erich > > > > [1] I'm using torbrowser most of the time. I'm using firefox to > work at amforth.sourceforge.net. However, NoScript or uMatrix do > an excellent job, but break the sf.net webpage routinely. I do > not see all the buttons and what not unless I really switch off > NoScript. This is not, what I prefer. > > -- > May the Forth be with you ... > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Matt L. <ma...@te...> - 2020-11-02 22:10:55
|
I would love to see native Forth on the ESP8266 boards. With 4mb of storage that my boards have, it would be really handy. -- Matt On 11/2/20 3:36 PM, Tristan Williams wrote: > Hello Erich, AmForthers, > >> Does this sound like a worthwile plan? > Yes, very much so. > > I would be interested in progressing further with AmForth for > RISC-V. The existing AmForth target board HiFive1 has been > discontinued [1] - though there is the upgraded HiFive1 Rev B [2]. > > Are there any views on which RISC-V board(s) should be considered for > AmForth? > > I like the idea of converting "opinion" into a proper blog, perhaps > extending it to some more general Forth ideas/resources. > > Best wishes, > Tristan > > [1] https://www.sifive.com/boards/hifive1 > [2] https://www.sifive.com/boards/hifive1-rev-b > > On 02Nov20 20:36, Erich Wälde wrote: >> Dear AmForthers, >> >> some time ago (2020-08-02), Mark Roth suggested to come up with a >> "road map". Now while mapping unknown territory is a challenge of >> sorts, it might be not that difficult in this case. >> >> This my personal point of view, it might change anytime without prior >> notice. >> >> 1. Accumulate all commits since Jan 2019 and call it *release 6.9* >> That I have done. :) >> >> 2. Document the exact steps that were needed to create "a release". >> Well yes, I have these lines, but not in shape and maybe not >> complete. It should be added to the repository nonetheless. >> >> 3. Add testing scripts --- I have a set of scripts for that, but I >> have not run this stuff yet. However, in my opinion adding a >> working test suite is far more important at the moment, than >> anything else. >> >> This includes preparing some hardware with 4 relevant target boards >> in order to simplify the process. >> >> 4. Call this *release 7.0* >> >> 5. Convert and Move Repository >> >> Currently it looks like I would have to convert the svn repository >> to a git repository with a tool like svn2git. This is a process I >> would like to avoid, so if someone knows how to convert the >> repository "server side", or even how to export the complete svn >> repository on sourceforge into a big file ... all hints are kindly >> appreciated. >> >> I would then move to sourcehut.org. Why? >> >> - I do have an account there already >> - sourcehut offers accounts for a very reasonable amount of money. >> - sourchut works without javascript! Can you believe this? No? Try it. >> For me this is a major step in the correct direction. [1] >> - I would order and pay for a new project account >> - I would like to add at least two collaborators with full access >> from day one. Volunteers? >> >> This is going to include more things than just converting the >> repository: >> >> - possibly convert the releases/N.M directories into branches >> - create a new space for the webpage >> - automate generation of the webpage, serverside if possible >> - document how to locally generate the documentation --- well, the >> stuff you have to install before "cd doc; make all". >> - look into the use of javascript and possible ways to reduce that, >> should it be desirable >> - create an archive for (some of) the old tarballs >> - archive and transfer the mailing list content >> - create a new mailing list >> - automate the generation of a release >> - document the release process >> - start using the bugtracker (preferably with connection to the >> mailing list) >> - test the branch-edit-pull.request-merge workflow >> - possibly convert "Opinion" into a prober blog? >> - setup a redirection notice on sourceforge, close everything else >> down. >> - possibly dissolve amforth/community into a ./contrib/ >> subdirectory, test the stuff again and document it better >> https://sourceforge.net/p/amforth/community/HEAD/tree/ >> >> And this list is not complete. >> >> 6. Call this *release 8.0* >> >> 7. Remove arm msp430 riscv for the sake of simplicity -- unless >> someone speaks up to offer help. >> >> Carsten has offered support for arm and riscv --- Thank you! >> >> msp430 anyone? >> >> 8. Fix and automate the creation of the reference cards >> >> - include ALL available WORDs (not only the ones in a particular >> build) >> - include the exact file path(s), where WORD is defined >> - possibly add a Forth equivalent (.asm WORDS) >> - possibly a pointer to a worked example >> >> In order to achieve that I would rework the existing perl script >> AND add any missing file headers, possibly in a new/enhanced >> format. >> >> >> If we get this far, then imho we have /advanced considerably/. >> >> >> >> >> Does this sound like a worthwile plan? >> >> I'm sure there are other ideas and suggestions. >> >> Point 5 is huge and needs to be broken into smaller steps. >> >> >> I would appreciate any response, and if you could >> include, which target you are using, all the better. >> >> >> Still reading? >> Thank you for your precious time. >> >> Happy forthing, >> Erich >> >> >> >> [1] I'm using torbrowser most of the time. I'm using firefox to >> work at amforth.sourceforge.net. However, NoScript or uMatrix do >> an excellent job, but break the sf.net webpage routinely. I do >> not see all the buttons and what not unless I really switch off >> NoScript. This is not, what I prefer. >> >> -- >> May the Forth be with you ... >> >> >> _______________________________________________ >> Amforth-devel mailing list for http://amforth.sf.net/ >> Amf...@li... >> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Ian J. <ij...@sa...> - 2020-11-03 01:39:37
|
Hi Erich, I’m probably another year out to offer any help if I’m even still capable… although I think I could muddle through and contribute some system admin type help with the irksome repositories. It seems to me that embedded hardware is vibrantly healthy and with the pressures IoT and of energy management low power etc. may stay that way. I’m curious therefore about the future of the current Atmel platform vs some of the other chips out there. Should amforth keep its name or has it evolved to something else than Atmel Forth? As for the plan it sounds great to me. I am especially the part about realizing that having a plan makes us better prepared for change not resistant to it. “it might change anytime without prior notice” . Thank you again for stepping in on this project. I hope to return to forth when I unpack my Oscilloscope and bench power supply wherever they went. May the forth be with all the AMForthers - or any other corny positive greeting I can offer in this very strange and ugly year. Ian > On Nov 2, 2020, at 2:36 PM, Erich Wälde <ew....@na...> wrote: > > > Dear AmForthers, > > some time ago (2020-08-02), Mark Roth suggested to come up with a > "road map". Now while mapping unknown territory is a challenge of > sorts, it might be not that difficult in this case. > > This my personal point of view, it might change anytime without prior > notice. > > 1. Accumulate all commits since Jan 2019 and call it *release 6.9* > That I have done. :) > > 2. Document the exact steps that were needed to create "a release". > Well yes, I have these lines, but not in shape and maybe not > complete. It should be added to the repository nonetheless. > > 3. Add testing scripts --- I have a set of scripts for that, but I > have not run this stuff yet. However, in my opinion adding a > working test suite is far more important at the moment, than > anything else. > > This includes preparing some hardware with 4 relevant target boards > in order to simplify the process. > > 4. Call this *release 7.0* > > 5. Convert and Move Repository > > Currently it looks like I would have to convert the svn repository > to a git repository with a tool like svn2git. This is a process I > would like to avoid, so if someone knows how to convert the > repository "server side", or even how to export the complete svn > repository on sourceforge into a big file ... all hints are kindly > appreciated. > > I would then move to sourcehut.org. Why? > > - I do have an account there already > - sourcehut offers accounts for a very reasonable amount of money. > - sourchut works without javascript! Can you believe this? No? Try it. > For me this is a major step in the correct direction. [1] > - I would order and pay for a new project account > - I would like to add at least two collaborators with full access > from day one. Volunteers? > > This is going to include more things than just converting the > repository: > > - possibly convert the releases/N.M directories into branches > - create a new space for the webpage > - automate generation of the webpage, serverside if possible > - document how to locally generate the documentation --- well, the > stuff you have to install before "cd doc; make all". > - look into the use of javascript and possible ways to reduce that, > should it be desirable > - create an archive for (some of) the old tarballs > - archive and transfer the mailing list content > - create a new mailing list > - automate the generation of a release > - document the release process > - start using the bugtracker (preferably with connection to the > mailing list) > - test the branch-edit-pull.request-merge workflow > - possibly convert "Opinion" into a prober blog? > - setup a redirection notice on sourceforge, close everything else > down. > - possibly dissolve amforth/community into a ./contrib/ > subdirectory, test the stuff again and document it better > https://sourceforge.net/p/amforth/community/HEAD/tree/ > > And this list is not complete. > > 6. Call this *release 8.0* > > 7. Remove arm msp430 riscv for the sake of simplicity -- unless > someone speaks up to offer help. > > Carsten has offered support for arm and riscv --- Thank you! > > msp430 anyone? > > 8. Fix and automate the creation of the reference cards > > - include ALL available WORDs (not only the ones in a particular > build) > - include the exact file path(s), where WORD is defined > - possibly add a Forth equivalent (.asm WORDS) > - possibly a pointer to a worked example > > In order to achieve that I would rework the existing perl script > AND add any missing file headers, possibly in a new/enhanced > format. > > > If we get this far, then imho we have /advanced considerably/. > > > > > Does this sound like a worthwile plan? > > I'm sure there are other ideas and suggestions. > > Point 5 is huge and needs to be broken into smaller steps. > > > I would appreciate any response, and if you could > include, which target you are using, all the better. > > > Still reading? > Thank you for your precious time. > > Happy forthing, > Erich > > > > [1] I'm using torbrowser most of the time. I'm using firefox to > work at amforth.sourceforge.net. However, NoScript or uMatrix do > an excellent job, but break the sf.net webpage routinely. I do > not see all the buttons and what not unless I really switch off > NoScript. This is not, what I prefer. > > -- > May the Forth be with you ... > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: <fr...@fr...> - 2020-11-03 09:34:08
|
Hi! > Point 5 is huge and needs to be broken into smaller steps. > > I would appreciate any response, and if you could > include, which target you are using, all the better. We (http://www.project-open.com/) are in the process of moving from CVS to GIT for the next ]project-open[ V5.1 release. The process is the same for SVN, the tool is actually called svn2git... We decided to host our repos on a private GitLab instance because: - GitLab allows us to setup permissions for "packages" (see below). That's important for us, because customer specific packages contain code that is not public. - GitLab is open source. - The GitLab founders are credible with their open source philosophy and the business model seems viable. We also publish on GitHub for PR reasons. It's free... Previously, our code was kept in a CVS repository. We installed GitLab in a VM and moved the CVS repository to the same CentOS VM that is running GitLab. Every night we now run "cvs2git" which is originally from http://cvs2svn.tigris.org/cvs2svn.html but now available for example here: https://github.com/mhagger/cvs2svn We have configured cvs2git to push the CVS changes both to GitHub and our private GitLab repos. This has worked without problems for quite some time, many repositories (our product consists of ~200 "packages" which are represented by separate repos) and very large repositories (we've got ~4 million LoC in total). Our next ]po[ V5.1 release will be based on GIT. We like that we can work with GIT on the "customer" side, while still using CVS as the upstream/master repository for some time. CVS is still referenced by many integration links, so we can't just break this. I believe the AmForth community should take several decisions: - Gradual or "big bang" migration? Should SVN and GIT run in parallel for some time, or is it OK to have a single big bang migration? Big bang is a lot easier... - Do you want to completely ignore GitHub? GitHub is the go-to place for open source software. Google does heavy indexing there. If you want AmForth to reach a large community, then you have to publish there. However, it doesn't need to the the primary repo... > convert the releases/N.M directories This seems to be quite difficult to me. Maybe just keep these directories during the initial migration and delete them in the following releases? Keep up the good work! Cheers! Frank On 2/11/20 20:36, Erich Wälde wrote: > Dear AmForthers, > > some time ago (2020-08-02), Mark Roth suggested to come up with a > "road map". Now while mapping unknown territory is a challenge of > sorts, it might be not that difficult in this case. > > This my personal point of view, it might change anytime without prior > notice. > > 1. Accumulate all commits since Jan 2019 and call it *release 6.9* > That I have done. :) > > 2. Document the exact steps that were needed to create "a release". > Well yes, I have these lines, but not in shape and maybe not > complete. It should be added to the repository nonetheless. > > 3. Add testing scripts --- I have a set of scripts for that, but I > have not run this stuff yet. However, in my opinion adding a > working test suite is far more important at the moment, than > anything else. > > This includes preparing some hardware with 4 relevant target boards > in order to simplify the process. > > 4. Call this *release 7.0* > > 5. Convert and Move Repository > > Currently it looks like I would have to convert the svn repository > to a git repository with a tool like svn2git. This is a process I > would like to avoid, so if someone knows how to convert the > repository "server side", or even how to export the complete svn > repository on sourceforge into a big file ... all hints are kindly > appreciated. > > I would then move to sourcehut.org. Why? > > - I do have an account there already > - sourcehut offers accounts for a very reasonable amount of money. > - sourchut works without javascript! Can you believe this? No? Try it. > For me this is a major step in the correct direction. [1] > - I would order and pay for a new project account > - I would like to add at least two collaborators with full access > from day one. Volunteers? > > This is going to include more things than just converting the > repository: > > - possibly convert the releases/N.M directories into branches > - create a new space for the webpage > - automate generation of the webpage, serverside if possible > - document how to locally generate the documentation --- well, the > stuff you have to install before "cd doc; make all". > - look into the use of javascript and possible ways to reduce that, > should it be desirable > - create an archive for (some of) the old tarballs > - archive and transfer the mailing list content > - create a new mailing list > - automate the generation of a release > - document the release process > - start using the bugtracker (preferably with connection to the > mailing list) > - test the branch-edit-pull.request-merge workflow > - possibly convert "Opinion" into a prober blog? > - setup a redirection notice on sourceforge, close everything else > down. > - possibly dissolve amforth/community into a ./contrib/ > subdirectory, test the stuff again and document it better > https://sourceforge.net/p/amforth/community/HEAD/tree/ > > And this list is not complete. > > 6. Call this *release 8.0* > > 7. Remove arm msp430 riscv for the sake of simplicity -- unless > someone speaks up to offer help. > > Carsten has offered support for arm and riscv --- Thank you! > > msp430 anyone? > > 8. Fix and automate the creation of the reference cards > > - include ALL available WORDs (not only the ones in a particular > build) > - include the exact file path(s), where WORD is defined > - possibly add a Forth equivalent (.asm WORDS) > - possibly a pointer to a worked example > > In order to achieve that I would rework the existing perl script > AND add any missing file headers, possibly in a new/enhanced > format. > > > If we get this far, then imho we have /advanced considerably/. > > > > > Does this sound like a worthwile plan? > > I'm sure there are other ideas and suggestions. > > Point 5 is huge and needs to be broken into smaller steps. > > > I would appreciate any response, and if you could > include, which target you are using, all the better. > > > Still reading? > Thank you for your precious time. > > Happy forthing, > Erich > > > > [1] I'm using torbrowser most of the time. I'm using firefox to > work at amforth.sourceforge.net. However, NoScript or uMatrix do > an excellent job, but break the sf.net webpage routinely. I do > not see all the buttons and what not unless I really switch off > NoScript. This is not, what I prefer. > |
|
From: <di...@sc...> - 2020-11-03 20:02:54
|
Hi all, I think I introduced myself already, but that was years ago. I first played around with forth in the 80s, but never had a chance to use it properly for a real project. Maybe this changes now, because due to corona I am working part-time now.. On the svn2git topic: I gave it a try and started a svn2git conversion on my machine with the command: svn2git https://svn.code.sf.net/p/amforth/code --branches releases This takes about 10 minutes, depending on host power and network connection. This converts the trunk to themaster branch and converts all the releases tree to branches. The result looks quite well to me. I have uploaded it to a private server, you can have a look at: fo...@ho...:amforth.git The password is the name of this project in uppercase, a dot, and 0x7d6 in decimal. If you like, I could also upload it to gitlab or github. Kind regards, Dieter Am Di., Nov. 3, 2020 10:34 schrieb fr...@fr...: Hi! Point 5 is huge and needs to be broken into smaller steps. I would appreciate any response, and if you could include, which target you are using, all the better. We (http://www.project-open.com/ (http://www.project-open.com/)) are in the process of moving from CVS to GIT for the next ]project-open[ V5.1 release. The process is the same for SVN, the tool is actually called svn2git... We decided to host our repos on a private GitLab instance because: - GitLab allows us to setup permissions for "packages" (see below). That's important for us, because customer specific packages contain code that is not public. - GitLab is open source. - The GitLab founders are credible with their open source philosophy and the business model seems viable. We also publish on GitHub for PR reasons. It's free... Previously, our code was kept in a CVS repository. We installed GitLab in a VM and moved the CVS repository to the same CentOS VM that is running GitLab. Every night we now run "cvs2git" which is originally from http://cvs2svn.tigris.org/cvs2svn.html (http://cvs2svn.tigris.org/cvs2svn.html) but now available for example here: https://github.com/mhagger/cvs2svn (https://github.com/mhagger/cvs2svn) We have configured cvs2git to push the CVS changes both to GitHub and our private GitLab repos. This has worked without problems for quite some time, many repositories (our product consists of ~200 "packages" which are represented by separate repos) and very large repositories (we've got ~4 million LoC in total). Our next ]po[ V5.1 release will be based on GIT. We like that we can work with GIT on the "customer" side, while still using CVS as the upstream/master repository for some time. CVS is still referenced by many integration links, so we can't just break this. I believe the AmForth community should take several decisions: - Gradual or "big bang" migration? Should SVN and GIT run in parallel for some time, or is it OK to have a single big bang migration? Big bang is a lot easier... - Do you want to completely ignore GitHub? GitHub is the go-to place for open source software. Google does heavy indexing there. If you want AmForth to reach a large community, then you have to publish there. However, it doesn't need to the the primary repo... convert the releases/N.M directories This seems to be quite difficult to me. Maybe just keep these directories during the initial migration and delete them in the following releases? Keep up the good work! Cheers! Frank On 2/11/20 20:36, Erich Wälde wrote: Dear AmForthers, some time ago (2020-08-02), Mark Roth suggested to come up with a "road map". Now while mapping unknown territory is a challenge of sorts, it might be not that difficult in this case. This my personal point of view, it might change anytime without prior notice. 1. Accumulate all commits since Jan 2019 and call it *release 6.9* That I have done. :) 2. Document the exact steps that were needed to create "a release". Well yes, I have these lines, but not in shape and maybe not complete. It should be added to the repository nonetheless. 3. Add testing scripts --- I have a set of scripts for that, but I have not run this stuff yet. However, in my opinion adding a working test suite is far more important at the moment, than anything else. This includes preparing some hardware with 4 relevant target boards in order to simplify the process. 4. Call this *release 7.0* 5. Convert and Move Repository Currently it looks like I would have to convert the svn repository to a git repository with a tool like svn2git. This is a process I would like to avoid, so if someone knows how to convert the repository "server side", or even how to export the complete svn repository on sourceforge into a big file ... all hints are kindly appreciated. I would then move to sourcehut.org. Why? - I do have an account there already - sourcehut offers accounts for a very reasonable amount of money. - sourchut works without javascript! Can you believe this? No? Try it. For me this is a major step in the correct direction. [1] - I would order and pay for a new project account - I would like to add at least two collaborators with full access from day one. Volunteers? This is going to include more things than just converting the repository: - possibly convert the releases/N.M directories into branches - create a new space for the webpage - automate generation of the webpage, serverside if possible - document how to locally generate the documentation --- well, the stuff you have to install before "cd doc; make all". - look into the use of javascript and possible ways to reduce that, should it be desirable - create an archive for (some of) the old tarballs - archive and transfer the mailing list content - create a new mailing list - automate the generation of a release - document the release process - start using the bugtracker (preferably with connection to the mailing list) - test the branch-edit-pull.request-merge workflow - possibly convert "Opinion" into a prober blog? - setup a redirection notice on sourceforge, close everything else down. - possibly dissolve amforth/community into a ./contrib/ subdirectory, test the stuff again and document it better https://sourceforge.net/p/amforth/community/HEAD/tree/ (https://sourceforge.net/p/amforth/community/HEAD/tree/) And this list is not complete. 6. Call this *release 8.0* 7. Remove arm msp430 riscv for the sake of simplicity -- unless someone speaks up to offer help. Carsten has offered support for arm and riscv --- Thank you! msp430 anyone? 8. Fix and automate the creation of the reference cards - include ALL available WORDs (not only the ones in a particular build) - include the exact file path(s), where WORD is defined - possibly add a Forth equivalent (.asm WORDS) - possibly a pointer to a worked example In order to achieve that I would rework the existing perl script AND add any missing file headers, possibly in a new/enhanced format. If we get this far, then imho we have /advanced considerably/. Does this sound like a worthwile plan? I'm sure there are other ideas and suggestions. Point 5 is huge and needs to be broken into smaller steps. I would appreciate any response, and if you could include, which target you are using, all the better. Still reading? Thank you for your precious time. Happy forthing, Erich [1] I'm using torbrowser most of the time. I'm using firefox to work at amforth.sourceforge.net. However, NoScript or uMatrix do an excellent job, but break the sf.net webpage routinely. I do not see all the buttons and what not unless I really switch off NoScript. This is not, what I prefer. _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ (http://amforth.sf.net/) Amf...@li... (mailto:Amf...@li...) https://lists.sourceforge.net/lists/listinfo/amforth-devel (https://lists.sourceforge.net/lists/listinfo/amforth-devel) |
|
From: Carsten S. <ca...@st...> - 2020-11-04 13:22:32
|
Hello Dieter, On 3 Nov 2020, at 20:07, di...@sc... wrote: > I gave it a try and started a svn2git conversion on my machine with > the command: > svn2git https://svn.code.sf.net/p/amforth/code --branches releases > This takes about 10 minutes, depending on host power and network > connection. > This converts the trunk to themaster branch and converts all the > releases tree to branches. > The result looks quite well to me. thank you. I've cloned your git repo and indeed it looks good to me (but I'm not a big expert on "git", but I see the different commits and diffs) Greetings Carsten |
|
From: Ian J. <ij...@sa...> - 2020-11-03 20:47:37
|
Some good points here: > On Nov 3, 2020, at 4:33 AM, fr...@fr... wrote: > > - Gradual or "big bang" migration? > Should SVN and GIT run in parallel for some time, or is > it OK to have a single big bang migration? Big bang is > a lot easier… > Big Bang. We are too small and under staffed (current Army of Erich!) to maintain stuff in parallel. Given the opportunity we can all grab working copies before the transition. A good thought here Frank. > - Do you want to completely ignore GitHub? > GitHub is the go-to place for open source software. > Google does heavy indexing there. If you want AmForth > to reach a large community, then you have to publish > there. However, it doesn't need to the the primary repo... Another wise comment Frank. There is something eventually even I could maintain for the community! Keeping things as open to the main stream opensource crowd is a good thought even if the day to day is managed elsewhere and when. Ian |
|
From: Carsten S. <ca...@st...> - 2020-11-04 13:33:58
|
Hi, On 3 Nov 2020, at 21:47, Ian Jefferson wrote: > Some good points here: > >> On Nov 3, 2020, at 4:33 AM, fr...@fr... wrote: >> >> - Gradual or "big bang" migration? >> Should SVN and GIT run in parallel for some time, or is >> it OK to have a single big bang migration? Big bang is >> a lot easier… >> > > Big Bang. We are too small and under staffed (current Army of Erich!) > to maintain stuff in parallel. Given the opportunity we can all grab > working copies before the transition. A good thought here Frank. > +1 >> - Do you want to completely ignore GitHub? >> GitHub is the go-to place for open source software. >> Google does heavy indexing there. If you want AmForth >> to reach a large community, then you have to publish >> there. However, it doesn't need to the the primary repo... > > Another wise comment Frank. There is something eventually even I > could maintain for the community! Keeping things as open to the main > stream opensource crowd is a good thought even if the day to day is > managed elsewhere and when. I use both sourcehut and GitHub, I prefer sourcehut but I agree that amForth should have a presence on Github as well. There are already various forks of amForth on Github, as well as amForth related code. Being on Github is important to be visible. And yes, an automated sync between sr.ht and GitHub could be possible. A repo on GitHub should be "official", e.g. the same people that run the main repo (Erich at the moment) should also have control there, even if someone from the community operates the repo and the sync. This prevents that the two repos will diverge later. Greetings Carsten |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X