Is the C# target still maintained?

1

Hey there,

I created a pull request into the hxcs project over a year ago Reverse logic of finding mono compiler when no version is specified by sebthom · Pull Request #33 · HaxeFoundation/hxcs · GitHub . So far I have not received any feedback by the maintainer which I believe is Cauê. This is very discouraging. If the HF actually is interested in working with the community then communitycontributions should be treated respectfully - which includes not to leaving PRs starving for ages without any proper feedback.

Maybe it would be a good idea to introduce some formal PR handling/tracking policy meaning if PRs are invalid or incomplete at least some feedback is given within let’s say 2-4 weeks. If the named issues are not addressed by the creator within a given time then the PR will be closed.

Same issue by the way with the main haxe project where also three year old PRs are lingering around.

Cheers,
Seb

6 Likes
2

I agree.

Same thing is happening for record-macros , some PR are waiting since more than one year without any feedback.

At least, if HF can’t/doesn’t want to manage decent feedback delays on PRs for some repos, it could be nice to make a call for new maintainers… otherwise these libs/targets will slowly die

3

Hi there. I’m the C# maintainer and it’s been indeed harder to keep a regular contribution schedule. I’m still battling to find a good balance between work, open source and family, as most of my contributions to Haxe have taken place during my spare time.

On the note of respectfulness, I would like to remind you that we at the Haxe Foundation do what we do mostly out of love for Haxe and its community. I think it would be fruitful if the tone were different, as the way you talk in these posts doesn’t help.

I’ve taken some time to take a look into your PR.

3 Likes
4

Hopefully others will correct me if I’m wrong here, but my understanding is that, in general, for community-driven open-source free-software projects like Haxe:

  • current maintainers are already working as much as they can on the project. The most recent Haxe Roundup num 446 says there were 73 commits made to the Haxe compiler in the past couple of weeks!

  • there is a permanent implied “help wanted / join in!” sign out on the front lawn. :slight_smile: That is, afaik, there is never a time when there’s not a call for new contributors (additional maintainers).

That said, for the case where someone has submitted a PR and they’d like someone to look it over and sign-off on it, but no one’s available, I don’t know the answer. I’m guessing that a main part of the solution is to make it as easy as possible for a reviewer to review + approve it. So, my guess would be, if in addition to the PR’s code changes, there’s also

  • tests
  • doc updates
  • clear rationale, and
  • maybe even having run the code through a formatter to ensure it matches the rest of the project.

Maybe the Contributing doc could use a “Before Submitting Your PR” section containing more explicit details to make the reviewer’s job as easy as possible?

3 Likes
5

Thank you for the kind words!

It’s unfortunate that if you provide something for free, people start taking it for granted and feel entitled to it. Most of our contributors work on Haxe in their free time and that should never be taken for granted!

As for your suggestion, I don’t mind updating the contributing doc. I’m not sure if anyone actually reads these, but it certainly won’t hurt. So if you send a pull request to update it, I promise to look at it within a year. :wink:

1 Like
6

@bubar : record macros have been moved out of std lib for about two years now. We don’t have a specific maintainer for it as it’s no longer haxe-core and we have way too many things to handle already, but we’re all in favor of giving invested people the ability to contribute. So if you’re interested in becoming maintainer over this lib, don’t hesitate to tell us.

7

Hello!
Don’t swear, guys. Let’s finding some solution.
Isn’t @seb did his PR for free too? He is not just talking (like me), he is doing something. It’s important.

As I see, HF has too small team, so you guys do not have a time to review and accept PR’s. But! I don’t know how, but you need to accept PR’s, because people do it for free as you, people trying to improve Haxe for all us. And it’s unfair if their work will just die.
Maybe you can spend up to 10% of time for PR’s and not for own commits. It may improve Haxe in general, because community will help you with it.

Because nowadays you guys almost alone. And community want to help. But community can’t do this, if you not accepting PR’s for years.

Also, maybe you can create (I know it’s a time, but anyway) a docs about how to work with sources (with step by step instruction about how to compile sources, for example). Not only for Haxe itself, but for hxjava, hxcs, hxcpp too. Maybe you can ask to community, who already has an experience with sources to help with this docs.
Then other, new people can join and help you with all that stuff. Then you guys will not be alone.

Also, do you still looking for the compiler developer? Your team is small, but it looks like you don’t do any active searching anymore.
I can advice you to post a vacancy on the platforms like Glassdoor or AngelList. Maybe then you find good a developer for this job.
Because HF blog is not a right place to find someone (and OCaml forum is almost dead too).
If it is hard to find OCampl developer, maybe try to find an experienced developer without knowledge of OCampl, but with readily to learn it.

And one more important thing. You really need a good evangelist. Maybe it is more important then compiler developer. He should help to popularize Haxe. He should visit tech events. There is a lot of JS events everywhewe in every country. And Haxe doing JS very well. So JS developer should know about Haxe.
It’s important, because the more people who know about Haxe, then more companies may use it and then more chances for financial grow of HF.

Also, I can suggest you to stop associate Haxe with games. Because games is a small niche of software development. Small games is a way smaller niche.You will never be a giant company if you will stay in that niche. Because there is already Unity, UE and C\C++.
So the solution I see is to associate Haxe with software development in general. Haxe has a Java target. Let’s talk about android development with it on Android conferences. Haxe has great support of JS target, so let’s talk about React, Vue and similar things and how Haxe can help developers experience to use this popular libraries. And let’s talk about it on JS conferences.
This is a work for evangelist (or PR manager). And it is a very important position.

