A lot of effort done in forks but not merged in main; why not merge?

[BFH-ktt1]

I took the liberty to browse through forks of our project and noticed a lot of great enhancements, bug-fixes, additions, great ideas, and so on that live in parallel to this project and are not merged into the current version. I find this really a pity as the goal of us is to create an even better logisim that suites your needs. Please consider opening pull request and, when you wish, mention that you want to be marked as contributor to project. Only common effort can make things better, even if the contribution seems to you to be minuscule.

[sderrien]

Hi,

Just saw your message, and I fully agree with it.

I would first suggest that the sentence "Please consider opening pull request and, when you wish, mention that you want to be marked as contributor to project" appears in the readme.md so that potential contributors know how to "enter the game" (note that not all of us are familiar with git/github practice, for example, I did no know until today what pull request meant, and I suspect I am not the only one like this around, that may explain the very few number of merge request).

Regards,

[maehne]

I agree with @sderrien that it would be a good idea to add a dedicated section to README.md explaining the procedure how to contribute to the project. We should also consider to review the forks for fixes/enhancements, which are worth to be integrated into Logisim-evolution and to actively encourage them to submit a pull request. The network graph makes this quite easy.

[sderrien]

This is again my 2cents, but I also feel this project needs much more publicity than what it currently has, because this is a very nice work. To me, the ability to go down to FPGA makes it an amazing teaching tool, and there are many interesting contributions around.

However, when I meet/discuss with colleagues, I find that many of them are using Logisim, yet they never heard about this version and almost all believe logisim is not evolving anymore, mostly because they rely on the tool official webpage. Maybe it could be worth contacting Carl Burch so that he refers to this github on his webpage ?

[maehne]

@sderrien: I totally agree with your observation. We have to improve on the publicity side and we took some decisions in this directions during a developer meeting in December. However, thinks move slowly due to our limited bandwidth.

Help is welcome!

[sderrien]

Here are a few more suggestions (I will be glad to help for any of these two items)

1) Consider renaming the project into something easier to remind (I often heard the following : "oh you told me about this new logisim version, but I couldn't remember its name and there are like 200 forks name logisim on github ... So we decided to stick to the existing one for this new academic year").

2) I'd suggest you create a twitter account for logisim-evolution, and link a few videos showing the new capabilities of the tool. We migh be able to reach students and also "makers/fablab" people who could be interested by the tool as a fast learning cost cross board/FPGA design tool. There is quite some twitter traffic for #logisim.

Regards

[kevinawalsh]

Hi @maehne. I agree it is a shame about the lack of a single definitive source for Logisim since Carl stepped down, and the difficulty of discovering the new features. I've considered renaming my fork several times, but I have some affection for the "Logisim" part of the name, since I've been contributing for so many years, and I figure keeping the "evolution" part was to acknowledge your really helpful addition of the FPGA support.

I'd be perfectly happy if someone were to port some or all of my changes over to your repository or any other fork of logisim. I suspect it would be a lot of work. I do occasionally I pull fixes and new features from your repository over to mine, but our two repositories have diverged quite a bit, unfortunately, so it's not nearly as simple as cherry-picking patches.

Best, Kevin

[maehne]

@kevinawalsh: Thanks for your reply and agreement that your enhancements may be back ported into our branch. I am willing to invest some time to it during the spring after I will have managed together with @sderrien to integrate his FSM editor (see PR #217) into our develop branch of Logisim-evolution. Our version will certainly profit from integrating your fixes and enhancements. Redeveloping them from scratch would be even more costly than profiting from your analyses and code and back porting them with all the support offered by Git in terms of merging code bases. I would appreciate it if you could support this effort by reviewing any related future pull requests. Also, it would be nice if you would consider contributing directly to the official Logisim-evolution version (if the back porting effort should succeed).

Feedback from your side, which enhancements are needed so that you can use our version in your courses, will be taken into account to prioritise the work.

[maehne]

@sderrien, regarding your suggestions:

1) Consider renaming the project into something easier to remind (I often heard the following : "oh you told me about this new logisim version, but I couldn't remember its name and there are like 200 forks name logisim on github ... So we decided to stick to the existing one for this new academic year").

