Hi all!
Let me invite you to the May 2018 meeting, taking place this Thursday, May 31, 2018 at 19:00 UTC. Invited members will again receive their credentials shortly before the meeting.
Based on requests and current topics, the agenda looks like this:
1. Status Reports ============== Like last time, participants are requested to just post their prepared reports again to not waste any minute.
2. Improving our handling of PRs and JIRA reports ============================================== The global JIRA permissions have been changed this month and there has been a lot of bad blood regarding issues marked as "trivial". On the one hand, trivial PRs waste a lot of time of our core developers as long as they are the only ones able to commit them. On the other hand, trivial PRs still add minor improvements to the code, so it would be wrong to just close them as invalid. Let's have an open discussion on this topic and try to establish rules we can all work with without taking this problem to a personal level.
3. Google Summer of Code ===================== This will be the first meeting, which could be joined by our GSoC student Victor Perevertkin. If he or the mentors have questions that are better discussed with all developers in the monthly meeting, let's do this here.
4. Changes affecting base addresses ================================ Robert Naumann has requested adding this topic to the agenda. He couldn't merge several PRs translating .mc files, because that would blow up the kernel and require a regeneration of all base addresses. He requested a brainstorming session in this meeting to get to a conclusion how to deal with this problem. I know that Joachim Henze has also attempted to change base addresses lately to fix Photoshop CS2, so this is probably the right time to deal with this problem.
Further topics can be requested by replying to this mail. See you all on Thursday!
Best regards,
Colin
Good day,
just as a suggestion for this or a following meeting (I'm no "core developer", so I can not attend to it):
Additional topic: "Get the demo laptop running completely and add it into our testbot"
As the main lesson learnt from the CLT18, we have almost no visible advantages (albeit we progressed very well in the last years!). Most people complained that we dumbing almost at the same level as years ago - and lost interest.
This is particulary bad as most things are already at the 90-100% level.
So my suggestion is to get the demo laptop (the Dell D531) running to a stage that "normal usage" can be demonstrated:
* Browsing the internet (already possible) * (Libre or Open or MS) Office working * 2D and simple 3D games running * Have the ATI driver running for decent performance (From my experience at the CLT, I think this is at the 90-95% stage - see https://jira.reactos.org/browse/CORE-14464 and the root issue https://jira.reactos.org/browse/CORE-10456 (which has already patches provided by vga1) * Sound (listening to music ("works seldom") * Access to a NFS server (already working, but not tested on real hw) * (unformated) printing (already working) * usb thumb sticks (already working with patches)
I would like having this on the next CLT so we can indeed show the impressive progress.
I think the main stumbling is the lack of automated tests on the laptop. So I would suggest to enable one of the laptops to do automated testing. At one point, ros could even be booted via PXE, so it should be fairly easy.
Either we could put it into the data center rack, or I'm willing to build and host such a setup at home. Either way, I'm willing to donate a IP KVM switch and a network power switch to make such setup possible.
Best regards, Michael Fritscher
P.S. Timely speaking, I've time tomorrow.
Am 2018-05-28 09:15, schrieb Colin Finck:
Hi all!
Let me invite you to the May 2018 meeting, taking place this Thursday, May 31, 2018 at 19:00 UTC. Invited members will again receive their credentials shortly before the meeting.
Based on requests and current topics, the agenda looks like this:
Status Reports
Like last time, participants are requested to just post their prepared reports again to not waste any minute.
Improving our handling of PRs and JIRA reports
The global JIRA permissions have been changed this month and there has been a lot of bad blood regarding issues marked as "trivial". On the one hand, trivial PRs waste a lot of time of our core developers as long as they are the only ones able to commit them. On the other hand, trivial PRs still add minor improvements to the code, so it would be wrong to just close them as invalid. Let's have an open discussion on this topic and try to establish rules we can all work with without taking this problem to a personal level.
Google Summer of Code
This will be the first meeting, which could be joined by our GSoC student Victor Perevertkin. If he or the mentors have questions that are better discussed with all developers in the monthly meeting, let's do this here.
Changes affecting base addresses
Robert Naumann has requested adding this topic to the agenda. He couldn't merge several PRs translating .mc files, because that would blow up the kernel and require a regeneration of all base addresses. He requested a brainstorming session in this meeting to get to a conclusion how to deal with this problem. I know that Joachim Henze has also attempted to change base
addresses lately to fix Photoshop CS2, so this is probably the right time to deal with this problem.
Further topics can be requested by replying to this mail. See you all on Thursday!
Best regards,
Colin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
If this does not count, then I vote for this topic, too. Fun fact here, I am listed as core developer :P
Greetings
Daniel
Am 30.05.2018 um 09:39 schrieb michael@fritscher.net:
Good day,
just as a suggestion for this or a following meeting (I'm no "core developer", so I can not attend to it):
Additional topic: "Get the demo laptop running completely and add it into our testbot"
As the main lesson learnt from the CLT18, we have almost no visible advantages (albeit we progressed very well in the last years!). Most people complained that we dumbing almost at the same level as years ago - and lost interest.
This is particulary bad as most things are already at the 90-100% level.
So my suggestion is to get the demo laptop (the Dell D531) running to a stage that "normal usage" can be demonstrated:
* Browsing the internet (already possible) * (Libre or Open or MS) Office working * 2D and simple 3D games running * Have the ATI driver running for decent performance (From my experience at the CLT, I think this is at the 90-95% stage - see https://jira.reactos.org/browse/CORE-14464 and the root issue https://jira.reactos.org/browse/CORE-10456 (which has already patches provided by vga1) * Sound (listening to music ("works seldom") * Access to a NFS server (already working, but not tested on real hw) * (unformated) printing (already working) * usb thumb sticks (already working with patches)
I would like having this on the next CLT so we can indeed show the impressive progress.
I think the main stumbling is the lack of automated tests on the laptop. So I would suggest to enable one of the laptops to do automated testing. At one point, ros could even be booted via PXE, so it should be fairly easy.
Either we could put it into the data center rack, or I'm willing to build and host such a setup at home. Either way, I'm willing to donate a IP KVM switch and a network power switch to make such setup possible.
Best regards, Michael Fritscher
P.S. Timely speaking, I've time tomorrow.
Am 2018-05-28 09:15, schrieb Colin Finck:
Hi all!
Let me invite you to the May 2018 meeting, taking place this Thursday, May 31, 2018 at 19:00 UTC. Invited members will again receive their credentials shortly before the meeting.
Based on requests and current topics, the agenda looks like this:
- Status Reports
============== Like last time, participants are requested to just post their prepared reports again to not waste any minute.
- Improving our handling of PRs and JIRA reports
============================================== The global JIRA permissions have been changed this month and there has been a lot of bad blood regarding issues marked as "trivial". On the one hand, trivial PRs waste a lot of time of our core developers as long as they are the only ones able to commit them. On the other hand, trivial PRs still add minor improvements to the code, so it would be wrong to just close them as invalid. Let's have an open discussion on this topic and try to establish rules we can all work with without taking this problem to a personal level.
- Google Summer of Code
===================== This will be the first meeting, which could be joined by our GSoC student Victor Perevertkin. If he or the mentors have questions that are better discussed with all developers in the monthly meeting, let's do this here.
- Changes affecting base addresses
================================ Robert Naumann has requested adding this topic to the agenda. He couldn't merge several PRs translating .mc files, because that would blow up the kernel and require a regeneration of all base addresses. He requested a brainstorming session in this meeting to get to a conclusion how to deal with this problem. I know that Joachim Henze has also attempted to change base addresses lately to fix Photoshop CS2, so this is probably the right time to deal with this problem.
Further topics can be requested by replying to this mail. See you all on Thursday!
Best regards,
Colin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Am 30.05.2018 um 09:39 schrieb michael@fritscher.net:
* (unformated) printing (already working)
Unfortunately, my demonstration back in 2015 was merely a proof-of-concept using low-level printer APIs. They work indeed, however almost every Win32 printing application uses the high-level GDI APIs or a datatype conversion through a printer driver. Both parts are still unimplemented.
Nevertheless, carrying a printer is hardly an option for most exhibitions, so I don't consider this too important when we only talk about demonstration purposes.
I think the main stumbling is the lack of automated tests on the laptop. So I would suggest to enable one of the laptops to do automated testing. At one point, ros could even be booted via PXE, so it should be fairly easy.
Either we could put it into the data center rack, or I'm willing to build and host such a setup at home. Either way, I'm willing to donate a IP KVM switch and a network power switch to make such setup possible.
Everyone, please remember that a similar setup is already in place at my home and completely unused: The Kaasimir GPU Testing Machine.
I have built a 4-port network power switch for it (supporting either simple circuit switching, power/reset button switching or Wake-on-LAN) and Kaasimir comes with two Raritan eRIC KVM-over-IP cards.
I've basically been waiting for interested developers since my presentation in August to hand them an account and let them improve ReactOS GPU support. But maybe the machine is even more interesting when we connect one of its KVM-over-IP cards to a Dell Latitude D531 ReactOS testing laptop. Would require working ReactOS PXE support, how far has that progressed? And who would actually benefit from such a setup? I don't want to put time into this if nobody wants to work with that setup anyway..
- Colin
I'd like to expand on point 2, which is something myself and DavidQ were discussing recently. Our PRs are becoming out of control. I've been though a lot of the top project on github, and most seem to have just a small handful of open PRs at any one time. As of this writing, we're currently at 83 and we've consistently increased since we first moved to github. We're on track to surpass 100 next month.
Potential problems are: 1) we have too few people reviewing 2) some of the devs reviewing are far too picky/pedantic in their comments 3) people are too afraid of just merging them 4) anything not on the first page gets ignored 4) something else?
My personal thoughts are we have a mixture of 2 & 3, with a hint of 4. Whatever the issues are, there are certainly things we can do to address it, but I'll leave that for the meeting discussion.
Ged.
-----Original Message----- From: Ros-dev ros-dev-bounces@reactos.org On Behalf Of Colin Finck Sent: Monday, 28 May 2018 08:16 To: 'ReactOS Development List' ros-dev@reactos.org Subject: [ros-dev] Status Meeting (May 2018)
Hi all!
Let me invite you to the May 2018 meeting, taking place this Thursday, May 31, 2018 at 19:00 UTC. Invited members will again receive their credentials shortly before the meeting.
Based on requests and current topics, the agenda looks like this:
1. Status Reports ============== Like last time, participants are requested to just post their prepared reports again to not waste any minute.
2. Improving our handling of PRs and JIRA reports ============================================== The global JIRA permissions have been changed this month and there has been a lot of bad blood regarding issues marked as "trivial". On the one hand, trivial PRs waste a lot of time of our core developers as long as they are the only ones able to commit them. On the other hand, trivial PRs still add minor improvements to the code, so it would be wrong to just close them as invalid. Let's have an open discussion on this topic and try to establish rules we can all work with without taking this problem to a personal level.
3. Google Summer of Code ===================== This will be the first meeting, which could be joined by our GSoC student Victor Perevertkin. If he or the mentors have questions that are better discussed with all developers in the monthly meeting, let's do this here.
4. Changes affecting base addresses ================================ Robert Naumann has requested adding this topic to the agenda. He couldn't merge several PRs translating .mc files, because that would blow up the kernel and require a regeneration of all base addresses. He requested a brainstorming session in this meeting to get to a conclusion how to deal with this problem. I know that Joachim Henze has also attempted to change base addresses lately to fix Photoshop CS2, so this is probably the right time to deal with this problem.
Further topics can be requested by replying to this mail. See you all on Thursday!
Best regards,
Colin
Am 30.05.2018 um 13:26 schrieb Ged Murphy:
Potential problems are: 4) something else?
I've been struggling with e.g. https://github.com/reactos/reactos/pull/276
On the one hand, we definitely need official support for Chinese, Korean, and Japanese character sets. On the other hand, this must not bloat up ReactOS by default, and just dropping a 12 MB font into the repository definitely does. So what is the ideal solution? I don't even know myself.
- I could leave the PR open and hope that the submitter addresses my comments and comes up with a better solution. That hasn't happened in the last months.
- I could close the PR right away. That would give the submitter no chance to address my comments and may even look disrespectful. And the original problem tends to be forgotten.
- I could close the PR and open a JIRA issue describing the problem. If we decide on that as a general rule, we would put another burden on every reviewer. Additionally, such general JIRA issues tend to rot in our database as well.
I think we often have this situation where the submitted PR is wrong, but we don't know the right solution either, and therefore keep the PR open. If we can better deal with these cases, the number of open PRs may decrease significantly.
- Colin
I think in this particular case, Giannis' solution seems ideal. In addition, I think it'd be good to split our language resources into separate mui files and only install the language chosen on install.
However this obviously involves additional work, and doesn't solve the problem of what to do with the PR (leave it open, close, add to jira)
Ged.
-----Original Message----- From: Ros-dev ros-dev-bounces@reactos.org On Behalf Of Colin Finck Sent: Wednesday, 30 May 2018 17:19 To: ros-dev@reactos.org Subject: Re: [ros-dev] Status Meeting (May 2018)
Am 30.05.2018 um 13:26 schrieb Ged Murphy:
Potential problems are: 4) something else?
I've been struggling with e.g. https://github.com/reactos/reactos/pull/276
On the one hand, we definitely need official support for Chinese, Korean, and Japanese character sets. On the other hand, this must not bloat up ReactOS by default, and just dropping a 12 MB font into the repository definitely does. So what is the ideal solution? I don't even know myself.
- I could leave the PR open and hope that the submitter addresses my comments and comes up with a better solution. That hasn't happened in the last months.
- I could close the PR right away. That would give the submitter no chance to address my comments and may even look disrespectful. And the original problem tends to be forgotten.
- I could close the PR and open a JIRA issue describing the problem. If we decide on that as a general rule, we would put another burden on every reviewer. Additionally, such general JIRA issues tend to rot in our database as well.
I think we often have this situation where the submitted PR is wrong, but we don't know the right solution either, and therefore keep the PR open. If we can better deal with these cases, the number of open PRs may decrease significantly.
- Colin
Credentials have been sent, please check your inboxes!
Am 28.05.2018 um 09:15 schrieb Colin Finck:
Hi all!
Let me invite you to the May 2018 meeting, taking place this Thursday, May 31, 2018 at 19:00 UTC. Invited members will again receive their credentials shortly before the meeting.
Based on requests and current topics, the agenda looks like this:
Status Reports
Like last time, participants are requested to just post their prepared reports again to not waste any minute.
Improving our handling of PRs and JIRA reports
The global JIRA permissions have been changed this month and there has been a lot of bad blood regarding issues marked as "trivial". On the one hand, trivial PRs waste a lot of time of our core developers as long as they are the only ones able to commit them. On the other hand, trivial PRs still add minor improvements to the code, so it would be wrong to just close them as invalid. Let's have an open discussion on this topic and try to establish rules we can all work with without taking this problem to a personal level.
Google Summer of Code
This will be the first meeting, which could be joined by our GSoC student Victor Perevertkin. If he or the mentors have questions that are better discussed with all developers in the monthly meeting, let's do this here.
Changes affecting base addresses
Robert Naumann has requested adding this topic to the agenda. He couldn't merge several PRs translating .mc files, because that would blow up the kernel and require a regeneration of all base addresses. He requested a brainstorming session in this meeting to get to a conclusion how to deal with this problem. I know that Joachim Henze has also attempted to change base addresses lately to fix Photoshop CS2, so this is probably the right time to deal with this problem.
Further topics can be requested by replying to this mail. See you all on Thursday!
Best regards,
Colin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-
Alexander Rechitskiy -
Colin Finck -
Daniel Reimer -
Ged Murphy -
michael＠fritscher.net -
Oleksandr Shaposhnikov