Adapt and over come,,, or die...... Sounds like a daily ReactOS thing. On Fri, Mar 6, 2015 at 7:02 AM, Magnus Johnsson <magnus...@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 <pie...@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-boun...@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.belu...@sfr.fr> >> > Datum: 06.03.2015 12:03 (GMT+01:00) >> > An: 'ReactOS Development List' <ros-dev@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-boun...@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-boun...@reactos.org] De la part de >> >> Aleksey Bragin Envoyé : vendredi 6 mars 2015 00:15 À : >> >> ros-dev@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, hbelu...@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@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 >> > >> > >> > >> > >> > _______________________________________________ >> > Ros-dev mailing list >> > Ros-dev@reactos.org >> > http://www.reactos.org/mailman/listinfo/ros-dev >> > >> >> >> -- >> Pierre Schweitzer <pie...@reactos.org> >> System & Network Administrator >> Senior Kernel Developer >> ReactOS Deutschland e.V. >> >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> > > > 2015-03-06 13:57 GMT+01:00 Aleksey Bragin <alek...@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@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 >
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
