Ros-dev

ros-dev@reactos.org

5790 discussions

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev