- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-diffs] [reactos] 01/01: [CRT] fix bug in _rotr implementation
by Jerome Gardou 28 Oct '17

28 Oct '17

Hmpf, somehow the change on my github profile was messed up. Sorry about that, the next commit should be under my real name. Jérôme Le 28/10/2017 à 10:28, zefklop a écrit : > https://git.reactos.org/?p=reactos.git;a=commitdiff;h=07c72955457267ee26f60… > > commit 07c72955457267ee26f6086e75c5595fbce76e06 > Author: zefklop <zefklop(a)users.noreply.github.com> > AuthorDate: Sat Oct 28 10:28:27 2017 +0200 > > [CRT] fix bug in _rotr implementation > --- > sdk/lib/crt/stdlib/rot.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/sdk/lib/crt/stdlib/rot.c b/sdk/lib/crt/stdlib/rot.c > index 825a76d3ed..7637a5e9b6 100644 > --- a/sdk/lib/crt/stdlib/rot.c > +++ b/sdk/lib/crt/stdlib/rot.c > @@ -38,7 +38,7 @@ unsigned int _rotr( unsigned int value, int shift ) > if ( shift < 0 ) > return _rotl(value,-shift); > > - if ( shift > max_bits<<3 ) > + if ( shift > max_bits ) > shift = shift % max_bits; > return (value >> shift) | (value << (max_bits-shift)); > } >

1 0

Status Meeting (October 2017)
by Giannis Adamopoulos 26 Oct '17

26 Oct '17

Hi all! Let me invite you to the monthly status meeting taking place today, October 26, 19:00 UTC. As of now we know that both Colin and Pierre will not be able to attend, or be able to control our IRC server so unless we get any further notice from either of them, the meeting will take place in #reactos-meeting in freenode. No agenda proposals have been submitted to me so far. You are welcome to suggest some points to discuss. One that I would like to propose is about the upcoming release that should be branched soon. Of course we will have our status reports. So please have them ready, so we get it done quickly! Giannis

3 2

JIRA up again - Do we still need FishEye?
by Colin Finck 16 Oct '17

16 Oct '17

Hi all! Our two Atlassian tools JIRA and FishEye have been unavailable for some hours again. I have brought JIRA back up, but FishEye has been eating RAM and CPU like crazy again. In my opinion, this is unacceptable for a tool that is just a simple commit browser to us. Also I don't have any time to constantly monitor it this weekend, so I'm leaving it shut down for now. With us having https://github.com/reactos/reactos/commits/master and https://git.reactos.org/?p=reactos.git;a=summary now, do we still need FishEye at all? If so, please tell me what features of it you would miss if it stays down. Maybe there are other alternatives. My last FishEye "performance" bug report took 3 months to resolve, and I'm reluctant to go the same route again for another such bug.. Cheers, Colin

3 2

Question about commits with no commit log, or commits with no files but just the log, on Git.
by Hermès BÉLUSCA - MAÏTO 16 Oct '17

16 Oct '17

‌Hello all,<br> <br> After having noticed https://github.com/reactos/reactos/commit/50ae5e7c5268222718174221366169e2b…<br> I am wondering whether it is possible to add mechanisms (like git pre-commit hooks) that check for, and<br> prevent potential problematic commits like, commits without commit log, or commits with no files (but with a log).<br> <br> Any ideas?<br> <br> Cheers,<br> Hermes

4 3

Testing Pull Requests
by Colin Finck 14 Oct '17

14 Oct '17

Hi all! Apart from basic build testing through AppVeyor and Travis-CI, you can now also run all regression tests for the code belonging to a Pull Request. Just log in to our BuildBot at https://build.reactos.org with your development account credentials (formerly "SVN credentials"), select a builder in the waterfall view and fill the field "Branch" in the "Force a Build" section. You have two options here: * "refs/pull/<ID>/head" Builds your branch, unmodified. That means, if you haven't kept your branch up to date with the main ReactOS repo, latest changes won't be included. * "refs/pull/<ID>/merge" Builds the changes of your branch merged to the main ReactOS repo. That means, latest changes in the main ReactOS repo will be included. Replace <ID> by the number of your Pull Request. As the resulting hash may be hard to predict, the "prepare source" step will now give detailed information about the latest commit included in your build: https://build.reactos.org/builders/Build%20GCCLin_x86/builds/19201/steps/pr… Have fun! Colin

3 3

GitHub Newbie Question
by Hermès BÉLUSCA - MAÏTO 10 Oct '17

10 Oct '17

<span style="font-family:arial,helvetica,sans-serif; font-size:12px">‌Hi all,<br> <br> I've a newbie question related to GitHub pull requests: How can one see whether commits pertaining to a pull request have both a valid full committer name and email set? So far I can only see the nicknames.<br> <br> Cheers,<br> Hermes</span>

3 2

Re: [ros-dev] GitHub Newbie Question
by hermes.belusca＠sfr.fr 10 Oct '17

10 Oct '17