It’s important: I’m not blaming HF. You did a great job, and you keep doing it for free. Thank you for that.
I’m just trying to help you to find some solution for this situation.

And I’m apologize about offtopic here, sorry.

3 Likes
8

Hi Dmitry.

I realize you’re not blaming HF, and only want to see its success. Please don’t feel that this reply is targeted directly to you! :slight_smile:.

This is probably obvious, but I think it bears repeating: since Haxe does not have enormous commercial backing, nor did it serendipitously find itself positioned in some killer app (like being the default browser scripting language), it of course prospers on the grassroots efforts of its contributors and users.

Java didn’t need to be awesome, or have grassroots community support — it had gobs of commercial dollars behind it. Teams of developers. Ads in trade magazines. Heavily sponsored events. Nowadays, Swift, Dart, TypeScript all have paid teams working on them and giant corps behind them. Like Java before them, they don’t need to be awesome or have community support. Kotlin is not quite in the same category but is in the ballpark.

Fwict, Haxe survives by more traditional means: by being awesome and by having an awesome community of contributors.

This is why (I think, I hope!) substantial design problems in community-focused/supported projects tend to be fixed earlier, and have breaking changes (or at least a solid deprecation policy) more often. They can’t afford to not be awesome!

Haxe uses its grassroots support to its advantage. Rather than tying up valuable resources and time finding, placing, paying, and supervising people for various jobs, people just come forward — out of the woodwork — and start helping! They materialize out of thin air and fix things they need fixed. Such is the great and terrible power of grassroots community support. :wink: Although it’s not written down anywhere I can see at the moment, the overall happy system at work is this:

  • The core devs focus on making Haxe awesome and easy to contribute to.
  • If you (meaning, anyone in the community) want more user group meetups, go to meetup.com or elsewhere and start one. Same with talks at non-Haxe conferences: be the one to do them!
  • If you want less focus on games, write your next non-game app in Haxe, and blog about it!
  • If you want more evangelizing, go out and evangelize (on HN, reddit, StackOverflow, your blog, etc.).
  • If you want more businesses to use Haxe, just start using it at work to do some small side tasks.

It all creates a virtuous cycle driven by that community support.

So, I’d suggest that a fruitful path forward is to ask, “How can we make Haxe easy to contribute to?”, thus freeing up core devs as much as possible to work on core development.

6 Likes
9

Hi John Gabriele,

while you are making very valid points, I feel you are not addressing the main point of the Threadstarter. Like Dimitri was saying: the Threadstarter is trying to contribute and trying to get a PR approved. He invested his time to help improve the project. But its PR is ignored. I don’t think that is a too high expectation in a open source project.

10

Opening a PR and then publicly complaining about it not receiving attention is the open-source equivalent of saying “No offense, but …”. I don’t understand how you guys think this helps with anything. If you genuinely care about issues like this being resolved, then this approach is counterproductive.

Anyway, the PR in question has been merged. So to answer the original question: yes, the C# target is still maintained.

1 Like
11

This specific PR because it was made in a hxcs specific repository that is mostly handled by Caue for C# target, and other team members are mostly working on the main repo (GitHub - HaxeFoundation/haxe: Haxe - The Cross-Platform Toolkit).

Here, you will be able to see several pending PRs, some dating from 2016, but these are mostly opened by core team members for internal discussion / testing, and I guess we could close several of them now because they are no longer relevant.

There are some PRs there that are community contributions, but they all seem to have been discussed and not merged because they are valid comments about not doing it. See Add support for toString metadata. by abeaumont · Pull Request #6894 · HaxeFoundation/haxe · GitHub and change ipv6 first,ipv4 second. by hpgood · Pull Request #6142 · HaxeFoundation/haxe · GitHub for some examples. And that’s only a few compared to all PRs we handled over time (Pull requests · HaxeFoundation/haxe · GitHub)

Now back to the original HxCS PR, it is right that for some platforms we have a single person that is in full capacity of maintaining it. For instance even as Haxe original developer, I have not myself a C# user so I don’t know enough the details of the platform to be able to contribute to the specifics of it or evaluate the usefulness of such PR. That’s not something that HF can fix easily, because as it was stated several times already we don’t have the budget to hire a full team with one person working full time on each target.

However thanks to the way Haxe compiler is designed, most of the work we do in terms of new language features etc does not imply work on each individual target.

3 Likes
12

I’m new here, and don’t know your development practices, and am not experienced in evaluating PR’s, so I couldn’t possibly presume to…

Ok! Couldn’t resist. Maybe something like: Contributing doc, guidelines regarding PR's by uvtc · Pull Request #7409 · HaxeFoundation/haxe · GitHub

1 Like
13

Just want to state for the record, that I find that all maintainers are doing an amazing job in general and I think it is quite extraordinary how far everybody pushed Haxe. Even though I am not using it very often I always find it interesting to follow its development and I am hoping for a successful future for the platform.

14

I absolutely love this! Thank you so much!!!

1 Like
15

Hello,

Well, yes i’m candidating for record-macros maintenance :slightly_smiling_face:

Maybe @jonasmalacofilho , @jasononeil would also be interested to get rights on the repo ?

… And sorry for the tone of my post (which has been written too quickly I admit). I didn’t want to blame anyone, but just trying to point out an issue which was blocking further contributions.

4 Likes
16

Yes, I would like to help maintain record-macros. Tora too, if I can.

4 Likes
17

I thought you already had access to that anyway. Just sent you an invite. Thanks!

3 Likes
18

Got it, thank you!

I´m really happy to be a part of the team, even in this small role.

1 Like