Re: [ros-dev] [ros-diffs] [hbelusca] 66575: Start source tree (final, I hope!) restructuration. Part 1/X Win32, Shell, Services, MVDM

[Aleksey Bragin]

Hermes,

What the fuck, may I ask?

I don't understand since when we started doing big changes in trunk 
without talking (or listening) to anyone at all, just at your own 
discretion?

Are you so sure the change is accepted by majority of our developers? 
Did you get approval of those devs? Give them some respect which they 
earned over years with their skills and commitment.

I understand ReactOS is a very loosely managed project (to favor ease of 
development), but totally ignoring everyone?
I checked CORE-9111 and I don't see any single comment from Timo, 
Jerome, James, whoever else counts.

Regards,
Aleksey Bragin
P.S. I'm not talking about actual changes, I'm talking about the process 
and attitude.

On 06.03.2015 2:03, [e-mail] wrote:
> Author: hbelusca
> Date: Thu Mar  5 23:03:33 2015
> New Revision: 66575
>
> URL: http://svn.reactos.org/svn/reactos?rev=66575&view=rev
> Log:
> Start source tree (final, I hope!) restructuration. Part 1/X
> Win32, Shell, Services, MVDM

[Jerome Gardou]

I guess Hermès wants to prove how good svn, git or whatever we use as 
CVS are when it comes to merging.

That said, I will kill anyone moving a single iota in ntoskrnl, includes 
and drivers. You've all been warned.

Le 06/03/2015 00:14, Aleksey Bragin a écrit :
> Hermes,
>
> What the fuck, may I ask?
>
> I don't understand since when we started doing big changes in trunk 
> without talking (or listening) to anyone at all, just at your own 
> discretion?
>
> Are you so sure the change is accepted by majority of our developers? 
> Did you get approval of those devs? Give them some respect which they 
> earned over years with their skills and commitment.
>
> I understand ReactOS is a very loosely managed project (to favor ease 
> of development), but totally ignoring everyone?
> I checked CORE-9111 and I don't see any single comment from Timo, 
> Jerome, James, whoever else counts.
>
> Regards,
> Aleksey Bragin
> P.S. I'm not talking about actual changes, I'm talking about the 
> process and attitude.
>
> On 06.03.2015 2:03, [e-mail] wrote:
> > Author: hbelusca
> > Date: Thu Mar  5 23:03:33 2015
> > New Revision: 66575
> >
> > URL: http://svn.reactos.org/svn/reactos?rev=66575&view=rev
> > Log:
> > Start source tree (final, I hope!) restructuration. Part 1/X
> > Win32, Shell, Services, MVDM
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Hermès BÉLUSCA - MAÏTO]

Hi,

So first, please receive my apologies for not having warned in ros-dev about
this (continuation of) tree restructure I did starting with r66575. Indeed
this was the first thing to do before doing anything, even if I talked about
that on IRC and JIRA!

In fact, the tree restructure discussion started 5 years ago, along with the
cmake bringup: see the big thread here:
http://www.reactos.org/pipermail/ros-dev/2010-July/013257.html . At that
time the main argument was that we were also in the middle of changing the
old build system (rbuild) to a new one (cmake) so it was problematic to do
those two big changes at once. Also at that time, seeing the argumentation
of Ged, Timo, Jérôme and the few others (active developers) who dared to
participate to this discussion, it was clear that a tree restructure was
necessary anyway, sooner or later.

In 2012 some tree restructure happened (r56305) by moving around and in a
more logical manner some core components of win32.

What happens now in 2015, i.e. 5 years after ? We have CMake well
established, everything works, but only win32 core was reorganized.