<span style="font-family:arial,helvetica,sans-serif; font-size:12px">Oops yeah sorry, it was about "author name", not committer name. But you've understood my point.<br> Thanks!</span><br>   <div class="gl_quote" style="margin-top: 20px; padding-top: 5px;">De : gigaherz(a)gmail.com<br> A : hermes.belusca@sfr.fr,ros-dev@reactos.org<br> Envoyé: mardi 10 octobre 2017 12:06<br> Objet : Re: [ros-dev] GitHub Newbie Question<br>   <div class="gl_quoted">Open the commit URL, such as https://github.com/reactos/reactos/commit/44060c284194546703805453f3985ed2b…, but with .patch appended to the end. This shows the author name as part of the "From:" line. The commiter doens't matter since it will be set to whoever presses the merge button. On 10 October 2017 at 11:56, Hermès BÉLUSCA - MAÏTO wrote: > ‌Hi all, > > I've a newbie question related to GitHub pull requests: How can one see > whether commits pertaining to a pull request have both a valid full > committer name and email set? So far I can only see the nicknames. > > Cheers, > Hermes > _______________________________________________ > 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</div> <div class="gl_quoted"> </div> </div>

1 0

Re: [ros-dev] [ros-diffs] [reactos] 01/01: Fix remaining text file line endings in the tree. (#18)
by Colin Finck 06 Oct '17

06 Oct '17

Sorry for the huge diff E-Mail to ros-diffs! I have just configured git_multimail.py to a maximum of 5000 lines to not let that happen again. We can again reduce the limit later on if it turns out to be still too much. Best regards, Colin Finck

1 0

Re: [ros-dev] ReactOS Repository migrated to GitHub
by Can Tasan 04 Oct '17

04 Oct '17

Congrats for switching into Github! Just a little question. Is there any way to return using revision numbers? Current hash-based commit tagging might be confusing, hard to find, not reflecting at-the-time state of development since we have relied on SVN for a long time. Also for bug reporting, revision numbers is more helpful. Secondly, for example, Wine don't (and probably won't) care for hashes as everyone out there uses release builds, and release period is just 2 weeks. That's not the case for ReactOS. In just a few commits big changes might occur, and everyone retests. 3 months? Avalanche! If it isn't viable, could we seek for another solution? (e.g timestamp...) Lastly, git.reactos.org is quite simple for watching the stream, and perfect! Best regards, Can

2 1

Re: [ros-dev] ReactOS Repository migrated to GitHub
by hermes.belusca＠sfr.fr 03 Oct '17

03 Oct '17

