Creating a "pull request" for jvcl

[ByteJuggler 45]

17 hours ago, FredS said:

 

There is a benefit in maintaining your own fork, wish it was simpler to find the most up to date fork though and fork that 🙂

 

Also generating a branch before a making a pull request isn't a big deal as long as one knows about that..

 

Yes.  One of the nice things of open source is that if a project isn't well maintained you can simply "run with it" yourself.  Your fork may well eventually become the de-facto official version, if it should turn out that your version of the code in question ends up consistently better maintained and up to date than the original.  To be clear: I'm not casting shade at the JCL/JVCL project per se here, just agreeing with your point that there's nothing wrong with maintaining your own fork and the consequences that may have, and that this is sometimes no bad thing.  🙂

 

Also as a minor digression, while this does obviously require some necessary conceptual branching understanding and how this is handled in git, it's reasonbly easy to create a new feature branch from a master branch even after the fact to fix the "problem" above with multiple pull requests.  And it's also of course possible to just roll both sets of changes into a single new pull request.  Given that there's some issues with the existing pull request in terms of supported versions (it seems, perhaps?), it seems this may be a fair course of action.  

Edited April 12, 2019 by ByteJuggler

[TiGü 21]

 

2 hours ago, Schokohase said:

It is also pointless to place a pull request if you know that it will break code for Versions < XE3 while the library clearly states

 

The contributer knows it, but did not provide a solution in code

 

2 hours ago, ByteJuggler said:

Especially with new contributors to open source (but also in general) it's usually advisable in the interests of friendly cooperation to exercise some patience and politeness and give contributors some friendly feedback about their pull requests if they should accidentally miss this or any other type of requirement that change requests should comply with (and to do so in the context where the pull request was submitted.)  If the JCL/JVCL maintainers are not giving at least this feedback to people trying to contribute then that's rather a shame.  😞

Especially when younger pull requests are commented and this one is simply ignored.
The maintainers can say: "Ok, that was nice, but come back when you have a version that works with Delphi 6".
But ignoring it completely is not cool. You know the German proverb: "Kannste man so machen, aber dann ist halt K*cke!"

My motivation to ever participate again for the JCL or JVCL is at a minimum.

Edited April 12, 2019 by TiGü

[Guest]

@TiGü 

 

Well, to me your PR is not cool and the missing reaction from the maintainers too.

 

If you want to help then create PR that improve the code base and did not cause some extra work for the maintainers.

 

@Maintainers

If you want to get more help you should stay in contact with your contributers, especially the new ones.

[ByteJuggler 45]

33 minutes ago, TiGü said:

 

Especially when younger pull requests are commented and this one is simply ignored.
The maintainers can say: "Ok, that was nice, but come back when you have a version that works with Delphi 6".
But ignoring it completely is not cool. You know the German proverb: "Kannste man so machen, aber dann ist halt K*cke!"

My motivation to ever participate again for the JCL or JVCL is at a minimum.

Ah, I'm sorry you feel a bit burned.  😞

 

Out of interest and for what it's worth: I had a look at what your patch is for, it seem to me from the StackOverflow discussion that the issue your patch works around is only present in a specific build of Windows and that's there's a fix for it [in Windows] since about a month ago?  The maintainers need to respond and state whether this is the case, but it might be that they don't really want to fix OS bugs in the JVCL, an understandable position to take.  

 

(Aside, we maintain our own versions of some open source libraries as well as Delphi Source because of similar reasons, being that long ago issues remain unpatched in the official source whether due to lack of interest from the maintainers or lack of demonstrability/completeness/quality/testing or whatever of the issue and/or patch on our end.  Sometimes just the way it goes. 🙂 )

Edited April 12, 2019 by ByteJuggler

[TiGü 21]

1 hour ago, ByteJuggler said:

Ah, I'm sorry you feel a bit burned.  

Please, don't feel sorry. My answer was for Schokohase.

But if KB4482887 fixed this issue (without any hints in the official description - tz tz tz), everything is okay.

I try to cancel my pull request.