search

Webhuis / GNUCobolIDE-scratch

IDE for Cobol based on OpenCobolIDE, works with GNUCobol
GNU General Public License v3.0
0 stars 0 forks source link

Please recreate as a fork #2

Closed GitMensch closed 8 months ago

GitMensch commented 8 months ago

As it is currently done all chance history is lost. Can you please click on "fork", either from the original repo https://github.com/OpenCobolIDE/OpenCobolIDE or from one of the existing forks?

Doing so would also allow to use the right spelling #1 in the name.

Then do the rename of the main folder (and possibly README) as one commit, then add either your existing changes over by one or as a single commit.

That has the benefit of providing git history as well as attribution, and would also help people to find it using the fork view of OCIDE repos.

Webhuis commented 8 months ago

Thank you for the feed back. I will take action.

Webhuis commented 8 months ago

Hi Simon,

On 2024-02-17 01:10, Simon Sobisch wrote: As it is currently done all chance history is lost. Can you please click on "fork", either from the original repo https://github.com/OpenCobolIDE/OpenCobolIDE or from one of the existing forks?

Sound like a plan.

I am considering how to do the fork with help of Jeroen.

I already added a comment on the subject.

Doing so would also allow to use the right spelling #1 [1] in the name.

Then do the rename of the main folder (and possibly README) as one commit, then add either your existing changes over by one or as a single commit.

That has the benefit of providing git history as well as attribution, and would also help people to find it using the fork view of OCIDE repos.

Met vriendelijke groet, Martin.

LinkedIn: https://www.linkedin.com/in/martinsimons1/ GitHub: https://github.com/Webhuis/CFEngine-Roadshow/tree/master/ Twitter: https://twitter.com/webhuis @Webhuis #TheCFEngineRoadshow

Webhuis commented 8 months ago

Hi Simon,

On 2024-02-17 01:10, Simon Sobisch wrote: As it is currently done all chance history is lost. Can you please click on "fork", either from the original repo https://github.com/OpenCobolIDE/OpenCobolIDE or from one of the existing forks?

Jeroen and I just created a new GnuCobolIDE https://github.com/Webhuis/GnuCobolIDE/tree/master forked from OpenCobolIDE https://github.com/OpenCobolIDE/OpenCobolIDE

Doing so would also allow to use the right spelling #1 [1] in the name.

Then do the rename of the main folder (and possibly README) as one commit, then add either your existing changes over by one or as a single commit.

That has the benefit of providing git history as well as attribution, and would also help people to find it using the fork view of OCIDE repos.

Met vriendelijke groet, Martin.

LinkedIn: https://www.linkedin.com/in/martinsimons1/ GitHub: https://github.com/Webhuis/CFEngine-Roadshow/tree/master/ Twitter: https://twitter.com/webhuis @Webhuis #TheCFEngineRoadshow

Webhuis commented 8 months ago

Hi,

its nice that you are planning to maintain a fork of the OpenCobolIDE.

Also did you think of the dependencies you'd have to maintain? The support of pyqode.core, pyqode.cobol and pyqode.qt has also ceased. And since OpenCobolIDE seems to be the only program to still use these, you would have to maintain them yourself. That would include switching to QT6 (and therefore pyside6).

I did a short review of the first commit in the webhuis GnuCobolIDE and found a few things:

  1. you replaced OpenCobolAPI to GNUCobolIDE, which resulting in getting https://github.com/GNUCobolIDE/GNUCobolIDE/... URLs. You should claim this name and therefore this URL as soon as possible https://github.com/Webhuis/GnuCobolIDE/blob/9a4fe5f5c8e79819a2e5f950983f2c44db57512f/gnucobolide/compilers.py#L109 This also applies to the installation guide, which now consists of commands, which had never worked and maybe will never work, if no one fixes it. Also you forgot the launchpad urls.
  2. Also you changed history here https://github.com/Webhuis/GnuCobolIDE/blob/9a4fe5f5c8e79819a2e5f950983f2c44db57512f/README.rst#gnulinux

I would like to hear about your roadmap for going onwards. Maybe i can help.

Kind regards

Moritz Kempe

GitMensch commented 8 months ago

I agree that the dependencies are important. Not sure if it is useful to keep them separated or directly included them into the main program.

In any case, this issue is "fixed" by the new fork, so closing. Best wishes for going on with that.

Webhuis commented 8 months ago

Hi Moritz,

Thank you for your elaborated response.

its nice that you are planning to maintain a fork of the OpenCobolIDE.

Thank you, again. :-)

