Status Meeting (May 2018)

[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:


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:
>  
>  
>  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
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Daniel Reimer]

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(a)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:
> >
> >
> >  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
> >
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Colin Finck]

Am 30.05.2018 um 09:39 schrieb michael(a)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

[Ged Murphy]

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(a)reactos.org> On Behalf Of Colin Finck
Sent: Monday, 28 May 2018 08:16
To: 'ReactOS Development List' <ros-dev(a)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

[Colin Finck]

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

[Ged Murphy]

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(a)reactos.org> On Behalf Of Colin Finck
Sent: Wednesday, 30 May 2018 17:19
To: ros-dev(a)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

[Colin Finck]

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:
>  
>  
>  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
>  
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>