There was a ticket (#3922) back in 2016 that brought up the idea that jEdit should be moved to github. I think the developers should revisit the idea. I believe the pros vastly outweigh the cons now.
I keep receiving emails from you. Please remove me for the email list, thank you
On Monday, June 12, 2023 at 11:01:12 AM GMT+2, whydo pplstillusesf via jEdit-devel jedit-devel@lists.sourceforge.net wrote:
Status: open
Group: none
Labels: github
Created: Wed Jun 02, 2021 12:07 AM UTC by sigzero
Last Updated: Mon Jun 12, 2023 08:55 AM UTC
Owner: nobody
There was a ticket (#3922) back in 2016 that brought up the idea that jEdit should be moved to github. I think the developers should revisit the idea. I believe the pros vastly outweigh the cons now.
Hey, I feel github much more efficient to navigate and use in git repositories, bugtrackers.
Github is centered on the developper while sourceforge is on the project.
For example if jEdit was on github, then I think we should not commit directly to the project. Just I would do a fork in my user space (that is public), you would do the same, Alan too and any developper who is interested in jEdit's development too. Then I would create a branch for my changes, and when I am satisfied I would submit a pull request from the branch of my personal space to jEdit project.
All those things are very easy to do in github and I found that contributing or forking other projects is very easy to do.
But of course the first thing to do is to migrate from svn to git. Then we can think about moving or not. But I think there is no secret why so many projects are moving to github. Just sourceforge was great in 2000 but it was unable to evolve to the modern standards.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Step 1 is it must be converted to git. Step 2 is it can be mirrored on both sf.net and github.
conversion to git including the full history (from cvs days) has been problematic according to vampire.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just realized my comments maybe didn't end up here even though i replied to the email i got (something that works on github pretty well).
in reponse to so list them out, i posted on Mon, Jun 12, 5:37 AM (edt)
Sure:
pros:
1. discoverability - github is the library of congress for code - people expect to find it there - would argue that it is safer there than here as msft has a lot in the bank and they are invested in getting everybody's code and preserving it in there supposedly to train ai etc
2. deduplication of effort - several developers have already exported the project and uploaded it to their personal github accounts
3. up and coming developers from this generation can find it and keep the project alive
4. git - git is the lingua franca of version control systems.
5. github actions - you can prove to the world that your code works because you can put a green checkmark at the top which links to a successful unit test run (i mean this is not unique, but it is built into github and free)
6. myriad of other github features (codespaces, labelled issues, PRs, etc)
7. up and coming developers from this generation can find it and keep the project alive
cons:
1. requires some amount of work
2. might lose some info in the process (like old issues) - i am personally not above writing a puppeteer script or something to scrape these off of SF and manually add them to a github issue tracker
3. you lose that retro feel
Alan, to your point i responded shortly after you posted:
Am curious to receive any feedback on that output - particularly with any flaws anyone can find or something that anyone wants to change, so it can be the best solution. I am also working (haven't touched it since hearing back that there are already plans for jEdit) on an issues copier tool from SF to GH.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
absolutely - @daleanson @ezust @grepppo @k_satoda - anybody home? (0_o - @vampire0 - any thoughts?)
I keep receiving emails from you. Please remove me for the email list, thank you
On Monday, June 12, 2023 at 11:01:12 AM GMT+2, whydo pplstillusesf via jEdit-devel jedit-devel@lists.sourceforge.net wrote:
absolutely - @daleanson @ezust @grepppo @k_satoda - anybody home? (0_o - @vampire0 - any thoughts?)
[feature-requests:#553] jEdit should move to github
Status: open
Group: none
Labels: github
Created: Wed Jun 02, 2021 12:07 AM UTC by sigzero
Last Updated: Mon Jun 12, 2023 08:55 AM UTC
Owner: nobody
There was a ticket (#3922) back in 2016 that brought up the idea that jEdit should be moved to github. I think the developers should revisit the idea. I believe the pros vastly outweigh the cons now.
Thanks.
Sent from sourceforge.net because jedit-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/jedit/feature-requests/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
jEdit Developers' List
jEdit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel
Related
Feature Requests: #553
So list them out, what are the pros and cons as you see them? What exactly does github provide that sf doesn't?
Hey, I feel github much more efficient to navigate and use in git repositories, bugtrackers.
Github is centered on the developper while sourceforge is on the project.
For example if jEdit was on github, then I think we should not commit directly to the project. Just I would do a fork in my user space (that is public), you would do the same, Alan too and any developper who is interested in jEdit's development too. Then I would create a branch for my changes, and when I am satisfied I would submit a pull request from the branch of my personal space to jEdit project.
All those things are very easy to do in github and I found that contributing or forking other projects is very easy to do.
But of course the first thing to do is to migrate from svn to git. Then we can think about moving or not. But I think there is no secret why so many projects are moving to github. Just sourceforge was great in 2000 but it was unable to evolve to the modern standards.
Step 1 is it must be converted to git. Step 2 is it can be mirrored on both sf.net and github.
conversion to git including the full history (from cvs days) has been problematic according to vampire.
I just realized my comments maybe didn't end up here even though i replied to the email i got (something that works on github pretty well).
in reponse to so list them out, i posted on Mon, Jun 12, 5:37 AM (edt)
Sure:
pros:
1. discoverability - github is the library of congress for code - people expect to find it there - would argue that it is safer there than here as msft has a lot in the bank and they are invested in getting everybody's code and preserving it in there supposedly to train ai etc
2. deduplication of effort - several developers have already exported the project and uploaded it to their personal github accounts
3. up and coming developers from this generation can find it and keep the project alive
4. git - git is the lingua franca of version control systems.
5. github actions - you can prove to the world that your code works because you can put a green checkmark at the top which links to a successful unit test run (i mean this is not unique, but it is built into github and free)
6. myriad of other github features (codespaces, labelled issues, PRs, etc)
7. up and coming developers from this generation can find it and keep the project alive
cons:
1. requires some amount of work
2. might lose some info in the process (like old issues) - i am personally not above writing a puppeteer script or something to scrape these off of SF and manually add them to a github issue tracker
3. you lose that retro feel
Alan, to your point i responded shortly after you posted: