Hi all!
I've held a presentation at Hackfest today regarding Licensing Best
Practices, different positions about the GPL and its influence, and ways
to improve ReactOS' conformance with all involved licenses.
I think we should treat this subject even more seriously than others,
given that we are an Open-Source project trying to provide an
alternative to a proprietary product. Also licensing questions arise
from time to time, which is why we should collect some answers.
Please watch the video at https://youtu.be/OTVVz9VLisU or see the slides
at
https://svn.reactos.org/press-media/trunk/Events/2017%20-%20Hackfest/Licens…
Discussions are open now! :)
But if there are no objections, let's introduce SPDX license headers,
.ABOUT files, and a complete license list as soon as possible.
Cheers,
Colin
Hey Eric,
The Battery icon, Hotplug icon and Quick Launch toolbars are currently
developed as part of the Google Summer of Code "Taskbar Shell Extensions
for ReactOS" project.
Summer of Code ends next week, so you are welcome to join the Code
Review at https://code.reactos.org. I guess CR-122 will be shortly
updated with the latest changes there.
Let's try to not duplicate efforts here ;)
Best regards,
Colin
I have recently added ReactOS as a distribution into Wine Application
Compatibility database as ReactOS uses most of Wine components.
ReactOS-Windows incompatibilities can now be tracked like Wine-Windows
incompatibilies.
Why not Monero too?
Sent from UNKNOWN SMARTPHONE - K91820
-------- Messaggio originale --------
Da: Erkin Alp Güney <erkinalp9035(a)gmail.com>
Data: 13/07/17 21:52 (GMT+01:00)
A: ros-dev(a)reactos.org
Oggetto: [ros-dev] Ethereum for fundraiser
Ethereum is a decentralised cryptocurrency based on proof of work and
proof of stake consensus with Turing-complete scripting. Utilising
Ethereum for fundraiser will allow us to remove the middlemen from
raising funds and allow us to distribute them more directly. I want to
be first contract programmer for ReactOS ethereum account. Any kind of
release schemes may be developed. However, this will need detailed
discussion and official approval first.
Yours, faithfully
Erkin Alp
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
I would strongly suggest using one master repo. Multi-repo projects and
their brethren are a mess.
Best regards,
Alex Ionescu
On Wed, Aug 2, 2017 at 1:18 PM, David Quintana (gigaherz) <
gigaherz(a)gmail.com> wrote:
> We have! If you look at Colin's email, it has a link to a google doc, we
> list Repo in it, and why we think it's not fit for our use :)
>
> That aside, I had a new idea, which I mentioned on IRC. I have added it to
> the document.
>
> On 2 August 2017 at 11:52, Alexander Sh. <chaez.san(a)gmail.com> wrote:
>
>> Have a look at Repo: https://code.google.com/archive/p/git-repo/
>> It is used by Android devs.
>>
>> 2 авг. 2017 г. 12:28 пользователь "David Quintana (gigaherz)" <
>> gigaherz(a)gmail.com> написал:
>>
>> The issue comes when we have to do regression-testing. We would need a
>>> tool that knows how to match up core, system, tests, ... otherwise
>>> debugging regressions is going to be hellish.
>>>
>>> On 2 August 2017 at 11:17, Alexander Sh. <chaez.san(a)gmail.com> wrote:
>>>
>>>> Since we have RosBE, we can have multiple repositories without actually
>>>> binding them and download them on demand. Or we can make a build script for
>>>> every new small module that downloads (clones) repos it needs.
>>>>
>>>> 2 авг. 2017 г. 11:41 пользователь "Colin Finck" <colin(a)reactos.org>
>>>> написал:
>>>>
>>>> Hi all!
>>>>
>>>> After David has successfully tested a first SVN -> Git conversion of
>>>> our repo, here comes the next challenge: Finding a way to preserve our
>>>> current modularization into reactos, rosapps, rostests and paving the way
>>>> for even more modularization.
>>>> My vision for the future is a small "core" repo that only contains our
>>>> host tools and SDK. We could also split off subprojects like fast486/ntvdm
>>>> or Paint into individual repos. Now that Microsoft has abandoned them under
>>>> Windows, they may individually attract developers who would never hack on
>>>> the entire ReactOS repo. Furthermore, 3rd party components could be
>>>> imported through their repo instead of copy-pasting their code without
>>>> history (as we do now).
>>>> Even if that vision is a distant goal, the technology for it is already
>>>> required for a reactos, rosapps, rostests modularization.
>>>>
>>>> Isn't that a perfect scenario for Git submodules?
>>>> Not sure: I'm not aware that they support the concept of optional
>>>> modules. You could only check out the "core" repo with all defined
>>>> submodules. This would make it impossible to use "core" only to build
>>>> Paint. There also seem to be other drawbacks when using submodules:
>>>> https://codingkilledthecat.wordpress.com/2012/04/28/why-your
>>>> -company-shouldnt-use-git-submodules/
>>>>
>>>> Alternatives like Git subtrees, Google Repo, and Gitslave exist, but
>>>> there is even less information about them. Furthermore, I think a good
>>>> integration into GUI tools like TortoiseGit is also a requirement for most
>>>> of us.
>>>>
>>>> David and I have started to write down our findings:
>>>> https://docs.google.com/document/d/1Ey1xdS_0GcG7p7ZgHZBh4A3V
>>>> Mq2uxyw5MpnUXbT8z6w/edit
>>>> Your input on this is very welcome!
>>>>
>>>> I guess any migration to Git is blocked before we have a solution here.
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Colin
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>> _______________________________________________
>> 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
>
>
Hi all!
We're going to have the missed monthly status meeting for July tomorrow.
Time will be 19:00 UTC as always and you will get your credentials
shortly before the meeting.
Agenda proposals so far include:
- The 0.4.6 release
- The upcoming Hackfest
- Design of the RAPPS setup mode
Please post any additional agenda proposals here.
See you tomorrow!
Colin
Since we have RosBE, we can have multiple repositories without actually
binding them and download them on demand. Or we can make a build script for
every new small module that downloads (clones) repos it needs.
2 авг. 2017 г. 11:41 пользователь "Colin Finck" <colin(a)reactos.org> написал:
Hi all!
After David has successfully tested a first SVN -> Git conversion of our
repo, here comes the next challenge: Finding a way to preserve our current
modularization into reactos, rosapps, rostests and paving the way for even
more modularization.
My vision for the future is a small "core" repo that only contains our host
tools and SDK. We could also split off subprojects like fast486/ntvdm or
Paint into individual repos. Now that Microsoft has abandoned them under
Windows, they may individually attract developers who would never hack on
the entire ReactOS repo. Furthermore, 3rd party components could be
imported through their repo instead of copy-pasting their code without
history (as we do now).
Even if that vision is a distant goal, the technology for it is already
required for a reactos, rosapps, rostests modularization.
Isn't that a perfect scenario for Git submodules?
Not sure: I'm not aware that they support the concept of optional modules.
You could only check out the "core" repo with all defined submodules. This
would make it impossible to use "core" only to build Paint. There also seem
to be other drawbacks when using submodules: https://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/
Alternatives like Git subtrees, Google Repo, and Gitslave exist, but there
is even less information about them. Furthermore, I think a good
integration into GUI tools like TortoiseGit is also a requirement for most
of us.
David and I have started to write down our findings:
https://docs.google.com/document/d/1Ey1xdS_0GcG7p7ZgHZBh4A3V
Mq2uxyw5MpnUXbT8z6w/edit
Your input on this is very welcome!
I guess any migration to Git is blocked before we have a solution here.
Cheers,
Colin
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Hi all!
After David has successfully tested a first SVN -> Git conversion of our
repo, here comes the next challenge: Finding a way to preserve our
current modularization into reactos, rosapps, rostests and paving the
way for even more modularization.
My vision for the future is a small "core" repo that only contains our
host tools and SDK. We could also split off subprojects like
fast486/ntvdm or Paint into individual repos. Now that Microsoft has
abandoned them under Windows, they may individually attract developers
who would never hack on the entire ReactOS repo. Furthermore, 3rd party
components could be imported through their repo instead of copy-pasting
their code without history (as we do now).
Even if that vision is a distant goal, the technology for it is already
required for a reactos, rosapps, rostests modularization.
Isn't that a perfect scenario for Git submodules?
Not sure: I'm not aware that they support the concept of optional
modules. You could only check out the "core" repo with all defined
submodules. This would make it impossible to use "core" only to build
Paint. There also seem to be other drawbacks when using submodules:
https://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-should…
Alternatives like Git subtrees, Google Repo, and Gitslave exist, but
there is even less information about them. Furthermore, I think a good
integration into GUI tools like TortoiseGit is also a requirement for
most of us.
David and I have started to write down our findings:
https://docs.google.com/document/d/1Ey1xdS_0GcG7p7ZgHZBh4A3VMq2uxyw5MpnUXbT…
Your input on this is very welcome!
I guess any migration to Git is blocked before we have a solution here.
Cheers,
Colin
Hello,
After recent changes in explorer, comctl32 and uxtheme the state of themes in reactos was improved a lot. I would like to ask your opinions about enabling themes in 3rd stage. It is also possible to have an option in 2nd stage to select if we want 3rd stage to have themes enabled. Do you think this should be enabled by default or not? All ideas are welcome. My intention is to complete it ASAP so that it can make in the release.
Thanks,
Giannis Adamopoulos