<span style="font-family: arial,helvetica,sans-serif; font-size: 12px;">Ahah!! Correct, you've a watchful eye!<br> Thank you very much!<br> <br> Hermès.‌</span> <div class="gl_quote" style="padding-top: 5px; margin-top: 20px;">De : magnusjjj(a)gmail.com<br> A : ros-dev(a)reactos.org<br> Envoyé: mardi 3 octobre 2017 20:09<br> Objet : Re: [ros-dev] ReactOS Repository migrated to GitHub<br>   <div class="gl_quoted"> <div dir="ltr">Are they not under the branches dropdown? Top left, three columns down? There is a handy drop down there. There are at least all the gsoc's, and a ton of other branches there? :). Check it out?</div> <div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2">  <table style="border-top-color: rgb(211, 212, 222); border-top-width: 1px; border-top-style: solid;"> <tbody> <tr> <td style="width: 55px; padding-top: 13px;"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&ut…" target="_blank"><img width="46" height="29" style="width: 46px; height: 29px;" alt="" src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-anima…"></a></td> <td style="width: 470px; color: rgb(65, 66, 78); line-height: 18px; padding-top: 12px; font-family: Arial,Helvetica,sans-serif; font-size: 13px;">Virus-free. <a style="color: rgb(68, 83, 234);" href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&ut…" target="_blank">www.avast.com</a></td> </tr> </tbody> </table> </div> <div class="gmail_extra">  <div class="gmail_quote">2017-10-03 19:45 GMT+02:00 Hermès BÉLUSCA-MAÏTO <span dir="ltr"><<a href="mailto:hermes.belusca@sfr.fr" target="_blank">hermes.belusca(a)sfr.fr</a>></span>: <blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">Thank you very much Colin !! \o/ \o/ \o/ \o/<br> <br> A little question, although: Where are our (experimental) branches now? :P<br> <br> Hermès<br> <br> > -----Message d'origine-----<br> > De : Ros-dev [mailto:<a href="mailto:ros-dev-bounces@reactos.org">ros-dev-bounces@<wbr>reactos.org</a>] De la part de Colin Finck<br> > Envoyé : mardi 3 octobre 2017 19:40<br> > À : <a href="mailto:ros-announce@reactos.org">ros-announce(a)reactos.org</a>; <a href="mailto:ros-general@reactos.org">ros-general(a)reactos.org</a>; 'ReactOS<br> > Development List'<br> > Objet : [ros-dev] ReactOS Repository migrated to GitHub <div class="HOEnZb"> <div class="h5">><br> > Today, the ReactOS Source Code has been migrated from a central Subversion<br> > instance to a decentralized Git repository. Together with that, ReactOS joins the<br> > list of projects using the popular GitHub service for developing software:<br> > <a href="https://github.com/reactos/reactos" target="_blank" rel="noreferrer">https://github.com/reactos/<wbr>reactos</a><br> > We expect that this move greatly improves the way we collaborate on ReactOS<br> > development and reduces the barriers for newcomers. Just fork our repository<br> > on GitHub, commit your changes and send us a Pull Request!<br> ><br> > Migrating a source code history of more than 20 years that had seen multiple<br> > version control systems was not a straightforward task.<br> > Deciding on a decentralized version control system has not been either.<br> > First discussions already started back in 2009, when neither Git nor Mercurial<br> > were able to fully convert a large SVN repository like ours and Git’s Windows<br> > support was still neglected. Things improved massively over the years, with<br> > GitHub and Git for Windows emerging as reliable tools for software<br> > development. But the ReactOS Project still took advantage of some Subversion<br> > features, so only a smooth migration using a two-way SVN-Git mirror was<br> > attempted in 2016. This failed miserably, however important lessons were<br> > learned for a future complete migration to Git. The tipping point was reached<br> > in early 2017 when a majority of ReactOS developers spoke out in favor of<br> > moving to Git. Finally, the ReactOS Hackfest in August offered a forum to try<br> > out things and discuss every little detail of the planned migration. And this is<br> > what got us here today!<br> ><br> > The development documentation is still in the process of being rewritten to<br> > account for the Git migration. You may currently find outdated information<br> > here and there. However, most of that is on the Wiki, so you are more than<br> > welcome to help us!<br> > The SVN Repository has been turned read-only and will be kept online for a<br> > while at the last revision r76032. Our Git mirror now mirrors the GitHub<br> > repository. If you have already been using our old Git mirror, please note that<br> > you have to do a fresh clone of our new repository (from either GitHub or the<br> > mirror) as the old and new ones are incompatible.<br> > JIRA continues to be used for bug tracking, BuildBot for continuous integration,<br> > and FishEye as a code browser.<br> ><br> > I would like to thank all the people who have helped with this migration, be it<br> > on IRC, the mailing lists or at the Hackfest! Special thanks also go to the KDE<br> > Project for their excellent svn-all-fast-export tool that was used for the<br> > conversion. If you are ever in a similar situation, have a look at my conversion<br> > scripts as well as the Git helpers for our infrastructure.<br> ><br> ><br> > Colin Finck<br> ><br> > ______________________________<wbr>_________________<br> > Ros-dev mailing list<br> > <a href="mailto:Ros-dev@reactos.org">Ros-dev(a)reactos.org</a><br> > <a href="http://www.reactos.org/mailman/listinfo/ros-dev" target="_blank" rel="noreferrer">http://www.reactos.org/<wbr>mailman/listinfo/ros-dev</a><br> <br> <br> ______________________________<wbr>_________________<br> Ros-dev mailing list<br> <a href="mailto:Ros-dev@reactos.org">Ros-dev(a)reactos.org</a><br> <a href="http://www.reactos.org/mailman/listinfo/ros-dev" target="_blank" rel="noreferrer">http://www.reactos.org/<wbr>mailman/listinfo/ros-dev</a></div> </div> </blockquote> </div> </div> <br> <br> <br> _______________________________________________<br> Ros-dev mailing list<br> Ros-dev(a)reactos.org<br> http://www.reactos.org/mailman/listinfo/ros-dev</div> <div class="gl_quoted"> </div> </div>

1 0

ReactOS Repository migrated to GitHub
by Colin Finck 03 Oct '17

03 Oct '17

Today, the ReactOS Source Code has been migrated from a central Subversion instance to a decentralized Git repository. Together with that, ReactOS joins the list of projects using the popular GitHub service for developing software: https://github.com/reactos/reactos We expect that this move greatly improves the way we collaborate on ReactOS development and reduces the barriers for newcomers. Just fork our repository on GitHub, commit your changes and send us a Pull Request! Migrating a source code history of more than 20 years that had seen multiple version control systems was not a straightforward task. Deciding on a decentralized version control system has not been either. First discussions already started back in 2009, when neither Git nor Mercurial were able to fully convert a large SVN repository like ours and Git’s Windows support was still neglected. Things improved massively over the years, with GitHub and Git for Windows emerging as reliable tools for software development. But the ReactOS Project still took advantage of some Subversion features, so only a smooth migration using a two-way SVN-Git mirror was attempted in 2016. This failed miserably, however important lessons were learned for a future complete migration to Git. The tipping point was reached in early 2017 when a majority of ReactOS developers spoke out in favor of moving to Git. Finally, the ReactOS Hackfest in August offered a forum to try out things and discuss every little detail of the planned migration. And this is what got us here today! The development documentation is still in the process of being rewritten to account for the Git migration. You may currently find outdated information here and there. However, most of that is on the Wiki, so you are more than welcome to help us! The SVN Repository has been turned read-only and will be kept online for a while at the last revision r76032. Our Git mirror now mirrors the GitHub repository. If you have already been using our old Git mirror, please note that you have to do a fresh clone of our new repository (from either GitHub or the mirror) as the old and new ones are incompatible. JIRA continues to be used for bug tracking, BuildBot for continuous integration, and FishEye as a code browser. I would like to thank all the people who have helped with this migration, be it on IRC, the mailing lists or at the Hackfest! Special thanks also go to the KDE Project for their excellent svn-all-fast-export tool that was used for the conversion. If you are ever in a similar situation, have a look at my conversion scripts as well as the Git helpers for our infrastructure. Colin Finck

