Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Ceylo

Pages: 1 [2] 3 4 ... 69
16
Providing an option for it means supporting it. So if it's not supported, then no option for it. Both must come together. Even if I understand that it is annoying for people with "old" devices.

17
https://developer.apple.com/news/?id=06282017b

SFML iOS support is still in development, iOS 11 doesn't support 32 bits ARM anymore, all devices since 2013 or later supports 64 bits. So even if it was possible to also support 32 bits, it's just not worth it.

It's really more a matter of "what's worth it" rather than "what's possible" (at least for now).

18
Hello jwurzer,

You should note that your iPad is unlikely to be supported by the official iOS release if/when it comes out: 32 bits support was recently removed because it is useless for apps that would be submitted to Apple's App Store today.

So you're currently lucky that the dependencies used for the iOS build still contain both 32 & 64 bits ARM architectures. 32 bits ARM data may be removed from these dependencies at any time.

19
Thanks for pushing things forward Hiura.

@eXpl0it3r @Laurent
After a step back I'm really puzzled about the fact I had to convince you on "why" it is a good idea to have PRs merged more efficiently. And it seems like you're still not convinced. I would have expected that the discussion would only be focused on the "how" and not the "why".

20
I'm not sure I follow. What I meant was that our CI would, in addition the existing tests, test the code after a local merge of the branch into master and, if any of the tests fail, the CI bot could emit a message on github with the error details.
I misunderstood, what you describe looks nice :)

Did you mean that the CI should automatically merge things? That'd be inadequate for the simple fact that the tests currently consist only in compiling the code. This won't indicate whether a bug was fixed or a feature correctly implemented.
No, I didn't intend to go that far.

It's not really a matter of trust, although if every kiddy can mess around our boards it would be a mess, obviously. But I think it absolutely makes sense to keep this board in the hands of a few. Why? Because, like a real company, not all developers are project managers and those are the only one that should organise priorities, IMO. The same applies, less critically, to tags in the end.
Well the developers could update the board to update status about what's ready to be reviewed, etc. Without changing priorities. Anyway it doesn't look like it could be used efficiently by PR authors to give visibility about PR needing testing/review so let's forget this.

[...] a couple of quick thoughts: [...]
I don't have any opinion on your ideas but thanks for the input!

21
[...] having CI also check the code after merging changes into master would help identify issues. I think it should be possible to configure a bot to report simple but helpful instructions for contributors (e.g. Please rebase your code).

Of course, if we agree on such changes in the infrastructure we would need people willing to help implement those changes. ;)
A reminder is still an improvement but a small one. What would really help would be the automatic test with merge. I guess it depends on the CI itself, so the first step would be checking whether the currently used CI system does support this. If we have to implement it ourselves it's not worth it to me.

Also, what would be the added value for contributors? It's just a tag, helpful for searching, but not influencing the discussion happening in the PR.
That's the point, easier searching. But no need to care about it if we go with forum solution or if we can get people used to the GitHub Project page.

This is a very unrealistic goal, as we simply won't have the resources available right within that time frame to do in-depth reviews and testing on 3-5 different platforms.
For sure we don't have the resources at the moment (or at least we don't see them) but I disagree when you say it's not realistic. Of course this is subjective so let's move on.

To me it seems you're not aware of the GitHub Project (sort of Kanban board) that we (or mostly I) maintain: https://github.com/SFML/SFML/projects/2
I've seen it but I don't consider it to be a usable tool unless any PR author can change it, which I guess you don't want so that you can keep control. Probably a matter of trust. Again the purpose is to make the list of PRs ready for review/testing visible immediately, not to depend on someone from the core team for that.

As soon as a PR hits the "Ready" section it will be merged the next time I get around to merging things, unless someone in the meantime raises some concern and "Review & Testing" PRs require additional community attention.
Could you give a ratio of the PRs where someone has actually raised a concern during this "Ready" stage? On all the PRs I've looked at I don't remember any where there was a concern, but maybe I just didn't take a representative sample.

