Hello all,
I am Pratik Singhal, a 3rd year undergraduate student studying Computer
Science studying in BITS-Pilani, Goa Campus, India.
I want to pursue the project NTFS Driver Improvement project as a part of
Google summer of code 2016.
I have previously participated in Google summer of Code 2015 for FreeBSD
operating system and have done some kernel hacking before.(
https://wiki.freebsd.org/SummerOfCode2015/CubieBoardSupport)
I have also made a mini operating system of my own.
I am sure, that the experience I gained while previously for FreeBSD will
certainly help me in understanding the ReactOS code base quickly which will
be useful for the project. I don't have any significant experience on
working with file systems before, but I am confident that with some
guidance from fellow developers I will be able to learn new things which
will help in completion of the project. Also, I haven't had any access to
Windows source code , so that shouldn't be a problem.
We will have to figure out concrete goals of the project, full term and mid
term deliverable and a plan for completion of project, if it is to be
selected for Google summer of Code.
It'll be great if somebody, could mentor me for this project.
Thanks,
Pratik Singhal
Hi,
After five years the ReactOS Project is returning to the Google Summer
of Code[1]!
On the heels of the 0.4.0 release the project's aim is on creating
smoother user experiences and generally making the system feel more
robust and pleasant to use. The team is looking for students interested
in learning more about the NT architecture that underpins the most
widely used desktop operating system in the world and who wants to take
part in the creation of an open source implementation of it.
Please head on over to the project proposal page[2] to see some of the
ideas we've come up with so far. If you have your own bright idea on how
to make ReactOS even better don't be afraid to share as we're always
open to new ideas.
Either way please head over to the IRC channel[3] to give us a shout if
you're interested. We promise, we don't bite. Mostly of the time ;)
Cheers,
Amine.
[1] https://summerofcode.withgoogle.com/organizations/6324900541235200/
[2] https://www.reactos.org/wiki/Google_Summer_of_Code_2016_Ideas
[3] https://reactos.org/irc
Hi guys,
I would like to understand whats the rationale behind changing the ReactOS
trunk version from 0.4-SVN to 0.5-SVN (see revision 70818) whereas we
have just started to release ROS 0.4.0 only?
Thanks in advance for your explanations!
Cheers,
Hermès.
Hello there,
A couple of you have already seen me make this request in IRC, but I
will make a more formal one here.
I've noticed that ReactOS still uses the Subversion VCS, and while this
might have been a good choice when it was initially set up, in 2016, it
is a rather backwards and self-defeating method to develop software.
For users without write access to the repository, developing against it
means that SVN serves barely better than copying a whole directory just
to do a diff against it. Submitting patches means that they'll not be
split up into logical steps (commits), and increases the difficulty of
determining what a patch contains, or even making a sane commit message
for it.
In the modern DVCS world, this simply doesn't need to hold true. Each
clone of the repository is exactly as the name implies: it's a clone.
Users that want to hack away on the source are freer to do so, create
their own private branches, commit to all their heart's content, and
submit a pull request back to the project (don't think of GitHub as the
only example of pull requests: they come in many forms and can even
include "sending patches to a mailing list", which would still retain
better properties than the Subversion model).
I do urge to give consideration to moving development infrastructure to
Git[*]. It would greatly ease both developer burden, and especially
contributors' burden. It is, simply, what the modern world uses. :-)
Secondary tale: I'm aware of git.reactos.org and GitHub both having a
git-svn clone of the repository. These are "okay" for the most basic
glances of the repo, but be warned that git-svn is unmaintained,
extremely buggy, and should never be used for a serious migration. For
a migration, we'll use reposurgeon. Each repository is unique and the
problems cannot be fully automated away, sorry. Human intervention is
required to do these properly.
---
Now that I've talked about why, I'll note some observations about the
Subversion repository in its present state:
* Multiple logical projects exist in the namespace. At the very least,
each of the subdirectories under /trunk should be translated to
independent Git repositories. If there are even more historical ones
(I've only looked at HEAD), we should get a list of them.
* Old versions of RosBE are under /tags. Is RosBE maintained
elsewhere?
* A lot of old and new branches. If any of these are already merged
into trunk, it may be best to just discard their preservation. Per-
developer branches might work out best if each developer took
'ownership' of them with independent repository clones. An
infrastructure and organization like https://git.kernel.org/ may be
worth looking into.
* Tagging conventions at least appear sane and logical, but they
should be named with more conventional names for Git, usually a bare
number or prefixed with v. For example, "0.3.17", "0.4.0", or
"v0.3.17", "v0.4.0" -- this is a pure policy decision, but with one-
project-per-repository, it keeps things looking clean.
* It is very large. Over a gigabyte as a live repository, 14GB as a
full stream dump. It will require a lot of memory to process and I'm
not sure my own system will handle that. It will also take a long time
to process and develop a migration -- the upper bound can be on the
order of months of work. Development in Subversion should not be halted
until the day the migration is being completed.
[*] Okay, it doesn't have to be Git. Hypothetically, any DVCS will do,
but only Mercurial has enough traction to be a viable alternative.
Thanks for listening,
Mike
On Thu, Feb 25, 2016 at 5:54 AM, David Quintana (gigaherz)
<gigaherz at gmail.com> wrote:
> I think the real goal with moving to a platform such as github is reducing
> the entry barriers for new contributors. As it has been mentioned already,
> almost all projects who moved from SVN with "send patches" contribution
> system, to Git/Hg with Pull Requests have got non-negligible growth in
> contributions.
>
I don't know... Speaking about "the entry barriers for new
contributors", this is contributing now:
1. svn checkout svn://svn.reactos.org/reactos/trunk/reactos
2. // make changes
3. svn diff > patch_for_JIRA_issue
compare it with "Git/Hg with Pull Requests":
1. Create/Log in to your GitHub account
2. Go to the page for the code respository you want to contribute to
(the “upstream”)
3. “Fork” the repository (this creates a clone to your GitHub account)
4. Create a local clone of your fork with git clone
5. Create a local branch for your changes
6. Make your changes and commit them to your local branch with git
commit, ensuring to include a descriptive commit message
7. Push the branch to your GitHub fork using git push
8. Go to the page for the upstream repository go to the pull requests
tab
9. Click the “New Pull Request” Button
10. Select the branch you want to submit, and write a summary of what
your change explaining what it is intended to do and how it is
implemented
which is the process for "Raising a Pull Request" described in here:
http://oss-watch.ac.uk/resources/pullrequest (the preferred source
chosed by Google search for explaining to me what a "pull request" is).
Ignoring the fact that new ReactOS contributions will have as
prerequisite the signing up for a (commercial) third party service,
GitHub may appear a good move for those familiar with GitHub intrinsic
knowledge, but it doesn't to for the rest of us.
I know that Amine Khaldi offered (on IRC, on #reactos-dev) to help to
"resort to manually relaying to GH" "only if someone doesn't want to"
sign up, but this will be counterproductive (who wants to be a burden
and to abuse in such a way precious developer's time?) and will most
likely prevent many not-so-motivated (but potentially precious)
contributions outside this cherished GitHub community.
Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of a month, 25th of February, 19:00 UTC, as usual.
IRC service will only be started shortly before the meeting. Your
participation passwords and server address will be emailed to you
shortly before the meeting starts, and they are going to be different
once again as they are not stored in any database. Hopefully it's not
much of inconvenience.
Please send agenda proposals to me before the meeting.
Regards,
Aleksey Bragin
Nearly ten years ago the ReactOS Project released version 0.3.0. Today
we are proud to announce the formal release of version 0.4.0!
A great deal of work has gone into making this release happen and as we
look back it is remarkable to consider how far the project has come
since that release a decade ago. This release is both a celebration of
and a testament to everything that the ReactOS team and community has
achieved together.
Here we document some of the highlights that separate 0.4.0 from not
just the 0.3.17 release but also the cumulative achievements that the
0.3.x series achieved: https://reactos.org/project-news/reactos-040-released
A changelog is available at: https://reactos.org/wiki/ChangeLog-0.4.0
Thank you to all of you for having stood by the project for this long
and we hope rewarding journey.
For those of you chomping at the bit to check out the release, please go
to the download page to get it now: https://reactos.org/download
Hi all ! Please have a look at
http://www.reactos.org/forum/viewtopic.php?f=2
<http://www.reactos.org/forum/viewtopic.php?f=2&t=14713> &t=14713 , I think
these two posts (at the time of writing this mail) show/remind few points
about ReactOS that need to be more emphased/better explained in our website
(and concerning the license, better be shown; notice that we run with GPL +
BSD for some parts of the code).
Regards,
Hermès