Also did you think of the dependencies you'd have to maintain? The support of pyqode.core, pyqode.cobol and pyqode.qt has also ceased. And since OpenCobolIDE seems to be the only program to still use these, you would have to maintain them yourself. That would include switching to QT6 (and therefore pyside6).

Indeed. pyqode is halfway Python3 and I had to convert and tweak it, here and there. I am new when it comes to publishing software through Github, so I created https://github.com/Webhuis/pyqode3 the same way I did with GnuCobol. Somewhere this week, I will fork officially fork pyqode into pyqode3, in order to preserve all the history. I am struggling with this library and I am open to a move towards QT6, but do not yet know how to do it.

I did a short review of the first commit in the webhuis GnuCobolIDE and found a few things:

Sounds like a plan. How would you claim?

This also applies to the installation guide, which now consists of commands, which had never worked and maybe will never work, if no one fixes it. Also you forgot the launchpad urls.

I am new when it comes to publishing software through Github, so I am open to ideas.

I would like to hear about your roadmap for going onwards. Maybe i can help.

I need all the help I can get. :-)

Would you mind having an conference call shortly?

Met vriendelijke groet, Martin.

+31651567029

LinkedIn: https://www.linkedin.com/in/martinsimons1/ GitHub: https://github.com/Webhuis/CFEngine-Roadshow/tree/master/ Twitter: https://twitter.com/webhuis @Webhuis #TheCFEngineRoadshow

Webhuis commented 8 months ago

Hi Martin,

I did a short review of the first commit in the webhuis GnuCobolIDE and found a few things:     * you replaced OpenCobolAPI to GNUCobolIDE, which resulting in getting https://github.com/GNUCobolIDE/GNUCobolIDE/... URLs. You should claim this name and therefore this URL as soon as possible https://github.com/Webhuis/GnuCobolIDE/blob/9a4fe5f5c8e79819a2e5f950983f2c44db57512f/gnucobolide/compilers.py#L109

Sounds like a plan. How would you claim?

By creating an organisation on github with the given name and moving your fork there.

This also applies to the installation guide, which now consists of commands, which had never worked and maybe will never work, if no one fixes it. Also you forgot the launchpad urls.     * Also you changed history here https://github.com/Webhuis/GnuCobolIDE/blob/9a4fe5f5c8e79819a2e5f950983f2c44db57512f/README.rst#gnulinux

I am new when it comes to publishing software through Github, so I am open to ideas.

That's not what i meant. I meant that there are tutorials in the readme file, which were broken by your refactoring.

"yaourt -S gnucobolide" as an example, doesn't work. Because there is nothing packaged with the name gnucobolide. You've changed it in commit https://github.com/Webhuis/GnuCobolIDE/commit/9a4fe5f5c8e79819a2e5f950983f2c44db57512f from "yaourt -S opencobolide". Nevertheless the old package was also deleted, the new one doesn't exist. Thats why just replacing the name in the readme maybe isn't the best idea.

Would you mind having an conference call shortly?

I'm afraid, i am not reading my mails this regularly. Maybe we could switch to a matrix chat?

Kind Regards

Moritz Kempe

GitMensch commented 8 months ago

I agree that https://github.com/gnucobolide/ would be a good organization to claim, at least if the pyqode and chrash-reporter dependencies are also forked there.

In theory I could also create a fork at https://github.com/gnucobol/gnucobolide and give @Webhuis admin and Moritz (would need the github user name for that) commit access to that; but that may be most reasonable if the dependencies are going to be included - I only know of one additional pyqode program and that works only with an outdated debugger branch of GnuCOBOL that is stale and should be seen as "archived". You could either redo your changes (most reasonable if you want to do them different) or I could force-push the current git repo from https://github.com/Webhuis/GnuCobolIDE (oh, in any case you may consider to name it "GnuCOBOL IDE" - case and space, but that's up to you, of course).

Note that https://github.com/gnucobol/ is NOT an "official" GC place, it was mostly created for making sure it isn't taken "external" and to allow mirroring. If//when GnuCOBOL moves to git its main place won't be at GitHub which will then serve as mirror-only for GnuCOBOL development - but you could still use it for gcide.

MoKe12g commented 8 months ago

Just found out, that i was doing an email exchange with an github issue. Wasn't that clear to me.

Anyway, I would like a clean fork of the original repo and adapt it step for step. And without breaking the documentation and all the links included. Then we could also start to write down some goal and discuss them, like what we do about this strange extlibs thing (https://github.com/Webhuis/GNUCobolIDE-scratch/tree/main/gnucobolide/extlibs), i wasn't been able to make sense of yet.