I made http://jira.reactos.org/browse/CORE-9111 , people started to give
proposals. You came back with the almost same argument, that is to finish
the existing things first (adapt that: at the time of CMake, it was CMake,
now, it's fix all ReactOS 0.4 bugs), and then improve structure of source
tree. Since not all the existing bugs will be fixed by then, we can continue
this way and wait another 5 years in order to have a real tree restructure?
I don't think so.
So I took that for granted and committed r66575.

Active developers really think (at least, myself) it's a pain in the ***
that when we code on some given module (example: shell), we need to modify
some bit of code in base/shell/whatever, some bit of code in
dll/win32/shell32, some bit of code here and there. All the code of the
shell should be tied together. This goes also for everything else: the core
of NT (kernel, ntdll, "base" drivers...), the win32 subsystem (win32k; for
it the change in r56305 started to make things more logical: you would not
have to modify code in some win32k/ directory while also changing
dll/win32/gdi32 or dll/win32/user32 that were by the way amongst all the
rest of wine dlls, etc...) .

Because I didn't want to wait yet another 5 years I decided to start
something.

OK my fault I would have to get a synthesis of the different proposals of
tree restructures I got, then put in ros-dev, then wait 1 month until
everybody starts to vote. Of course you would get people thinking it's
better to do à la Wine and sort the files by extension type (that's what we
almost have currently) and it was already repeated that it is BAD because it
doesn't translate the fact that ROS/windows is built by modules; others
would have thought it's nice to have this piece of thing next to another one
whereas this can be postponed later on until the *obvious* parts of code
have been properly packed together.

And because of that, here is my proposal: UNTIL details get fixed, I propose
to:
- keep the /boot/, /include/, /lib/, /media/ and /tools/ directories (as
well as /cmake/ and the files in / ) untouched.
- ntoskrnl, ntdll and the drivers we have in /drivers/ (SAUF, the multimedia
ones) go into some main "ntcore" directory (ntcore, ntos, call it whatever
you prefer. I'm inclined to the second name, but I'm ok with the first one).
- the keyboard layouts can be moved either to win32ss/ or to / (in case we
can give sense to keyboard layouts in "pure" NT, for example when we run
usetup, etc...)
- ok... my already-done (but revertable) modifs from 66575 (directory
renamings can be done, it's not set in stone).
- putting all printing support in some /win32/printsup (or "printing"...)
directory : that means: localspl, ntprint, printui, spoolsv and spoolss, and
winspool (so far...)

That's what I'm 99.99% sure (and what I think is quite clear). Concerning
the rest (that can create discussion) I still keep it in old directories.

Regards,
Hermès.

-----Message d'origine-----
De : Ros-dev [mailto:[e-mail]] De la part de Aleksey
Bragin
Envoyé : vendredi 6 mars 2015 00:15
À : [e-mail]
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 66575: Start source tree
(final, I hope!) restructuration. Part 1/X Win32, Shell, Services, MVDM

Hermes,

What the fuck, may I ask?

I don't understand since when we started doing big changes in trunk without
talking (or listening) to anyone at all, just at your own discretion?

Are you so sure the change is accepted by majority of our developers? 
Did you get approval of those devs? Give them some respect which they earned
over years with their skills and commitment.

I understand ReactOS is a very loosely managed project (to favor ease of
development), but totally ignoring everyone?
I checked CORE-9111 and I don't see any single comment from Timo, Jerome,
James, whoever else counts.

Regards,
Aleksey Bragin
P.S. I'm not talking about actual changes, I'm talking about the process and
attitude.

On 06.03.2015 2:03, [e-mail] wrote:
> Author: hbelusca
> Date: Thu Mar  5 23:03:33 2015
> New Revision: 66575
>
> URL: http://svn.reactos.org/svn/reactos?rev=66575&view=rev
> Log:
> Start source tree (final, I hope!) restructuration. Part 1/X Win32, 
> Shell, Services, MVDM

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Christoph von Wittich]

Does this mean Hermes just volunteered to adapt the ~130 patches in JIRA 
to his new tree structure...?

Am 06.03.2015 um 00:58 schrieb Hermès BÉLUSCA - MAÏTO:
> Hi,
>
> So first, please receive my apologies for not having warned in ros-dev about
> this (continuation of) tree restructure I did starting with r66575. Indeed
> this was the first thing to do before doing anything, even if I talked about
> that on IRC and JIRA!
>
> In fact, the tree restructure discussion started 5 years ago, along with the
> cmake bringup: see the big thread here:
> http://www.reactos.org/pipermail/ros-dev/2010-July/013257.html . At that
> time the main argument was that we were also in the middle of changing the
> old build system (rbuild) to a new one (cmake) so it was problematic to do
> those two big changes at once. Also at that time, seeing the argumentation
> of Ged, Timo, Jérôme and the few others (active developers) who dared to
> participate to this discussion, it was clear that a tree restructure was
> necessary anyway, sooner or later.
>
> In 2012 some tree restructure happened (r56305) by moving around and in a
> more logical manner some core components of win32.
>
> What happens now in 2015, i.e. 5 years after ? We have CMake well
> established, everything works, but only win32 core was reorganized.
>
> I made http://jira.reactos.org/browse/CORE-9111 , people started to give
> proposals. You came back with the almost same argument, that is to finish
> the existing things first (adapt that: at the time of CMake, it was CMake,
> now, it's fix all ReactOS 0.4 bugs), and then improve structure of source
> tree. Since not all the existing bugs will be fixed by then, we can continue
> this way and wait another 5 years in order to have a real tree restructure?
> I don't think so.
> So I took that for granted and committed r66575.
>
> Active developers really think (at least, myself) it's a pain in the ***
> that when we code on some given module (example: shell), we need to modify
> some bit of code in base/shell/whatever, some bit of code in
> dll/win32/shell32, some bit of code here and there. All the code of the
> shell should be tied together. This goes also for everything else: the core
> of NT (kernel, ntdll, "base" drivers...), the win32 subsystem (win32k; for
> it the change in r56305 started to make things more logical: you would not
> have to modify code in some win32k/ directory while also changing
> dll/win32/gdi32 or dll/win32/user32 that were by the way amongst all the
> rest of wine dlls, etc...) .
>
> Because I didn't want to wait yet another 5 years I decided to start
> something.
>
> OK my fault I would have to get a synthesis of the different proposals of
> tree restructures I got, then put in ros-dev, then wait 1 month until
> everybody starts to vote. Of course you would get people thinking it's
> better to do à la Wine and sort the files by extension type (that's what we
> almost have currently) and it was already repeated that it is BAD because it
> doesn't translate the fact that ROS/windows is built by modules; others
> would have thought it's nice to have this piece of thing next to another one
> whereas this can be postponed later on until the *obvious* parts of code
> have been properly packed together.
>
> And because of that, here is my proposal: UNTIL details get fixed, I propose
> to:
> keep the /boot/, /include/, /lib/, /media/ and /tools/ directories (as
>
> well as /cmake/ and the files in / ) untouched.
> ntoskrnl, ntdll and the drivers we have in /drivers/ (SAUF, the multimedia
>
> ones) go into some main "ntcore" directory (ntcore, ntos, call it whatever
> you prefer. I'm inclined to the second name, but I'm ok with the first one).
> the keyboard layouts can be moved either to win32ss/ or to / (in case we
>
> can give sense to keyboard layouts in "pure" NT, for example when we run
> usetup, etc...)
> ok... my already-done (but revertable) modifs from 66575 (directory
>
> renamings can be done, it's not set in stone).
> putting all printing support in some /win32/printsup (or "printing"...)
>
> directory : that means: localspl, ntprint, printui, spoolsv and spoolss, and
> winspool (so far...)
>
> That's what I'm 99.99% sure (and what I think is quite clear). Concerning
> the rest (that can create discussion) I still keep it in old directories.
>
> Regards,
> Hermès.
>
> -----Message d'origine-----
> De : Ros-dev [mailto:[e-mail]] De la part de Aleksey
> Bragin
> Envoyé : vendredi 6 mars 2015 00:15
> À : [e-mail]
> Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 66575: Start source tree
> (final, I hope!) restructuration. Part 1/X Win32, Shell, Services, MVDM
>
> Hermes,
>
> What the fuck, may I ask?
>
> I don't understand since when we started doing big changes in trunk without
> talking (or listening) to anyone at all, just at your own discretion?
>
> Are you so sure the change is accepted by majority of our developers?
> Did you get approval of those devs? Give them some respect which they earned
> over years with their skills and commitment.
>
> I understand ReactOS is a very loosely managed project (to favor ease of
> development), but totally ignoring everyone?
> I checked CORE-9111 and I don't see any single comment from Timo, Jerome,
> James, whoever else counts.
>
> Regards,
> Aleksey Bragin
> P.S. I'm not talking about actual changes, I'm talking about the process and
> attitude.
>
> On 06.03.2015 2:03, [e-mail] wrote:
> > Author: hbelusca
> > Date: Thu Mar  5 23:03:33 2015
> > New Revision: 66575
> >
> > URL: http://svn.reactos.org/svn/reactos?rev=66575&view=rev
> > Log:
> > Start source tree (final, I hope!) restructuration. Part 1/X Win32,
> > Shell, Services, MVDM
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Pierre Schweitzer]

Hi,

I believe this an opportunity to remind that ReactOS is a team project.
And thus, some good practices apply to preserve team work.

Over the last months, we have seen a trend getting more and more present
in ReactOS, and which is totally damaging for others devs and for
contributors (patches). This is what I call useless commits for the sake
of committing. Obviously, r66575 applies.

So, guys before you ever commit, always remember that you are not the
only one to provide patches, to have commit access to files, and thus,
the following commits are really dangerous for others:
- Changing formatting/whitespace especially on files you even don't work on
- Changing comment style especially on files you even don't work on
- Moving files especially on files you even don't work on

Even if such commits look harmless, they are actually the most dangerous
possible, because most of the time, SVN (or git, no matter) gets lost
and cannot replay local changes on top of them. And this, for commits
that don't bring anything to ReactOS.
Such trend should really stop.

Finally, regarding this sole issue. Regarding the amount of changes and
implications, arguments such as "Active developers really think (at
least, myself)" are definitely not receivable. As in maths, you cannot
extrapolate your thoughts. Arguments such as "Because I didn't want to
wait yet another 5 years I decided to start something." are not
receivable either. As long as it concerns other devs, you're not the
only one to decide any longer. And this implies prior discussions
agreement. Team work. Again.
And as a reminder the last time such topic was brought to devs, it was
agreed that we have more urgent to do in terms of 0.4 release
preparation than changing source tree structure.

And as a conclusion, I'll totally second Jérôme. The next who breaks on
purpose my working copy with previously defined "useless commits for the
sake of committing" will win a branch just for himself and will see his
trunk commit access revoked. If one cannot work in team, they shouldn't
have access to team work tools.
Period.

Regards,

On 06/03/2015 00:58, Hermès BÉLUSCA - MAÏTO wrote:
> Hi,
>
> So first, please receive my apologies for not having warned in ros-dev about
> this (continuation of) tree restructure I did starting with r66575. Indeed
> this was the first thing to do before doing anything, even if I talked about
> that on IRC and JIRA!
>
> In fact, the tree restructure discussion started 5 years ago, along with the
> cmake bringup: see the big thread here:
> http://www.reactos.org/pipermail/ros-dev/2010-July/013257.html . At that
> time the main argument was that we were also in the middle of changing the
> old build system (rbuild) to a new one (cmake) so it was problematic to do
> those two big changes at once. Also at that time, seeing the argumentation
> of Ged, Timo, Jérôme and the few others (active developers) who dared to
> participate to this discussion, it was clear that a tree restructure was
> necessary anyway, sooner or later.
>
> In 2012 some tree restructure happened (r56305) by moving around and in a
> more logical manner some core components of win32.
>
> What happens now in 2015, i.e. 5 years after ? We have CMake well
> established, everything works, but only win32 core was reorganized.
>
> I made http://jira.reactos.org/browse/CORE-9111 , people started to give
> proposals. You came back with the almost same argument, that is to finish
> the existing things first (adapt that: at the time of CMake, it was CMake,
> now, it's fix all ReactOS 0.4 bugs), and then improve structure of source
> tree. Since not all the existing bugs will be fixed by then, we can continue
> this way and wait another 5 years in order to have a real tree restructure?
> I don't think so.
> So I took that for granted and committed r66575.
>
> Active developers really think (at least, myself) it's a pain in the ***
> that when we code on some given module (example: shell), we need to modify
> some bit of code in base/shell/whatever, some bit of code in
> dll/win32/shell32, some bit of code here and there. All the code of the
> shell should be tied together. This goes also for everything else: the core
> of NT (kernel, ntdll, "base" drivers...), the win32 subsystem (win32k; for
> it the change in r56305 started to make things more logical: you would not
> have to modify code in some win32k/ directory while also changing
> dll/win32/gdi32 or dll/win32/user32 that were by the way amongst all the
> rest of wine dlls, etc...) .
>
> Because I didn't want to wait yet another 5 years I decided to start
> something.
>
> OK my fault I would have to get a synthesis of the different proposals of
> tree restructures I got, then put in ros-dev, then wait 1 month until
> everybody starts to vote. Of course you would get people thinking it's
> better to do à la Wine and sort the files by extension type (that's what we
> almost have currently) and it was already repeated that it is BAD because it
> doesn't translate the fact that ROS/windows is built by modules; others
> would have thought it's nice to have this piece of thing next to another one
> whereas this can be postponed later on until the *obvious* parts of code
> have been properly packed together.
>
> And because of that, here is my proposal: UNTIL details get fixed, I propose
> to:
> keep the /boot/, /include/, /lib/, /media/ and /tools/ directories (as
>
> well as /cmake/ and the files in / ) untouched.
> ntoskrnl, ntdll and the drivers we have in /drivers/ (SAUF, the multimedia
>
> ones) go into some main "ntcore" directory (ntcore, ntos, call it whatever
> you prefer. I'm inclined to the second name, but I'm ok with the first one).
> the keyboard layouts can be moved either to win32ss/ or to / (in case we
>
> can give sense to keyboard layouts in "pure" NT, for example when we run
> usetup, etc...)
> ok... my already-done (but revertable) modifs from 66575 (directory
>
> renamings can be done, it's not set in stone).
> putting all printing support in some /win32/printsup (or "printing"...)
>
> directory : that means: localspl, ntprint, printui, spoolsv and spoolss, and
> winspool (so far...)
>
> That's what I'm 99.99% sure (and what I think is quite clear). Concerning
> the rest (that can create discussion) I still keep it in old directories.
>
> Regards,
> Hermès.
>
> -----Message d'origine-----
> De : Ros-dev [mailto:[e-mail]] De la part de Aleksey
> Bragin
> Envoyé : vendredi 6 mars 2015 00:15
> À : [e-mail]
> Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 66575: Start source tree
> (final, I hope!) restructuration. Part 1/X Win32, Shell, Services, MVDM
>
> Hermes,
>
> What the fuck, may I ask?
>
> I don't understand since when we started doing big changes in trunk without
> talking (or listening) to anyone at all, just at your own discretion?
>
> Are you so sure the change is accepted by majority of our developers? 
> Did you get approval of those devs? Give them some respect which they earned
> over years with their skills and commitment.
>
> I understand ReactOS is a very loosely managed project (to favor ease of
> development), but totally ignoring everyone?
> I checked CORE-9111 and I don't see any single comment from Timo, Jerome,
> James, whoever else counts.
>
> Regards,
> Aleksey Bragin
> P.S. I'm not talking about actual changes, I'm talking about the process and
> attitude.
>
> On 06.03.2015 2:03, [e-mail] wrote:
> > Author: hbelusca
> > Date: Thu Mar  5 23:03:33 2015
> > New Revision: 66575
> >
> > URL: http://svn.reactos.org/svn/reactos?rev=66575&view=rev
> > Log:
> > Start source tree (final, I hope!) restructuration. Part 1/X Win32, 
> > Shell, Services, MVDM
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
-- 
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.

[Aleksey Bragin]

On 06.03.2015 2:58, Hermès BÉLUSCA - MAÏTO wrote:
> Hi,
>
> So first, please receive my apologies for not having warned in ros-dev about
> this (continuation of) tree restructure I did starting with r66575. Indeed
> this was the first thing to do before doing anything, even if I talked about
> that on IRC and JIRA!

Wrong.
You did not need to warn, you need to get majority of devs to support 
this change, to get comments from them, to make sure they continue to 
feel "at home" in ReactOS source code.

Right now, for the sake of subjective beautification you just forced 
everyone but you to adapt their patches (myself included, I have many 
working copies) just because you feel the tree structure was wrong.

This is just ridiculous. As Pierre said, we are a team here. And 
teamwork without big issues is what is making our project a good place 
to work in, to get pleasure and satisfaction from the work done.
> In fact, the tree restructure discussion started 5 years ago, along with the
> cmake bringup: see the big thread here:
> http://www.reactos.org/pipermail/ros-dev/2010-July/013257.html .

Imagine what, I was part of it.
> At that
> time the main argument was that we were also in the middle of changing the
> old build system (rbuild) to a new one (cmake) so it was problematic to do
> those two big changes at once. Also at that time, seeing the argumentation
> of Ged, Timo, Jérôme and the few others (active developers) who dared to
> participate to this discussion, it was clear that a tree restructure was
> necessary anyway, sooner or later.

This is called 
https://en.wikipedia.org/wiki/Post-purchase_rationalization . After you 
made the change you start explaining that everyone was supporting it, it 
was so much needed, and let's just forget about any side-effects it may 
have caused.
> In 2012 some tree restructure happened (r56305) by moving around and in a
> more logical manner some core components of win32.

Yep.
> What happens now in 2015, i.e. 5 years after ? We have CMake well
> established, everything works, but only win32 core was reorganized.

Sure, 5 years is a magic number which means you can safely ignore 
everyone else and just force your own change.
> I made http://jira.reactos.org/browse/CORE-9111 , people started to give
> proposals. You came back with the almost same argument, that is to finish
> the existing things first (adapt that: at the time of CMake, it was CMake,
> now, it's fix all ReactOS 0.4 bugs), and then improve structure of source
> tree. Since not all the existing bugs will be fixed by then, we can continue
> this way and wait another 5 years in order to have a real tree restructure?
> I don't think so.
> So I took that for granted and committed r66575.

You know, users don't care about source code tree structure. Tree is for 
developers. Users (and hence, popularity and usability of ReactOS) like 
when ReactOS does not crash, when ReactOS runs their apps, when ReactOS 
loads native binary drivers.
And my point is that internal changes (code refactorings, tree 
restructures, reformatting) must happen only when the advantage of that 
is more than the disadvantage/side effects.
Are you going to say that ReactOS 0.4 is closer now because you 
restructured the tree according to your taste? Was there any urge to do 
the restructure?
> Active developers really think (at least, myself) it's a pain in the ***

The key part: "myself". Let's face it: you silently ignored my opinion 
and decided not to ask anyone else. This is PITA, not the tree structure.
> that when we code on some given module (example: shell), we need to modify
> some bit of code in base/shell/whatever, some bit of code in
> dll/win32/shell32, some bit of code here and there. All the code of the
> shell should be tied together. This goes also for everything else: the core
> of NT (kernel, ntdll, "base" drivers...), the win32 subsystem (win32k; for
> it the change in r56305 started to make things more logical: you would not
> have to modify code in some win32k/ directory while also changing
> dll/win32/gdi32 or dll/win32/user32 that were by the way amongst all the
> rest of wine dlls, etc...) .

It's not "more logical", it's just different logical approaches.
> Because I didn't want to wait yet another 5 years I decided to start
> something.

Just remember, trunk is not your private branch. You have to take other 
devs opinion into account. And you are not always right. Sometimes even 
Alex Ionescu fails, though I must say it happens very rare.
Get used to convince people. Remember Arwinss? Did I just delete the 
existing trunk win32ss back then? Imagine if I did? My reasoning was 
perfect, the subsystem was superior to trunk back then in many ways, and 
"I did not want to wait another 10 years for someone to finish trunk's 
win32ss".
> OK my fault I would have to get a synthesis of the different proposals of
> tree restructures I got, then put in ros-dev, then wait 1 month until
> everybody starts to vote. Of course you would get people thinking it's
> better to do à la Wine and sort the files by extension type (that's what we
> almost have currently) and it was already repeated that it is BAD because it
> doesn't translate the fact that ROS/windows is built by modules; others
> would have thought it's nice to have this piece of thing next to another one
> whereas this can be postponed later on until the *obvious* parts of code
> have been properly packed together.

Yes, unless I don't know something and suddenly all your ideas are 
absolutely true without the need for verification. Mine aren't, I always 
consult with other skilled people.
> And because of that, here is my proposal: UNTIL details get fixed, I propose
> to:
> keep the /boot/, /include/, /lib/, /media/ and /tools/ directories (as
>
> well as /cmake/ and the files in / ) untouched.
> ntoskrnl, ntdll and the drivers we have in /drivers/ (SAUF, the multimedia
>
> ones) go into some main "ntcore" directory (ntcore, ntos, call it whatever
> you prefer. I'm inclined to the second name, but I'm ok with the first one).
> the keyboard layouts can be moved either to win32ss/ or to / (in case we
>
> can give sense to keyboard layouts in "pure" NT, for example when we run
> usetup, etc...)
> ok... my already-done (but revertable) modifs from 66575 (directory
>
> renamings can be done, it's not set in stone).
> putting all printing support in some /win32/printsup (or "printing"...)
>
> directory : that means: localspl, ntprint, printui, spoolsv and spoolss, and
> winspool (so far...)

Oh, now you shared your secret plan with us. Thank you so much!
Actually, I would like to invent something better than just copying the 
NT source code tree layout.
> That's what I'm 99.99% sure (and what I think is quite clear). Concerning
> the rest (that can create discussion) I still keep it in old directories.

...
> Regards,
> Hermès.
>
> -----Message d'origine-----
> De : Ros-dev [mailto:[e-mail]] De la part de Aleksey
> Bragin
> Envoyé : vendredi 6 mars 2015 00:15
> À : [e-mail]
> Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 66575: Start source tree
> (final, I hope!) restructuration. Part 1/X Win32, Shell, Services, MVDM
>
> Hermes,
>
> What the fuck, may I ask?
>
> I don't understand since when we started doing big changes in trunk without
> talking (or listening) to anyone at all, just at your own discretion?
>
> Are you so sure the change is accepted by majority of our developers?
> Did you get approval of those devs? Give them some respect which they earned
> over years with their skills and commitment.
>
> I understand ReactOS is a very loosely managed project (to favor ease of
> development), but totally ignoring everyone?
> I checked CORE-9111 and I don't see any single comment from Timo, Jerome,
> James, whoever else counts.
>
> Regards,
> Aleksey Bragin
> P.S. I'm not talking about actual changes, I'm talking about the process and
> attitude.
>
> On 06.03.2015 2:03, [e-mail] wrote:
> > Author: hbelusca
> > Date: Thu Mar  5 23:03:33 2015
> > New Revision: 66575
> >
> > URL: http://svn.reactos.org/svn/reactos?rev=66575&view=rev
> > Log:
> > Start source tree (final, I hope!) restructuration. Part 1/X Win32,
> > Shell, Services, MVDM

[Hermès BÉLUSCA - MAÏTO]

So...

... must I revert trunk pre-66575 ?

Hermès.

-----Message d'origine-----
De : Ros-dev [mailto:[e-mail]] De la part de Aleksey
Bragin
Envoyé : vendredi 6 mars 2015 10:48
À : ReactOS Development List
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 66575: Start source tree
(final, I hope!) restructuration. Part 1/X Win32, Shell, Services, MVDM

On 06.03.2015 2:58, Hermès BÉLUSCA - MAÏTO wrote:
> Hi,
>
> So first, please receive my apologies for not having warned in ros-dev 
> about this (continuation of) tree restructure I did starting with 
> r66575. Indeed this was the first thing to do before doing anything, 
> even if I talked about that on IRC and JIRA!

Wrong.
You did not need to warn, you need to get majority of devs to support this
change, to get comments from them, to make sure they continue to feel "at
home" in ReactOS source code.

Right now, for the sake of subjective beautification you just forced
everyone but you to adapt their patches (myself included, I have many
working copies) just because you feel the tree structure was wrong.

This is just ridiculous. As Pierre said, we are a team here. And teamwork
without big issues is what is making our project a good place to work in, to
get pleasure and satisfaction from the work done.
> In fact, the tree restructure discussion started 5 years ago, along 
> with the cmake bringup: see the big thread here:
> http://www.reactos.org/pipermail/ros-dev/2010-July/013257.html .

Imagine what, I was part of it.
> At that
> time the main argument was that we were also in the middle of changing 
> the old build system (rbuild) to a new one (cmake) so it was 
> problematic to do those two big changes at once. Also at that time, 
> seeing the argumentation of Ged, Timo, Jérôme and the few others 
> (active developers) who dared to participate to this discussion, it 
> was clear that a tree restructure was necessary anyway, sooner or later.

This is called
https://en.wikipedia.org/wiki/Post-purchase_rationalization . After you made
the change you start explaining that everyone was supporting it, it was so
much needed, and let's just forget about any side-effects it may have
caused.
> In 2012 some tree restructure happened (r56305) by moving around and 
> in a more logical manner some core components of win32.

Yep.
> What happens now in 2015, i.e. 5 years after ? We have CMake well 
> established, everything works, but only win32 core was reorganized.

Sure, 5 years is a magic number which means you can safely ignore everyone
else and just force your own change.
> I made http://jira.reactos.org/browse/CORE-9111 , people started to 
> give proposals. You came back with the almost same argument, that is 
> to finish the existing things first (adapt that: at the time of CMake, 
> it was CMake, now, it's fix all ReactOS 0.4 bugs), and then improve 
> structure of source tree. Since not all the existing bugs will be 
> fixed by then, we can continue this way and wait another 5 years in order

to have a real tree restructure?
> I don't think so.
> So I took that for granted and committed r66575.

You know, users don't care about source code tree structure. Tree is for
developers. Users (and hence, popularity and usability of ReactOS) like when
ReactOS does not crash, when ReactOS runs their apps, when ReactOS loads
native binary drivers.
And my point is that internal changes (code refactorings, tree restructures,
reformatting) must happen only when the advantage of that is more than the
disadvantage/side effects.
Are you going to say that ReactOS 0.4 is closer now because you restructured
the tree according to your taste? Was there any urge to do the restructure?
> Active developers really think (at least, myself) it's a pain in the

The key part: "myself". Let's face it: you silently ignored my opinion and
decided not to ask anyone else. This is PITA, not the tree structure.
> that when we code on some given module (example: shell), we need to 
> modify some bit of code in base/shell/whatever, some bit of code in 
> dll/win32/shell32, some bit of code here and there. All the code of 
> the shell should be tied together. This goes also for everything else: 
> the core of NT (kernel, ntdll, "base" drivers...), the win32 subsystem 
> (win32k; for it the change in r56305 started to make things more 
> logical: you would not have to modify code in some win32k/ directory 
> while also changing
> dll/win32/gdi32 or dll/win32/user32 that were by the way amongst all 
> the rest of wine dlls, etc...) .

It's not "more logical", it's just different logical approaches.
> Because I didn't want to wait yet another 5 years I decided to start 
> something.

Just remember, trunk is not your private branch. You have to take other devs
opinion into account. And you are not always right. Sometimes even Alex
Ionescu fails, though I must say it happens very rare.
Get used to convince people. Remember Arwinss? Did I just delete the
existing trunk win32ss back then? Imagine if I did? My reasoning was
perfect, the subsystem was superior to trunk back then in many ways, and "I
did not want to wait another 10 years for someone to finish trunk's
win32ss".
> OK my fault I would have to get a synthesis of the different proposals 
> of tree restructures I got, then put in ros-dev, then wait 1 month 
> until everybody starts to vote. Of course you would get people 
> thinking it's better to do à la Wine and sort the files by extension 
> type (that's what we almost have currently) and it was already 
> repeated that it is BAD because it doesn't translate the fact that 
> ROS/windows is built by modules; others would have thought it's nice 
> to have this piece of thing next to another one whereas this can be 
> postponed later on until the *obvious* parts of code have been properly

packed together.
Yes, unless I don't know something and suddenly all your ideas are
absolutely true without the need for verification. Mine aren't, I always
consult with other skilled people.
> And because of that, here is my proposal: UNTIL details get fixed, I 
> propose
> to:
> keep the /boot/, /include/, /lib/, /media/ and /tools/ directories
>
> (as well as /cmake/ and the files in / ) untouched.
> ntoskrnl, ntdll and the drivers we have in /drivers/ (SAUF, the
>
> multimedia
> ones) go into some main "ntcore" directory (ntcore, ntos, call it 
> whatever you prefer. I'm inclined to the second name, but I'm ok with the

first one).
> the keyboard layouts can be moved either to win32ss/ or to / (in
>
> case we can give sense to keyboard layouts in "pure" NT, for example 
> when we run usetup, etc...)
> ok... my already-done (but revertable) modifs from 66575 (directory
>
> renamings can be done, it's not set in stone).
> putting all printing support in some /win32/printsup (or
>
> "printing"...) directory : that means: localspl, ntprint, printui, 
> spoolsv and spoolss, and winspool (so far...)

Oh, now you shared your secret plan with us. Thank you so much!
Actually, I would like to invent something better than just copying the NT
source code tree layout.
> That's what I'm 99.99% sure (and what I think is quite clear). 
> Concerning the rest (that can create discussion) I still keep it in old

directories.
...
> Regards,
> Hermès.
>
> -----Message d'origine-----
> De : Ros-dev [mailto:[e-mail]] De la part de 
> Aleksey Bragin Envoyé : vendredi 6 mars 2015 00:15 À : 
> [e-mail] Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 
> 66575: Start source tree (final, I hope!) restructuration. Part 1/X 
> Win32, Shell, Services, MVDM
>
> Hermes,
>
> What the fuck, may I ask?
>
> I don't understand since when we started doing big changes in trunk 
> without talking (or listening) to anyone at all, just at your own

discretion?
> Are you so sure the change is accepted by majority of our developers?
> Did you get approval of those devs? Give them some respect which they 
> earned over years with their skills and commitment.
>
> I understand ReactOS is a very loosely managed project (to favor ease 
> of development), but totally ignoring everyone?
> I checked CORE-9111 and I don't see any single comment from Timo, 
> Jerome, James, whoever else counts.
>
> Regards,
> Aleksey Bragin
> P.S. I'm not talking about actual changes, I'm talking about the 
> process and attitude.
>
> On 06.03.2015 2:03, [e-mail] wrote:
> > Author: hbelusca
> > Date: Thu Mar  5 23:03:33 2015
> > New Revision: 66575
> >
> > URL: http://svn.reactos.org/svn/reactos?rev=66575&view=rev
> > Log:
> > Start source tree (final, I hope!) restructuration. Part 1/X Win32, 
> > Shell, Services, MVDM

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Timo Kreuzer]

Yes, What the fuck?

I have lots patches and you just broke them all.

What made you think you can decide on your own how the new structure is 
supposed to look like?
Did you ask me or Jim for how win32ss looks like now?

We already restructured win32ss so why are you re-restructuring it on 
your own?

Has it ever come to your mind that the main committers in that area 
should be asked before breaking stuff for them?

This is not the fucking wild-west!

Timo

Am 06.03.2015 um 00:14 schrieb Aleksey Bragin:
> Hermes,
>
> What the fuck, may I ask?
>
> I don't understand since when we started doing big changes in trunk 
> without talking (or listening) to anyone at all, just at your own 
> discretion?
>
> Are you so sure the change is accepted by majority of our developers? 
> Did you get approval of those devs? Give them some respect which they 
> earned over years with their skills and commitment.
>
> I understand ReactOS is a very loosely managed project (to favor ease 
> of development), but totally ignoring everyone?
> I checked CORE-9111 and I don't see any single comment from Timo, 
> Jerome, James, whoever else counts.
>
> Regards,
> Aleksey Bragin
> P.S. I'm not talking about actual changes, I'm talking about the 
> process and attitude.
>
> On 06.03.2015 2:03, [e-mail] wrote:
> > Author: hbelusca
> > Date: Thu Mar  5 23:03:33 2015
> > New Revision: 66575
> >
> > URL: http://svn.reactos.org/svn/reactos?rev=66575&view=rev
> > Log:
> > Start source tree (final, I hope!) restructuration. Part 1/X
> > Win32, Shell, Services, MVDM
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev