- Ros-dev - ReactOS.org

Status Meeting (October 2017)

by Giannis Adamopoulos

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 … [View More]

7 years, 7 months

3
2
0 0

JIRA up again - Do we still need FishEye?

by Colin Finck

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, … [View More]

7 years, 7 months

3
2
0 0

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

‌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

7 years, 7 months

4
3
0 0

Testing Pull Requests

by Colin Finck

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 … [View More]

7 years, 7 months

3
3
0 0

GitHub Newbie Question

by Hermès BÉLUSCA - MAÏTO

<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>

7 years, 7 months

3
2
0 0

Re: [ros-dev] GitHub Newbie Question

by hermes.belusca＠sfr.fr

<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>   … [View More]

7 years, 7 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [reactos] 01/01: Fix remaining text file line endings in the tree. (#18)

by Colin Finck

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

7 years, 8 months

1
0
0 0

Re: [ros-dev] ReactOS Repository migrated to GitHub

by Can Tasan

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 … [View More]

7 years, 8 months

2
1
0 0

Re: [ros-dev] ReactOS Repository migrated to GitHub

by hermes.belusca＠sfr.fr

<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="… [View More]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> [View Less]

7 years, 8 months

1
0
0 0

ReactOS Repository migrated to GitHub

by Colin Finck

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 … [View More]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 [View Less]

7 years, 8 months

3
2
0 0

Regression in r75772 broke multiple disk drive support

by Dimitrij Klingbeil

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 - … [View More]

7 years, 8 months

2
4
0 0

Status Meeting (September 2017)

by Colin Finck

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 … [View More]

7 years, 8 months

1
1
0 0

once agaon about ReactOS trademark infringement by Facebook

by Alexander Rechitskiy

7 years, 8 months

3
2
0 0

Re: [ros-dev] once agaon about ReactOS trademark infringement by Facebook

by David Quintana (gigaherz)

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> &… [View More]

7 years, 8 months

1
0
0 0

Git Migration on October 3!

by Colin Finck

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.… [View More]

7 years, 8 months

2
2
0 0

Re: [ros-dev] Regression in r75772 broke multiple disk drive support - format also does not work

by Dimitrij Klingbeil

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 … [View More]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 > [View Less]

7 years, 8 months

1
0
0 0

Rethinking our Git merge workflow

by Colin Finck

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 … [View More]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 [View Less]

7 years, 8 months

5
7
0 0

Re: [ros-dev] Rethinking our Git merge workflow

by Alex Ionescu

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. … [View More]

7 years, 8 months

1
0
0 0

Re: [ros-dev] Rethinking our Git merge workflow

by Alex Ionescu

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 … [View More]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 > [View Less]

7 years, 8 months

2
1
0 0

Git Migration Newsletter #2

by Colin Finck

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. … [View More]

7 years, 8 months

1
0
0 0

Git Migration Newsletter

by Colin Finck

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 … [View More]

7 years, 8 months

4
6
0 0

Re: [ros-dev] Git Migration Newsletter

by David Quintana (gigaherz)

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, … [View More]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 [View Less]

7 years, 8 months

2
3
0 0

Git Migration: The documentation, rossubsys and wallpapers directories

by Colin Finck

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 (… [View More]

7 years, 8 months

8
15
0 0

un-official Builds of ReactOS 0.4.6 with USB support

by Alexander Rechitskiy

7 years, 8 months

1
0
0 0

Bluetooth Stack

by Alexander T.

Hi all! I have to do a semester project on operating systems in my university. In GSoC 2017 ideas there is problem called «Bluetooth stack». So, is this problem already solved? If not, then could anyone tell me more about it? Sincerely, Alexandr Tsukanov

7 years, 9 months

2
1
0 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