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

Fri Mar 6 13:54:21 UTC 2015

Adapt and over come,,, or die...... Sounds like a daily ReactOS thing.

On Fri, Mar 6, 2015 at 7:02 AM, Magnus Johnsson <magnusjjj at gmail.com> wrote:

> Question, from someone who is not a ReactOS dev, a solution to this kind
> of thing might be, say, have a plan for how (if) restructuring is to be
> done, and, oh, a vote? I don't think that the work put in needs to be
> thrown away, but maybe said patches could be broken up into smaller ones
> and being judged case-by-case? Also, if you could document the work that
> needed to be done to allow restructuring to be done the way you planned,
> that might certainly be helpful not only for this case, but maybe could be
> hacked into a newbie-guide for how the source tree is laid out :).
>
> 2015-03-06 13:46 GMT+01:00 Pierre Schweitzer <pierre at reactos.org>:
>
>> On 03/06/2015 01:30 PM, Hermès BÉLUSCA - MAÏTO wrote:
>> > First I would prefer to revert everything I done so far for that
>> (failed) attempt of tree restructure, because otherwise nobody will be
>> happy. As far as I can see in a local SVN repo I did here, if I revert to
>> the tree shape pre-66575 nothing should break (I mean, if you update your
>> local copy that was at, let’s say, revision 66574 and you update to
>> revision after-my-would-be-revert, it should be ok, your local changes
>> should survive.
>>
>> Given these last information, I'm all for a revert.
>>
>> >
>> >
>> >
>>
>> > Then it would be nice to have a discussion with everybody and seriously
>> to how move the main parts of the things.
>> >
>> >
>> >
>> > Cheers,
>> >
>> > Hermès.
>> >
>> >
>> >
>> > De : Ros-dev [mailto:ros-dev-bounces at reactos.org] De la part de
>> daniel.reimer
>> > Envoyé : vendredi 6 mars 2015 13:12
>> > À : 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
>> >
>> >
>> >
>> > Hii,
>> >
>> >
>> >
>> > Well... In theory the restructuring might be logical and maybe even a
>> good idea to separate some of the DLL/win32 folder etc, but this can't be
>> done as one man show. It breaks the patches in jira, breaks the stuff our
>> devs might have locally and maybe someone has something to say to your
>> plans.
>> >
>> > How to resolve this? Tbh, no clue. But a open discussion BEFORE
>> commiting would be a start IMO. So guys, what now? Can we keep it or not?
>> >
>> >
>> >
>> > Greetings
>> >
>> >
>> >
>> > Daniel
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Von meinem Samsung Gerät gesendet.
>> >
>> >
>> >
>> > -------- Ursprüngliche Nachricht --------
>> > Von: Hermès BÉLUSCA - MAÏTO <hermes.belusca at sfr.fr>
>> > Datum: 06.03.2015 12:03 (GMT+01:00)
>> > An: 'ReactOS Development List' <ros-dev at reactos.org>
>> > Betreff: Re: [ros-dev] [ros-diffs] [hbelusca] 66575: Start source tree
>> (final, I hope!) restructuration. Part 1/X Win32, Shell, Services, MVDM
>> >
>> > So...
>> >
>> > ... must I revert trunk pre-66575 ?
>> >
>> > Hermès.
>> >
>> > -----Message d'origine-----
>> > De : Ros-dev [mailto:ros-dev-bounces at reactos.org] 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:ros-dev-bounces at reactos.org] De la part de
>> >> Aleksey Bragin Envoyé : vendredi 6 mars 2015 00:15 À :
>> >> ros-dev at reactos.org 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, hbelusca at svn.reactos.org wrote:
>> >>> Author: hbelusca
>> >>> Date: Thu Mar  5 23:03:33 2015
>> >>> New Revision: 66575
>> >>>
>> >>> URL: http://svn.reactos.org/svn/reactos?rev=66575 <
>> http://svn.reactos.org/svn/reactos?rev=66575&view=rev> &view=rev
>> >>> Log:
>> >>> Start source tree (final, I hope!) restructuration. Part 1/X Win32,
>> >>> Shell, Services, MVDM
>> >>>
>> >>
>> >
>> >
>> > _______________________________________________
>> > Ros-dev mailing list
>> > Ros-dev at reactos.org
>> > http://www.reactos.org/mailman/listinfo/ros-dev
>> >
>> > _______________________________________________
>> > Ros-dev mailing list
>> > Ros-dev at reactos.org
>> > http://www.reactos.org/mailman/listinfo/ros-dev
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Ros-dev mailing list
>> > Ros-dev at reactos.org
>> > http://www.reactos.org/mailman/listinfo/ros-dev
>> >
>>
>>
>> --
>> Pierre Schweitzer <pierre at reactos.org>
>> System & Network Administrator
>> Senior Kernel Developer
>> ReactOS Deutschland e.V.
>>
>>
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev at reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
>
> 2015-03-06 13:57 GMT+01:00 Aleksey Bragin <aleksey at reactos.org>:
>
>> On 06.03.2015 15:46, Pierre Schweitzer wrote:
>>
>>> On 03/06/2015 01:30 PM, Hermès BÉLUSCA - MAÏTO wrote:
>>>
>>>> First I would prefer to revert everything I done so far for that
>>>> (failed) attempt of tree restructure, because otherwise nobody will be
>>>> happy. As far as I can see in a local SVN repo I did here, if I revert to
>>>> the tree shape pre-66575 nothing should break (I mean, if you update your
>>>> local copy that was at, let’s say, revision 66574 and you update to
>>>> revision after-my-would-be-revert, it should be ok, your local changes
>>>> should survive.
>>>>
>>> Given these last information, I'm all for a revert.
>>>
>> Me too, even though technically I like some aspects of the restructure,
>> and appreciate your time spent on the issue, it's definitely not wasted.
>>
>> Regards,
>> Aleksey Bragin
>>
>>
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev at reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.reactos.org/pipermail/ros-dev/attachments/20150306/af6314f8/attachment-0001.html>