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: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&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 > -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