3 2

Regression in r75772 broke multiple disk drive support
by Dimitrij Klingbeil 03 Oct '17

03 Oct '17

Hi all, It looks like revision 75772 (removed a "DeviceExt->OpenHandleCount--;") has introduced some significant unintended consequences. Ever since I can't get ReactOS to recognize a second hard drive. My configuration is like this: - ReactOS in a VirtualBox VM, VirtualBox version 5.11.18 - VM configured for Windows 2003 32-bit, with 1 CPU - Emulated Chipset: PIIX3, no USB, no Audio, no Serial - AMD-V active, Nested Paging active, - No paravirtualization interface, no guest additions - Emulated Storage: SATA controller with 4 ports - Port 0: First Hard disk (has partition C) - Port 1: Second Hard disk (has partition D) - Port 3: CDROM (to install ReactOS from, E) - Each hard disk has one single primary partition (FAT formatted by an older ReactOS setup) - On C I install ReactOS (re-formatting the partition in the process) - On D there is some data (a small collection of program installers to try out) Now, inside ReactOS I cannot see the contents of D. The drive itself shows up, but unformatted and of a zero size. In the revisions before 75772 there were no problems, I could see the drive and use the data on it. Re-installing r75771 shows that the drive image is OK and the data is still there, so it's not the data that was corrupted. If I insert a CDROM image (with ReactOS already running), the CDROM drive (E) suddently disappears and D now has the CDROM in it (so happened just now with r75872). When I eject the CDROM, D becomes empty but still shows the icon for a CDROM. E does not re-appear. 75772 looks like a very small change, but something must have gone really off the rails... Regards, Dimitrij P.S. This was at first sent from the wrong (not subscribed to the list) address by mistake. I think the first one was rejected by the list SW, but sorry if the message appears twice.

2 4

Status Meeting (September 2017)
by Colin Finck 28 Sep '17

28 Sep '17

Hi all! Let me invite you to the monthly status meeting taking place today, September 28, 19:00 UTC. As always, you will get credentials for our private IRC server shortly before the meeting. No agenda proposals have been submitted to me so far. If that doesn't change, we will have a meeting just for the status reports. Please have them ready, so we get it done quickly! A lot of tasks from our long last meeting are also still in progress (not just the Git migration), so I wouldn't mind having a short meeting this time. See you in a few hours! Colin

1 1

once agaon about ReactOS trademark infringement by Facebook
by Alexander Rechitskiy 28 Sep '17

28 Sep '17

3 2

Re: [ros-dev] once agaon about ReactOS trademark infringement by Facebook
by David Quintana (gigaherz) 28 Sep '17

28 Sep '17

Your email client is showing you the raw HTML, which contains "&" in place of the & sign. The real link is: https://www.reactos.org/forum/viewtopic.php?f=2&t=16671 You may want to get an email client with HTML support ;P On 28 September 2017 at 09:37, Thomas Mueller <mueller6723(a)twc.com> wrote: > from Alexander Rechitskiy : > >> <div>Hi!</div><div> </div><div> </div><div>Please, read this!</div><div> </div><div>https://www.reactos.org/forum/viewtopic.php?f=2&t=16671</div><div> </div><div>-- <br />Best regards, Alexander Rechitskiy</div><div> </div> > > I copied and pasted your link with the mouse and got > > > Board index > Change font size > > Information > > The requested topic does not exist. > > Board index > The team • Delete all board cookies • All times are UTC + 2 hours > > But the link created by removing "amp;" following "f=2" seemed to work. > > Tom > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev

1 0

Git Migration on October 3!
by Colin Finck 22 Sep '17

22 Sep '17

Hi all! With our infra/toolchain now being fully prepared for the Git migration, I can finally say that there are no more blockers holding us back. Therefore I'm announcing that the migration from SVN to Git will take place on TUESDAY, OCTOBER 3, 2017 During that day (European time) SVN will be turned read-only forever and some of our services may expect temporary downtime. Let's see who will get the last commit ever to SVN :) The new repository will then be available at https://github.com/reactos/reactos, with https://git.reactos.org providing a mirror. The following things are still on the To-Do list, but I don't consider them blockers. We can work on them iteratively after the migration: * Writing a new .gitignore file. * Writing a .gitattributes file to enforce EOL style. * Writing Git guides on our Wiki for beginners and SVN users. Best regards, Colin

2 2

Re: [ros-dev] Regression in r75772 broke multiple disk drive support - format also does not work
by Dimitrij Klingbeil 20 Sep '17