I totally agree with you that the offspring of so many separate forks with different names to carry on the work of Carl Burch causes confusion among old users of the original Logisim as well as potential new users. Therefore, I personally don't see how renaming Logisim-evolution yet again would help the situation. The name choice was very conscious to hint users about the goals of our efforts. What we need is an effort to bring together the community of Logisim variants developers and users and convincing them that a joint development of the software is beneficial for all of them. I think that if we manage to show that it is possible to merge successfully with reasonable efforts the different diverging development branches of the past into a new version of Logisim-evolution, this will be a strong argument. This is the motivation of my offer to help with integrating your and @kevinawalsh's improvements into the official Logisim-evolution development branch. If this should succeed, we can also approach the other forks with a similar offer.

Your initial suggestion to approach Carl Burch with the request to pointing to efforts which continue his initial work. If we gain enough momentum in the development and community building, we may even consider to discuss with him whether we may drop the "-evolution" part and become thus a new official major version of the original Logisim. (You might remember that there is precedence in other open-source projects, e.g., EGCS was a fork of GCC, which was so successful that it later became the official GCC.

2) I'd suggest you create a twitter account for logisim-evolution, and link a few videos showing the new capabilities of the tool. We migh be able to reach students and also "makers/fablab" people who could be interested by the tool as a fast learning cost cross board/FPGA design tool. There is quite some twitter traffic for #logisim.

Yes, we certainly have a lot of potential on the communication and documentation side. Creating a dedicated website is on the TODO list and pro-active communication about improvements in Logisim-evolution over social media channels would certainly help to increase our visibility and motivate the community to contribute to Logisim-evolution. Unfortunately, our time and development resources are limited as it is more a side project to support our teaching of digital design. So, most communication about improvements is done orally in the class room during the labs of our students.

Any help in development, documentation and community building is welcome!

[BFH-ktt1]

Hi all, Sorry for not having participated in this discussion for the last three weeks, but I was completely covered by teaching a master block course :-)

@maehne and @sderrien : Thank you for taking the initiative to integrate the FSM component into the current logisim branch, as this is a very nice feature we are having already long time on our agenda.

@kevinawalsh : I agree with you that cherry-picking might not be the best idea for integrating your work into the current development tree as (1) we changed a bit the source tree to be more compliant with the gradle framework, (2) we took different approaches to solve the same problem, for example the shape of a sub-circuit, you choose for an attribute, whereas we put it as a global setting. I be very willing to pick-up this task and try to integrate as much as possible all the nice features you added in the holy cross edition. I will in this effort have 4 questions/issues: 1) As I will do the modifications by hand using the latest version of your fork, there will not be a direct track that these modifications were done by you as they will appear as my commits. How would you like to handle this aspect? 2) As my time is limited (I work on logisim in my free time) it will take quite some time to go over all the commits you made. In this time, I guess, you will also be working on your fork. How do we handle this so that at a certain moment we could converge? 3) As I stated before, we took different approaches on same problems. This means that in merging the two, some aspects must be discussed to find a solution that suites all parties; however in this aspect I see the risk loosing backward compatibility to both current versions. Furthermore, this will probably also impact all descriptions we made for practical works that we do during teaching, and definitely will impact the current documentation of logisim. 4) I saw in some of your commits that you made some quite specific HDL-generators for a given FPGA board. This is an aspect that is really worth while, but in my opinion should not be put a "generic" generator for the given component, but as "optional" generator that should reside in the description of a given FPGA board. This aspect is unfortunately still not integrated in logisim, and I wonder if you have an idea how to go about that. I would love to hear about your opinion on these topics, and happy to do the work and try to integrate all your nifty features in the current development branch.

@all: There are still a lot of forks out there that have also very nice features, and I will definitely look into them. If you want to help to merge them, please do not hesitate to do so.

[BFH-ktt1]

@kevinawalsh : Could you please review my pull request #228 and #226? I'm especially interested if the Logisim files generated by your Holy Cross edition are now read in without any issues concerning the appearances. Note: the circuit custom appearance is not yet implemented, although it is already in the attribute list. Thanks in advance!

[BFH-ktt1]

At all, I face some issues on merging, could you all please take a look at my pull request #232? Thanks in advance

[MarcinOrlowski]

I'd like to move this thread to discussions. Please object if I miss a reason it should stay as issue ticket.

[maehne]

I have no problem with moving this to "dev talk".