What's the reason that "merging as fast as possible" is so important to you?
So as I already stated
Quote from: Ceylo
During that time I refrained from helping on other matters, because I didn't want to pile unmerged work up, I wasn't sure it would be merged at all, and it was rather demotivating to get sparse feedback.
Additionally here are a few other reasons:
- Dependency: when a PR is pending, other changes I do may conflict with my previous changes, and I can't always predict this and thus create my next branch from the pending PR branch. Also if I create the branch from the current pending PR branch, I risk basing my work on stuff that won't be merge. And I can't tell in advance whether the PR will be refused, although it's usually unlikely.
- Shipping the value to users: unmerged work is not available to users, so with slow merging you're constantly wasting time for the people having the issue that would be fixed by the PR. This is also valid for the PR author himself: if he fixed an issue related to the development environment, you're keeping him in that problematic environment

If this is reason you want to get stuff merged faster, then that's really just an issue on your end. If you don't want to deal with multiple PRs at once, then that's fine, but you can't just put the blame on the process.
Well if it's an issue for any/some contributors, then this is your issue. Because without contributions SFML dies. I'm just one contributor among many others, but I don't think telling "this is problem with you only" is gonna help with motivation and contributions :) .

As for feedback, it just takes time, especially with such a large change. There aren't hundred of people just waiting to test and review and of the people that are there to help, only a handful will be familiar enough with CMake to give this a fair try. Then you have Windows, Linux, macOS, iOS and Android that these change affects in some way. Not everyone has access to devices that run these OS or have the knowledge to operate them properly.
In my books 2 months of testing and feedback is quite realistic for the given change set.
Of course reviewing and testing takes time. But it for sure shouldn't need 2 months.


To "fix" this we would need an easy way to see the list of PRs that are waiting for review. [...] or a forum section with a topic per PR needing review. This last solution looks maybe overkill but the advantage is that it's visible from all SFML forum members that would visit this section, and if people want to help on SFML development by reviewing, they can know where to help in an easy way. If we go this way it should be the PR's author's responsibility to open the topic in the forum section, so that it's not more burden for SFML core team.
We actually had an internal discussion about this many moons ago and sort of agreed to do it, but then never actually did it.
Interesting to know!

I don't think we can have a fixed number on who has to look at what, because it really depends. For a minor change for example, it really doesn't matter if someone from the community tests or reviews this, but when you get API changing stuff, we really do want SFML Team members to sign-off on that.
As usual, the more help the better!
Ok.

Plus we need to consider that simply changing the process doesn't guarantee in any way, that suddenly more people will actually spent the time to review and test pull requests, [...]
What's sure is that not changing anything won't make more people come help :P

Things we already have setup
For curiosity, do you know if anyone is using the GitHub project apart from you? (NB: I'm not implying it doesn't make it useful, even if you were the only one using it)

22
Ultimately my feelings is that the whole team wants to ensure SFML keeps a high code quality standard. It's part of its 'personality'. That's why I suggest we request the final approval by a team member. My hope is that with more feedback this will go much faster as grey area in the code would already have been discussed.
Agreed.

Your suggestion for adding a tag and putting more light on those blocked PR is a good one, I think.
I really insist about the fact that the PR creator must be able to set the tags himself (if we go for the tags solution). It’s important that there is no need to wait for anyone from the core team to set the tag, and that we don’t wait for the PR to look blocked : the tag should be set as soon as the PR can be reviewed.

I've tried promoting a few of my PRs on the forun a while back. Sadly, it didn't work. It also adds some work.
Was it mixed with other topics or in a dedicated section? To me it’s really important that people who help by reviewing or testing can do it without searching for these topics. There should be list that shows where help is wanted. Topics in a distinct section is one possible way to expose this list.

As for the additional work, if you consider that the PR's author does it, it's not more work for the core team, and only a little bit more for each contributor.

Maybe we should instead regularly advertise that people can subscribe to github issues if they want to contribute. But in any case, people can always open a thread for a specific PR and attract the attention of the community.
I'm afraid we won't get results if we can't make this become a habit, I mean the people who'd like to help would maybe not get used to help if a topic requesting help is created only sometimes. You could think of this as virtually creating an easy workflow for people who want to help.

Currently merging is done in batches to make rebating less tedious. If we merge a PR everyday or so, every other PRs need to be updated. So we have to find a tradeoff.
"rebating"?
Why do other PRs need to be update after a merge? Because you're not confident that once merged, even if there is no conflict it could break builds? I can't remember how it's called but the CI could check 2 things, the current branch state (what is currently done), and create a temporary merge commit (by merging from master into the PR's branch) and provide build results for this situation too. This way you remain 100% sure the PR can be merged without breaking master, and the PR authors don't need to update their PR. Then you don't need PR batching. This is more load for your builders but it seems like it could handle it. More computer time and less human time.

From my outside view visibilty is a problem and the process is not so clear at all. There are SO MANY issues in the tracker!
Not willing to upset you but the PR process is already big enough to deal with, so let's remain focused :) If you want to talk about GitHub issues you should open a distinct thread.

1. eXpl0it3r is amazing at managing tasks, I wouldn't say he is the bottleneck, and I think having more people involved in this process would just make it a big mess -- unless eXpl0it3r is fed up and wants some help, of course :)
I agree eXpl0it3r is doing an amazing job. But if PRs wait a full week to be merged there's still something wrong. For now I still don't know if the delay if because of batching or because the free time of a single person is not enough so will wait for eXpl0it3r's answer on this matter.

2. Reviewing and testing needs time, I don't think there's any good reason for rushing to merge a PR as long as  it is still active. The problem, in my opinion, is when PRs get stuck (or worse: forgotten) because there's suddenly no one to test or review it.
Nobody talked of rushing :) only being more efficient to reduce the time between when the PR is opened and when it is merged. Which most likely implies sharing more work with the community.

3. We've already tried various strategies for getting more people involved in the review & testing process, but they all failed. The truth is that only the author of the PR and, with some luck, one or two SFML team member, really cares to actively work on PRs. Others just wait until it's done and available.
Can you give more details about what you tried?

4. Unlike you, I think we're doing a really great job at handling issues and PRs. Issues and PRs are submitted quite frequently, and so far we've been able to handle them, allowing SFML to remain active and evolve even without the team members working on it. Compare the situation to what it was before: I think we've made huge progress.
I'm not saying you're not doing a great job. You do a great work with current team. But that doesn't mean it (the process, not your work ;D ) is satisfying from PR authors point of view, because of the delays mentioned above. I don't know how the situation previously was so I believe you about the progress.
But let's take my last PR as an example (although it's an extreme case) for which testing took 2 months, where probably 90% of that time is waiting for feedback. During that time I refrained from helping on other matters, because I didn't want to pile unmerged work up, I wasn't sure it would be merged at all, and it was rather demotivating to get sparse feedback. So what you seem to consider a good enough process means that I could have contributed more or less 3 times more to SFML in the same time range. Up to you to consider if it's worth it.

So the only problem is the lack of testing & review from the community, and in my opinion this cannot be solved. People who want to help already do it. There's nothing we can do to force others to get involved.
Waiting for your answer on 3. before answering this. But yes there are things to do, and you can't force people to get involved, but you can motivate them.

23
Hello,

I'm opening this topic because I feel like current PR submission process is not efficient and I believe this is discouraging people from contributing more (at least it discourages me).

To give a few numbers:
PRTesting & feedbacksWaiting to be merged
#13352 months2 days
#137112 days7 days
#13612 days10 days
#13343 weeks7 days
#1377~10 days*7 days*
#13952 days4 days
#13844 days3 days
#13562 weeks1 day
#13502 weeks0 day
#13452 days7 days
#13427 days7 days
* there was no feedback so not easy to tell if any testing phase happened and for how long

I hope this is representative enough. Of course I made this table mainly because I'm somewhat traumatized with the 2 months testing phase on my PR, that was mainly waiting and no feedback. But it's not the only PR in this case (at a smaller scale though).

There are several cases:
1. there are feedbacks and changes are required -> to me this is not an issue, so let's not focus on it
2. there are no feedbacks
  a. on (code) review -> should be improved
  b. on testing -> should be improved
3. PR is ready to be merged (code review, testing, feedbacks and CI are ok) but still waits to be merged -> should be improved

Of course I understand that the SFML core team can't do everything right away, and this is not what I wish. So here are a few ideas to help on these matters.


2.a : I don't know what are the current rules. Should the (code) review be done always by at least a SFML core team member, or can it be done by any member? In both cases my personal feeling is that currently the PRs that are blocked by a (code) review are not visible in SFML's PR list. The tags in https://github.com/SFML/SFML/pulls don't look to give this information.

To "fix" this we would need an easy way to see the list of PRs that are waiting for review. I can see 2 ways of doing that: a new tag on which you could filter on, on SFML's GitHub, or a forum section with a topic per PR needing review. This last solution looks maybe overkill but the advantage is that it's visible from all SFML forum members that would visit this section, and if people want to help on SFML development by reviewing, they can know where to help in an easy way. If we go this way it should be the PR's author's responsibility to open the topic in the forum section, so that it's not more burden for SFML core team.

2.b : Same questions about current requirements on testing. From what I saw it depends on whether the change looks "safe" or not. If it's safe testing is skipped, apart from CI. When testing is needed, can it be done by anyone or should there be at least 1 tester from SFML core team? Again this is very similar to 2.a. And we could most likely apply the same solution.

3. I noticed that only eXpl0it3r is merging the PRs. Why? I would expect that at least all members from the SFML core team could do this. Also I wonder if there is currently a minimal wait time before merge (I remember there were notices like "If nobody is against this PR withing X days it will get merged" in the past).

The goal would be for any PR that don't need updates (ie. only review and testing time) to be merged within at most 2 days. This is of course not doable if parts of the process can be done by too few people, but totally doable if the process is scalable.

Ceylo

24
Window / Re: How to make the entire window draggable?
« on: March 24, 2018, 12:18:52 pm »
Don't you think you're doing a lot, and inviting yourself to many issues just because "with sfml and windows my application is blocked while resizing or moving" ?


25
General / Re: Help automatically specifying LD_LIBRARY_PATH ?
« on: March 19, 2018, 11:45:08 pm »
Runpath search paths really is the way to go if you want SFML to be automatically found.
You should check https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html#//apple_ref/doc/uid/TP40008306-SW3 (section "Using Run-Path Dependent Libraries").
With this you can save in your exe where the OS should look for its dependencies (usually inside your application bundle). And the paths to look for can be relative to your executable if you make use of @executable_path or @loader_path.

Note that you don't *HAVE* to create a bundle application, if you set the runpath search paths correctly you'll be able to run your executable without changing LD_LIBRARY_PATH. But bundle applications are what most macOS users expect, because they prefer to see a single "file" (ie. application) rather than an executable and a bunch of files/directories next to it.

26
General / Re: FindSFML.cmake users, help test the new SFMLConfig.cmake
« on: March 13, 2018, 08:59:22 pm »
Up!
Testing is done on Linux and macOS but we're still missing someone for Windows. If anyone could help unlock this PR… :)

27
SFML projects / Re: ALAGEngine - 2.5D Isometric Shading Engine
« on: February 26, 2018, 05:20:02 pm »
I really like the rendering of your scene, both realistic and simple enough :) I’m having a hard time understanding why not use 3D though. I know very few about making video games so don’t be surprised if my questions look basic :-°

Quote
And why not 3D ?

The first answer that comes to my mind is very simple: I can't do low-poly 3D mesh. But I can do messy hight-poly things. Hence it means I can make my own assets.
What do you mean with messy high poly things?

Quote
Moreover, I really loke the old-school looj that the 2.5D iso gives.
Finally, it's really fun to develop, and it allows to do interesting optimizations (but it's more costly than simple 3D or classical 2D).
Do you mean costly on development time or at runtime for rendering ?

28
SFML development / Re: iOS development progress
« on: February 23, 2018, 01:09:12 pm »
@Jonny : Whichever you prefer :) I have both but I’m used to using none so.. only disadvantage I can see with IRC (from what I understand about IRC) is that you’d lose the messages sent to you while being offline.

Apart from that I’m away for the next days AND I don’t wish to continue on iOS as long as this PR isn’t merged (it needs testing from users), because I feel like I’m accumulating too much unmerged work atm.

29
SFML development / Re: iOS development progress
« on: February 19, 2018, 08:24:54 am »
It may be the same issue indeed. I’ll change the clear color of the window example to be sure, because with a black background I can’t see the display frame :D

30
SFML development / Re: iOS development progress
« on: February 17, 2018, 07:20:20 pm »
Now I have the "window" example that launches and runs "correctly". It displays the cube, but orientation handling looks wrong, and it doesn't take advantage of the whole screen (on iPad it shows a x1/x2 button to scale contents, booh!).
"pong" and "opengl" also launch but stop because of missing image files for now.

The whole point to not stay with a black screen was including <SFML/Main.hpp> in the example's main file. To avoid further issues with this I added a check in SFAppDelegate.mm, so that this doesn't go unnoticed.

Pages: 1 [2] 3 4 ... 69
anything