20 Sep '17

Something else seems to be off the rails too... It does't seem possible to format the drive from within ReactOS either. Here's what happens when I try the command-line format utility: - Fill drive D with enough stuff (to see a clear size difference) - Start cmd.exe, then "Format D: /Q" - Format appears to run, writing a new FS - At the end, Format will display a drive size summary - The "used" size is wrong, the drive is still as full as before (!) - When going there with Explorer, the contents have not disappeared (!) - The FS structure seems to be messed up however, as - after a reboot the drive is no longer there (not raw but missing) It looks like Format does not properly unmount the drive before formatting and / or it does not re-mount it after formatting either, or at least that these steps somehow fail to work. The result seems to be a corrupted FS. However I'm not sure if formatting has ever worked - never tried before. Regards Dimitrij ----- Original Message ----- From: "Dimitrij Klingbeil" <dklingb(a)gmail.com> To: "ReactOS Development List" <ros-dev(a)reactos.org> Sent: Wednesday, September 20, 2017 9:07 PM Subject: Re: [ros-dev] Regression in r75772 broke multiple disk drive support > Hi Pierre > > Some parts of this issue seem fixed, but not all - at least not reliably. > > The second drive does appear at first. But as soon as something is done > with it (like starting a program / an installer from it), the system will > become rather temperamental. While the program does run, after the next > ReactOS reboot, the drive disappears again, and this time it completely > disappears rather than looking empty or raw-mounted. After the subsequent > reboot, the drive appears again. Hard to tell, why. > > At least that's what I've tried with an otherwise freshly formatted drive: > > - Create a directory "Software" > - Put inside the Firefox 45.9.0-ESR installer > - Start the installer > - Wait until it finishes extracting its contents in a temp location > - The installer will greet one with its "Welcome" screen > - Rather than continuing, reboot ReactOS now > - After the reboot, drive D is no longer there > - Reboot ReactOS again > - Drive D re-appears and its contents are still in place > - Try the installer again (possibly letting it finish) > - Reboot again, and the drive disappears > - Reboot an additional time, and the drive re-appears > - etc. repetitively, ad infinitum > - One reboot "breaks" something, the next one "fixes" it again > > This was seen with ReactOS r75915, tested just a moment ago. > > Regards > Dimitrij > > > ----- Original Message ----- > From: "Pierre Schweitzer" <pierre(a)reactos.org> > To: <ros-dev(a)reactos.org> > Sent: Wednesday, September 20, 2017 10:48 AM > Subject: Re: [ros-dev] Regression in r75772 broke multiple disk drive > support > > >> This regression got fixed with r75911. >> Can you confirm it's OK on your side? >> >> Le 18/09/2017 à 22:41, Pierre Schweitzer a écrit : >>> Ack. See https://jira.reactos.org/browse/CORE-13805 >>> >>> Thanks for the report. >>> >>> Le 17/09/2017 à 17:39, Dimitrij Klingbeil a écrit : >>>> Hi all, >>>> >>>> It looks like revision 75772 (removed a >>>> "DeviceExt->OpenHandleCount--;") >>>> has introduced some significant unintended consequences. >>>> Ever since I can't get ReactOS to recognize a second hard drive. >>>> >>>> My configuration is like this: >>>> - ReactOS in a VirtualBox VM, VirtualBox version 5.11.18 >>>> - VM configured for Windows 2003 32-bit, with 1 CPU >>>> - Emulated Chipset: PIIX3, no USB, no Audio, no Serial >>>> - AMD-V active, Nested Paging active, >>>> - No paravirtualization interface, no guest additions >>>> - Emulated Storage: SATA controller with 4 ports >>>> - Port 0: First Hard disk (has partition C) >>>> - Port 1: Second Hard disk (has partition D) >>>> - Port 3: CDROM (to install ReactOS from, E) >>>> - Each hard disk has one single primary partition (FAT formatted by an >>>> older >>>> ReactOS setup) >>>> - On C I install ReactOS (re-formatting the partition in the process) >>>> - On D there is some data (a small collection of program installers to >>>> try >>>> out) >>>> >>>> Now, inside ReactOS I cannot see the contents of D. The drive itself >>>> shows >>>> up, but unformatted and of a zero size. In the revisions before 75772 >>>> there >>>> were no problems, I could see the drive and use the data on it. >>>> Re-installing r75771 shows that the drive image is OK and the data is >>>> still >>>> there, so it's not the data that was corrupted. >>>> >>>> If I insert a CDROM image (with ReactOS already running), the CDROM >>>> drive >>>> (E) suddently disappears and D now has the CDROM in it (so happened >>>> just >>>> now >>>> with r75872). When I eject the CDROM, D becomes empty but still shows >>>> the >>>> icon for a CDROM. E does not re-appear. >>>> >>>> 75772 looks like a very small change, but something must have gone >>>> really >>>> off the rails... >>>> >>>> Regards, >>>> Dimitrij >>>> >>>> >>>> >>>> P.S. This was at first sent from the wrong (not subscribed to the list) >>>> address by mistake. I think the first one was rejected by the list SW, >>>> but sorry if the message appears twice. >>>> >>>> _______________________________________________ >>>> Ros-dev mailing list >>>> Ros-dev(a)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(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >

1 0

Rethinking our Git merge workflow
by Colin Finck 19 Sep '17

19 Sep '17

Hi all! After playing around with GitHub's features in https://github.com/colinfinck/sandbox for the last few days, it turns out that its server-side settings hardly prevent repository mess. Although I have set master to be a "protected branch" and enabled the option "Require branches to be up to date before merging", it allows me to push just everything that doesn't rewrite history. This includes any kind of merge commits, even the nasty automatic merges that occur when you commit to your outdated local master and then do the requested "git pull" before pushing. GitHub Staff confirmed to me that GitHub has no way of enforcing a rebase-only workflow. For a self-hosted Git, a simple pre-receive hook like https://stackoverflow.com/a/5493549 would do the trick. The only other option GitHub offers is requiring each commit to go to a branch. Changes to master can only happen through an approved Pull Request then. This would drastically change our workflow though, and I don't think we want this additional burden for every minor change. Before we now reverse our decision for a GitHub master repo, let's verify that a self-hosted Git repo with an enforced rebase-only workflow is really what we want: - It would ensure a linear history in the "master" branch, just like WINE has. If you sort by "Commit Date" instead of "Author Date", the history would even be chronological. - When contributing changes from a branch back to "master" using "git rebase", every single commit is reapplied with a new hash. Except for the author dates, these commits have no link to the original branch. - Without GitHub as the master repo, we would lose the ability to merge Pull Requests directly from the website. That would sooner or later turn the entire Pull Request feature of GitHub useless for us. Contrary to what people told me, GitHub doesn't detect when you merge the Pull Request locally and push these changes back to GitHub. On the other hand, what would an unrestricted GitHub provide us: - Discussing, improving, and later merging Pull Requests directly on the website. Merging, squash merging, and rebase merging is supported. Not just for our own branches, but also for forks of the ReactOS repo. - Our history graph in the "master" branch will inevitably become a stream of parallel lines, making it harder to follow the history chronologically. Worst-case example is the Linux kernel: http://fs5.directupload.net/images/170914/h5pddxx7.png (ok, admittedly gitk renders this graph a bit nicer) Allowing merges used to be an even bigger problem when we still wanted a linear history to replicate SVN revision numbers. But we now replaced revision numbers by the output of "git describe". So maybe merge commits are ok now? At least, we should be able to prevent automatic merge commits by instructing every committer to use "git fetch && git rebase origin" instead of "git pull" when syncing with the server. A nicely written and illustrated (Tortoise)Git guide on the Wiki should do the job :) I tend to favor the second option right now and allow merges, but I definitely need more input on this from you. Best regards, Colin

5 7

Re: [ros-dev] Rethinking our Git merge workflow
by Alex Ionescu 15 Sep '17

15 Sep '17

Yes, I prefer GitHub too. I just meant GitLab > BitBucket :) Best regards, Alex Ionescu On Fri, Sep 15, 2017 at 4:02 PM, Colin Finck <colin(a)reactos.org> wrote: > Am 15.09.2017 um 02:26 schrieb Alex Ionescu: > > Have you looked at GitLabs? BitBucket is a shit show. > > GitLab would be my option if we ever need to move away from GitHub. > But as long as people are okay with contributing exclusively through > Pull Requests, GitHub is a viable solution for us. > I think the added exposure and easier access for newcomers are worth > changing our development model. > > > Cheers, > > Colin > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

1 0

Re: [ros-dev] Rethinking our Git merge workflow
by Alex Ionescu 15 Sep '17

15 Sep '17

