Push changes upstream?

[emmenlau]

I very much appreciate this repository and the many good changes that you accumulate.
But it raises a bit the question of longevity. What would happen if the projects deviate? How can users discover these improvements here?

To solve these questions, it would be awesome if you could push your changes upstream. For example, it seems your Qt6 support is fully backwards compatible. I guess it should be acceptable in the original repository?

[Daguerreo]

Well, of course I can't push on the upstream, but it's still possible to open MR to the original repository.

About your doubts, I'm doing my best to keep this repo aligned with the original, for instance I would greatly refactor the coding style because there are two mixed styles, but I didn't because would deviate too much with the original codebase. Usually I write in the README the implemented feature and major differences between this and the original repo.

I guess I won't do any big change in this version anymore since v3 is a thing a I would like to focus my effort on that version.
Anyway of course any help is always welcome.

[emmenlau]

Hey @Daguerreo , thanks a lot for the positive response, and also all your work about maintaining this repo, its highly appreciated!

I understand that maintaining merge requests against upstream can be quite a bit time consuming. I'm happy to help as much as I can.

So maybe we could start with some topic already, like Qt 6 support? I think you have a number of related changes that could go into one MR and be promoted upstream? I'm happy to do that, or review and promote the merge request. What do you think?

[Daguerreo]

Well, I have no power there, you could just try to open a MR to the original repo and see if it's merged, it's up to you. Any feature here could be gladly merged there. But I have to point out that most of the additional feature here were based on MR never merged to the base repo.

[emmenlau]

I understand that the original repo is currently not so actively maintained anymore. But this can be a great benefit of your work: Through your repo, more people have used and tested the changes. So it will be easier for the original authors to gain trust in your changes. For example the Qt6 changes are becoming more relevant for all users every day. I think that by now there is a good chance they will be merged.

Would you be willing to open a MR for them?

[tay10r]

I'd making this a separate repository instead of a fork. Forks don't appear on searches, at least when you're not signed into GitHub. I discovered this when I was searching for this fork specifically at work, and could not find it. Original author no longer seems to have time for the project anyway.

[emmenlau]

I'd making this a separate repository instead of a fork. Forks don't appear on searches, at least when you're not signed into GitHub. I discovered this when I was searching for this fork specifically at work, and could not find it. Original author no longer seems to have time for the project anyway.

This completely breaks the spirit of open source. I heavily prefer what @Daguerreo was doing, to keep this repo as much in line with the original upstream as possible. The original repo has 533 forks. No-one can and should search them for good improvements. And much less so create new, independent repos.

[tay10r]

This completely breaks the spirit of open source.

That's a bit of an exaggeration.

I heavily prefer what @Daguerreo was doing, to keep this repo as much in line with the original upstream as possible.

Okay.

The original repo has 533 forks. No-one can and should search them for good improvements. And much less so create new, independent repos.

So you're saying that creating an independent work containing improvements is against the spirit of open source? Nobody should search forks for improvements? I don't understand how you came to these conclusions.

@emmenlau I think you're forgetting the fact that the original author no longer maintains the repository. Nobody has been able to get a merge request complete with that repo in a long time. If that weren't the case, then of course it would be preferable to merge upstream. Since that's not an option, the forks have been the only way to get bug fixes.

[emmenlau]

This completely breaks the spirit of open source.

That's a bit of an exaggeration.

I do not think so.

I heavily prefer what @Daguerreo was doing, to keep this repo as much in line with the original upstream as possible.

Okay.

Thanks for your great work :-)

The original repo has 533 forks. No-one can and should search them for good improvements. And much less so create new, independent repos.

So you're saying that creating an independent work containing improvements is against the spirit of open source? Nobody should search forks for improvements? I don't understand how you came to these conclusions.

@emmenlau I think you're forgetting the fact that the original author no longer maintains the repository. Nobody has been able to get a merge request complete with that repo in a long time. If that weren't the case, then of course it would be preferable to merge upstream. Since that's not an option, the forks have been the only way to get bug fixes.

I do not see this in the same way. The original author has worked quite hard to get this going. And he has engaged in a community where 21 other contributors added code. 92 issues where closed, 115 merge requests merged. That is quite some work that we are now basing our next steps on.

In the past two years, he has been a lot less active, that is certainly true. But there have been commits, so the project is not dead. And who knows what the person may going through right now? Change of jobs? Starting a family? But that does not mean that they will never pick up this hobby again.

The question is where to go from here. For me, it was by pure chance that I found your fork, out of 533 others. Even if it becomes an independent repo, it will for years not rank as high in google or github as the original repo! So the majority of users is not even aware of your (great) work. And that is a huge waste of resources.

And you will also not carry this flag forever, I guess. Maybe you move on in two years, maybe in three? By then, most forks will have a few commits ahead of the original repo, but nobody will be able to unite all this great work ever again.

This is why I think it breaks the spirit of open source. There is no community forming here. But a community should be at the heart of every open source project.

What is the alternative? Provide good help to the original author. And let others do the same, when we move on.
I think the original author is more likely to accept well tested contributions. And your changes @Daguerreo are now more well tested. For example, in paceholder#288 (comment) the original author said to merge your Qt6 changes. Was there a specific reason why this was not carried forward? I would first go this route again. If that does not work, maybe the original author would accept contributors with merge permission, if kindly asked? There are more ways forward here.

[Daguerreo]

Would you be willing to open a MR for them?

Sorry but I won't. I already tried several times with differents MR but those stayed there for months, then I got pissed and I deleted them since I was just wasting my time. This doesn't mean MR from this repo can't go in the original, I'm just saying I'm not doing it myself. I onestly think it's just a matter of cultural barrier, but it's just my opinion.

The original repo has 533 forks. No-one can and should search them for good improvements. And much less so create new, independent repos.

This is what I actually did LOL. I found 3 different incomplete attempt of the dynamic ports which I used to deliver the complete feature. Same goes for the pri files. Out there there's a nice rework of the styling (which should be really needed), but it breaks too much the compatibility.

I even checked all the PR and most of those are poor work, but instead of leaving those opened forever he should close it or state clearly the work it's not good enough to be merged, but again, maybe it's just a cultural matter.
For instance, one of those MR was an undo feature, I tried it but it has a poor design and a sneaky bug, it should be implemented using the QUndoCommand instead and it should be a great feature.

@tay10r it's not true the original repo is dead, he's trying to continue to develop it and you can see from the work of the v3, which is actually great and I really really would to develop in that branch, but I don't have much time right now.
I mentioned the undo stack before, it should be easier and more obvious to implement it in the v3 rather than in v2, but it needs more time to learn the structure of the new version (that again, it is great)

[paceholder]

Hello there,

I accidentally came across this thread. I am not dead, as some might have supposed. Just a matter of lack of time.
The version 2 is quite crappy and I do not want to loose time there. In the version 3 I already have a functional model-view approach, headless mode, Qt6 compatibility. Just need to rewrite some leftovers like save\restore, fix CI, fix tests.

I will happily accept PR agains version 3.

Dynamic ports are not that easy as it might look.
I haven't seen a good implementation yet that does not crash in all the edge cases and is useful enogth.

@Daguerreo I think the cultural barrier here is in discussing my personality without inviting me.
If you want to help, please check and fix, for example, the CI scripts for Qt6 for the version 3.
I am still waiting for the promised PR with clang-format config (since Aug 12, 2021). Sorry if I missed that.
Take it as an official invitation for contributing to the version 3.

I'll delete all the further comments like "this will never be merged because the author doesn't respond me immediately, better take a look at my fork".

Best regards,

Dmitry

[Daguerreo]

@paceholder

I accidentally came across this thread. I am not dead, as some might have supposed. Just a matter of lack of time. The version 2 is quite crappy and I do not want to loose time there. In the version 3 I already have a functional model-view approach, headless mode, Qt6 compatibility. Just need to rewrite some leftovers like save\restore, fix CI, fix tests.

As you can see I pointed out you're still working and they should provide the support for the MR to your repo. If I may say, you should state this clear intent about v2 and v3 in your readme or in an issue. That should be make clear for everyone where the project is going to.

I am still waiting for the promised PR with clang-format config (since Aug 12, 2021). Sorry if I missed that. Take it as an official invitation for contributing to the version 3.

I did it but I stopped because I reached the same conclusion you just said, "don't loose time on v2 and focus on v3". Since it was done for v2 it would lead to a dead road. I'm not able yet work on v3 mainly for the lack of time to study it so I'm still not able to make a complete working example with a custom graph model. In addition we don't know what you've have planned or what it's still missing or what you would like to add and in what priority, so it's a bit difficult to give you help for v3. Out there there's several people that will be glad to help, so please give us the tools to do that.

[emmenlau]

Thanks again for all the great work from all sides. I'll close this issue as its now outdated! Happy coding!