Have you looked at GitLabs? BitBucket is a shit show. Best regards, Alex Ionescu On Fri, Sep 15, 2017 at 1:07 AM, Thomas Faber <thomas.faber(a)reactos.org> wrote: > I'm wary of opening up pushing to master. If we really want a linear > history, it should be enforced. Accidents with version control happen > all the time (when was the last time the SVN pre-commit hook stopped you > from committing because you forgot to set eol-style?). > > I wouldn't mind forcing the use of pull requests, assuming we can set it > up so that merge is allowed with no reviews (those would be recommended, > but enforcing them seems too much). > > Though I'm also okay with giving up the linear history idea altogether, > or hosting the repo elsewhere (e.g. we could host a Bitbucket instance). > > > On 2017-09-14 17:48, David Quintana (gigaherz) wrote: > >> I vote for recommending devs to use pull requests, and to make it a >> semi-strict policy that devs who push directly to master should ALWAYS >> make >> sure to pull and rebase before pushing. >> >> I myself intend on almost exclusively contribute through pull requests. >> This means: >> >> 1. I'll push to my own fork, and work backed by the fork >> 2. When I'm done doing something, I will use the pull request feature, >> rather than "git push upstream/master" >> 3. If the changes are non-trivial, I'll ask for a second opinion from >> some other developer >> 4. I'll push "merge with rebase" myself, but only when I feel the >> changes are "sufficiently approved" >> >> I would vote for using such a workflow as a primary way of contributing, >> since it avoids all sorts of issues, and has the added benefit of the >> automatic "merge with rebase". >> >> On 14 September 2017 at 17:23, Colin Finck <colin(a)reactos.org> wrote: >> >> Hi all! >>> >>> After playing around with GitHub's features in >>> https://github.com/colinfinck/sandbox for the last few days, it turns >>> out that its server-side settings hardly prevent repository mess. >>> >>> Although I have set master to be a "protected branch" and enabled the >>> option "Require branches to be up to date before merging", it allows me >>> to push just everything that doesn't rewrite history. This includes any >>> kind of merge commits, even the nasty automatic merges that occur when >>> you commit to your outdated local master and then do the requested "git >>> pull" before pushing. >>> GitHub Staff confirmed to me that GitHub has no way of enforcing a >>> rebase-only workflow. For a self-hosted Git, a simple pre-receive hook >>> like https://stackoverflow.com/a/5493549 would do the trick. >>> >>> The only other option GitHub offers is requiring each commit to go to a >>> branch. Changes to master can only happen through an approved Pull >>> Request then. This would drastically change our workflow though, and I >>> don't think we want this additional burden for every minor change. >>> >>> Before we now reverse our decision for a GitHub master repo, let's >>> verify that a self-hosted Git repo with an enforced rebase-only workflow >>> is really what we want: >>> >>> - It would ensure a linear history in the "master" branch, just like >>> WINE has. If you sort by "Commit Date" instead of "Author Date", the >>> history would even be chronological. >>> - When contributing changes from a branch back to "master" using "git >>> rebase", every single commit is reapplied with a new hash. Except for >>> the author dates, these commits have no link to the original branch. >>> - Without GitHub as the master repo, we would lose the ability to merge >>> Pull Requests directly from the website. That would sooner or later turn >>> the entire Pull Request feature of GitHub useless for us. >>> Contrary to what people told me, GitHub doesn't detect when you merge >>> the Pull Request locally and push these changes back to GitHub. >>> >>> >>> On the other hand, what would an unrestricted GitHub provide us: >>> >>> - Discussing, improving, and later merging Pull Requests directly on the >>> website. Merging, squash merging, and rebase merging is supported. Not >>> just for our own branches, but also for forks of the ReactOS repo. >>> - Our history graph in the "master" branch will inevitably become a >>> stream of parallel lines, making it harder to follow the history >>> chronologically. Worst-case example is the Linux kernel: >>> http://fs5.directupload.net/images/170914/h5pddxx7.png >>> (ok, admittedly gitk renders this graph a bit nicer) >>> >>> Allowing merges used to be an even bigger problem when we still wanted a >>> linear history to replicate SVN revision numbers. But we now replaced >>> revision numbers by the output of "git describe". So maybe merge commits >>> are ok now? >>> At least, we should be able to prevent automatic merge commits by >>> instructing every committer to use "git fetch && git rebase origin" >>> instead of "git pull" when syncing with the server. A nicely written and >>> illustrated (Tortoise)Git guide on the Wiki should do the job :) >>> >>> >>> I tend to favor the second option right now and allow merges, but I >>> definitely need more input on this from you. >>> >>> >>> Best regards, >>> >>> Colin >>> >> > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

2 1

Git Migration Newsletter #2
by Colin Finck 13 Sep '17

13 Sep '17

Hi all! Let me give a short update on the Git Migration: * The data from the committer table has been converted into an identity map for the SVN->Git conversion tool: https://github.com/ColinFinck/reactos-git-conversion-scripts/blob/master/re… Together with my hacked version of svn-all-fast-export (https://github.com/ColinFinck/svn2git), this results in a really nice and clean Git repo :) Further changes to your names or E-Mail addresses in that committer table won't be taken into account. Please add your GitHub usernames to that table though! * As you can imagine, our tree and tools need several changes to deal with the change from SVN revision numbers to Git commit hashes. My first patch for reporting the "Git revision" in our codebase is ready and open for discussion: https://github.com/ColinFinck/reactos-git-conversion-scripts/commit/0aaa6ff… More to follow! Cheers, Colin

1 0

Git Migration Newsletter
by Colin Finck 12 Sep '17

12 Sep '17

Hi all! Let me give a public update about our Git Migration Decisions after the last meeting: * The migration of our SVN repository "reactos" is going to happen in September/October. * https://github.com/reactos/reactos will become our master repository as we want to take advantage of GitHub's Pull Request features. This means, all developers must register for GitHub accounts now. * git.reactos.org will remain as a replication slave. If we ever have severe problems with GitHub, we can switch back to a self-hosted Git in no time. * We will enforce a linear history in the "master" branch through server-side GitHub settings. You may create and push as many branches as you want and do whatever you want there, but when you want to commit the changes back to "master", you can only do so over a "git rebase". * BuildBot builds will get a naming scheme like: reactos-bootcd-0.4.7-dev+344-5f3c53e2a-gcc.7z That means 344 commits after the tag "0.4.7-dev" has been created, with this particular commit having the short hash "5f3c53e2a". Whenever we branch for a release like "0.4.6", we will now not just create the branch, but also tag "master" with "0.4.7-dev" to make this naming scheme possible. More newsletters like this may follow when I have more information to share or get the impression that some decisions haven't reached all developers yet. Best regards, Colin

4 6

Re: [ros-dev] Git Migration Newsletter
by David Quintana (gigaherz) 10 Sep '17

10 Sep '17

The git repository data is compressed, and takes in the order of 100 mb. The checkout size will be somilar but the .git folder is much more compact than the .svn folder. On 10 Sep 2017 10:08 am, "Michael Fritscher" <michael(a)fritscher.net> wrote: Hi, are there estimation about the size of a git clone vs. a svn checkout? I'm afraid that I'll need to free much space beforehand... Best regards, Michael Fritscher > If you mean your local working copy: clone into a separate folder, and > copy > over the files. Subversion checkout is only the current commit data, while > git clones contain ALL THE HISTORY, so you can't "migrate" anything, > because the svn metadata doesn't contain any of the needed info. Even if > you could somehow migrate using a tool, the tool would still have to > perform a clone, and would just import the file status. > > On 6 September 2017 at 23:06, Thomas Mueller <mueller6723(a)twc.com> wrote: > >> from Colin Finck: >> >> > Let me give a public update about our Git Migration Decisions after >> the >> last >> > meeting: >> >> > * The migration of our SVN repository "reactos" is going to happen in >> > September/October. >> >> > * https://github.com/reactos/reactos will become our master repository >> as we >> > want to take advantage of GitHub's Pull Request features. >> > This means, all developers must register for GitHub accounts now. >> >> > * git.reactos.org will remain as a replication slave. If we ever have >> severe >> > problems with GitHub, we can switch back to a self-hosted Git in no >> time. >> >> > * We will enforce a linear history in the "master" branch through >> server-side >> > GitHub settings. You may create and push as many branches as you want >> and do >> > whatever you want there, but when you want to commit the changes back >> to >> > "master", you can only do so over a "git rebase". >> >> > * BuildBot builds will get a naming scheme like: >> >> > reactos-bootcd-0.4.7-dev+344-5f3c53e2a-gcc.7z >> >> > That means 344 commits after the tag "0.4.7-dev" has been created, >> with this >> > particular commit having the short hash "5f3c53e2a". >> > Whenever we branch for a release like "0.4.6", we will now not just >> create the >> > branch, but also tag "master" with "0.4.7-dev" to make this naming >> scheme >> > possible. >> >> >> > More newsletters like this may follow when I have more information to >> share or >> > get the impression that some decisions haven't reached all developers >> yet. >> >> Is there a convenient way to migrate an svn tree to git, or would it be >> necessary to git-clone to a separate tree? >> >> Will the boot CD images be in 7z (p7zip) format: >> >> What has kept me from trying ReactOS is not having a place to put it, >> considering ReactOS does not successfully boot from USB. >> >> My hard drives are partitioned GPT. >> >> Tom >> >> >> _______________________________________________ >> 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 _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

2 3

Git Migration: The documentation, rossubsys and wallpapers directories
by Colin Finck 09 Sep '17

09 Sep '17

Hi all! As you know, we have to give up our "modules" directory concept when switching to Git, because Git doesn't support checking out an arbitrary directory into a subdirectory of a Git clone. Therefore, the first commit to the migrated repository will make the "reactos" directory the new root and move "rosapps" and "rostests" permanently into "modules". We can then introduce an environment variable/CMake variable/something else to enable or disable building of them on demand (suggestions are welcome!) But what will happen to the remaining directories in /trunk, namely "documentation", "rossubsys", and "wallpapers"? * Commits to "documentation" never had a relation to "reactos" commits, so nothing is lost if we put that directory into a separate repo "documentation.git" and remove all traces to it from the history of "reactos.git". I'd go this way if there are no objections. * I don't get the idea of that "rossubsys" directory created in 2014.. These subsystems are all stubs, never built with modern ReactOS, and no work has happened since "reviving" them. I would just go and remove them again. You can always find them in our repository history. * The "wallpapers" directory is a harder candidate. On the one hand, we don't want to bloat our ReactOS builds by including wallpapers in every build. Also the number of wallpapers may increase in the future, which could bloat the "reactos.git" repo even more. On the other hand, the wallpapers have always accompanied our release branches, so there is a value of having them tracked next to our code. I could put them in a separate repository "wallpapers.git" now and remove all traces to them in the "reactos.git" repo. But then again, how are they picked up by the build process in the future if we can't check them out into a subdirectory of "modules"? Another alternative is moving them to "modules/wallpapers_disabled". Then they are not picked up by the build process until they are renamed to "modules/wallpapers" for releases. What are your opinions on this? Cheers, Colin

8 15

un-official Builds of ReactOS 0.4.6 with USB support
by Alexander Rechitskiy 07 Sep '17

07 Sep '17

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev