Re: [ros-dev] Current votes on the situation with the 0.4.14 release

[Mark Jansen]

As noted in mattermost,
I'd like to at least consider what Joachim has to say about this, 
considering the amount of work he spends on releases.


Regards,
Mark

PS:
Oleg Dubinskiy's vote is not empty, he simply sent it as html so it is 
not nicely displayed in the mailing list.


On 07-Mar-21 11:18, George Bişoc wrote:

During the last days of February of this year some team members have 
participated in a vote concerning the delay of 0.4.14 release due to the amount 
of regressions making it not eligible to be released as per the release 
engineering guidelines. As 1st of March has already passed, this is the current 
situation with the votes as they stand out for the moment in the following 
order.

1. Release 0.4.14 as-is (with its known regressions as of now)
=
* Javier Agustìn Fernàndez Arroyo
* Stanislav Motylkov
* Hermès BÉLUSCA-MAÏTO
* Alexander Rechitskiy
* George Bişoc

2. Skip 0.4.14
=
* Victor Perevertkin
* Joshua Rice (non team member)

3. Fix the bugs as soon as possible
=
None

Oleg Dubinskiy's vote is not counted because his mail is apparently empty 
(???). Considering the collected votes, should we extend the period of voting 
for a few days so that the other team members can have an opinion too regard 
the matter or shall we conclude the voting as is and proceed further with 
releasing 0.4.14?

Regards,
George

___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] CLT 2021. I need a few more ppl as stand members

[Mark Jansen]

I cannot guarantee availability,
but I will try to at least hop in a few times to answer some questions.

Regards,

Mark

On 20-Feb-21 20:18, Aleksey Bragin wrote:

If noone volunteers, then let me volunteer.

I perfectly remember CLT 2010 (and 2009), I enjoyed it, so why not 
enjoy it this time too? :-)


Regards,
M.Sc. Alexey Bragin

On 2/20/2021 7:49 PM, Daniel Reimer wrote:
Small addendum. Not speaking german is no excuse. We already had non 
german speakers with us there who talked in english and Aleksey was 
greeted in finest russian.


Am 20.02.2021 um 17:30 schrieb Daniel Reimer:

SO, one day left...

No reply yet by anyone who wants to join. Well Amine Telegrammed me 
telling me he can help in case of emergency. But how about some more 
ppl who wanna show off ROS? Tbh I am tired of playing tag every year 
again and again. Especially the e.V. members can't say this came by 
surprise. So let's try it a bit different. If noone shows up we will 
try our best to do it on our own, but that will be that last time I 
will take lead in some event management. I do this not for myself 
here, I can spend my time with other stuff, too and that will be the 
case starting this year if no one will answer here in time now. 
Sorry if someone feels offended by this mail, but if no one wants us 
to take part in CLT, then tell me earlier next time!


Greetings

Daniel

Am 18.02.2021 um 10:53 schrieb Daniel Reimer:
Not much to say. I paste a translated mail from CLT staff in here 
now to give you all (non private) information we have by now:


...

As you can imagine, everything is a bit different this year. Due to 
the Corona situation, we will not be able to meet at the TU 
Chemnitz in March. Therefore, the Chemnitzer Linux-Tage 2021 will 
take place purely virtually. With this mail we would like to inform 
you about the essential boundary conditions.


You can register additional booth attendants until February 21.
We will provide you with a virtual videoconference room in our open 
source videoconferencing system BigBlueButton. Our visitors will be 
able to enter this videoconference room during the event and 
interact with you. We will offer demo dates for BigBlueButton. 
Until then you can test it at the following URL:

https://demo.bigbluebutton.org/gl/

You are free to decide about the design of your booth program. You 
can either be available for talks and discussions the whole time or 
publish a small booth program yourself (e.g. mini-discussion 
rounds, quizzes, whatever comes to your mind). IMPORTANT: Please 
send us your booth program (time, title, short description) by 
e-mail by February 21.
If you do not create your own program, please make sure that at 
least one of you is always available in the video conference room 
during the entire event, so that the booth does not look abandoned.




So I need one or two more guys to help out. Date is 13. / 14. March 
2021. If you wanna help out, I will need your full name, title if 
existing and email address.


HELP MEEE

thx

Daniel Reimer



___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev

[ros-dev] FOSDEM online

[Mark Jansen]

Hello,

This year FOSDEM is going to be an online event:
https://fosdem.org/2021/news/2020-12-11-stands-cfp/

Are there volunteers for an online ReactOS stand?

We would need some short video's for introduction and demonstration 
purposes,

as well as some people active in a chat room answering questions.

Regards,

Mark


___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Status Meeting (November 2020)

[Mark Jansen]

Agreed with Colin.


On 26-Nov-20 09:27, Colin Finck wrote:

Am 25.11.2020 um 22:26 schrieb Hermès BÉLUSCA-MAÏTO:
What about that discussion about why we have ditched out MSVC 2010 
support


You mean reintroducing an ancient compiler that forces us to hack 
around its incapacity to deal with anything more modern than C89? One 
that already makes it harder to import third-party components and 
attract new developers?


Let's face it, we already make our incredible job of writing a 
Windows-compatible operating system even harder than Microsoft's - by 
supporting both GCC and MSVC. We spend enormous amounts of time to 
just get the basics right for both toolchains, and still fail at 
things like the C++ standard library. Ditching MSVC 2010 finally paves 
the way for importing a modern and trusted third-party C++ library 
like Clang's libc++ to replace our hacked and unmaintained stlport. 
Going even further, we could finally draw from the huge pool of 
talented C++ developers, who leverage the benefits of C++11 and 
beyond. Think about that next time you debug a memory leak or a 
deadlock that would have been impossible through std::unique_ptr or 
std::mutex.


This project won't ever become usable in a lifetime if we don't go 
with the time but stick to old habits forever. There is no inherent 
value in supporting old compilers, just wasted developer time.
And don't tell me about self-hosting: It's not like anybody 
productively uses ReactOS for building ReactOS right now. If you just 
want to demonstrate that, use the RosBE GCC-based toolchain. I already 
spent hours on backporting that back to ReactOS/Windows XP...



Now I usually would have put that on the agenda for the meeting and 
asked for a vote.
But as this year's ditching of MSVC 2010 is just the implementation of 
a meeting decision from 2 years ago 
(https://reactos.org/project-news/december-2018-meeting-minutes/), 
meeting votes are apparently not considered binding here. Neither is 
apparently the discussion we had in the related PR 
https://github.com/reactos/reactos/pull/2658.



So let's have an open discussion and voting process right here on the 
mailing list for everyone to see, to decide this once and for all!
Just reply to this mail, tell about your reasons - and more 
importantly tell whether you support or reject dropping MSVC 2010 
support.


Votes by CORE REACTOS MEMBERS are then counted on 1ST JANUARY 2021.


At this point, it should be obvious that I myself SUPPORT the decision 
to ditch building ReactOS with MSVC 2010.



Cheers,

Colin


___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Not available for Status Meeting (August 2020)

[Mark Jansen]

Hey,

The 27th I won't be able to attend either, so re-scheduling it works for 
me :)


Regards,

Mark

On 14-Aug-20 17:24, Colin Finck wrote:

Hi all!

Keeping the usual schedule, our next bi-monthly status meeting would be
on 27th August.
Due to vacation, I won't be available on that date though and therefore
cannot serve as the meeting moderator.

If you want the meeting to take place on the usual date, please find
another moderator.
Otherwise, we have to postpone it I guess.

Suggestions are welcome! :)


Cheers,

Colin


___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] FOSDEM 2020

[Mark Jansen]

Hey,

I should be available this weekend.

Regards,

Mark

On 23-11-2019 22:12, Colin Finck wrote:

Hi all!

It took a while but FOSDEM has finally put a list of accepted stands on
their website: https://fosdem.org/2020/news/2019-11-19-accepted-stands/

Looks like we only got a stand on Sunday this year, with our friends
from Haiku OS having one on Saturday only. Not really what I thought
when signing up for a "shared booth as always", but I'm sure we're going
to manage that.

There are plenty of opportunities for us to fill an entire weekend in
Brussels, including

* Having a "mini Hackfest" on Saturday in a coworking space in Brussels
(or alternatively at FOSDEM itself, but it's going to be crowded there)

* Following up on what Victor and me discussed with the FreeBSD, Haiku,
NetBSD, and RTEMS people at GSoC Mentor Summit regarding a port of the
low-level FreeBSD kernel interfaces to ReactOS, making a vast amount of
network and storage drivers available to us.
As far as I recall, the FreeBSD people have a conference in Brussels
just before FOSDEM and are inviting us to join (Mahdi - correct me if
I'm wrong).

* Asking the Haiku guys if we shall try to join their booth on Saturday
while they join ours on Sunday (Adrien? François?)

But first I'd like to know who else is definitely going to make it to
Brussels. Please reply to my mail ASAP, then we can have a short meeting
on Mattermost soon and come to a decision.


Cheers,

Colin


___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Gsoc 19

[Mark Jansen]

Hello,

Thanks for your interest in ReactOS!

Please note that it is not announced yet which organizations are 
selected for participation (See https://summerofcode.withgoogle.com/ )


Also please take a look at our wiki page, where it is explained that we 
expect a small contribution before we can accept any application: 
https://reactos.org/wiki/Google_Summer_of_Code_2019#Make_a_small_contribution


Our current infrastructure is built using php, (with some bits of python 
and Twistd forbuildbot).
It would make sense to make yourself familiar with testman ( 
https://reactos.org/testman/ , 
https://github.com/reactos/web/tree/master/www/www.reactos.org/testman )


Regards,

Mark Jansen.

On 11-2-2019 13:40, Ayush Sinha wrote:


Hey there !

I am really interested to work with your organization.I am interested 
in Web development projects, Went through the reactOS GSOC’19 page. I 
am interested in making the web interface for reactos which can show 
all GitHub reactos repos, commits, etc using the GitHub API. 
(https://www.reactos.org/wiki/Google_Summer_of_Code_2019_Ideas#Developer_Web_Interface)


Looking forward to work on the same idea for GSOC’19 under your 
mentorship.


Currently I am reading the api documentation and trying to implement 
some basic stuffs using nodeJS, till now I have created a web app that 
can list all reactOs repositories and related information.


Webapp link: https://github-userinterface.herokuapp.com/ 
<https://github-userinterface.herokuapp.com/>


GitHub repo: 
https://github.com/ayushsnha/UserInterface-with-Github-RESTapiV3


kindly review the link. All suggestions are welcomed

Thanks

Ayush Kumar Sinha

2^nd year bachelor of cs,

VIT University,

India


___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Google Summer of Code 2019

[Mark Jansen]

Something like kiwiirc.com should work.



On 29-11-2018 18:17, Javier Agustìn Fernàndez Arroyo wrote:
Please, remind me how can I connect to the meeting via web  I'm at 
work and I can't use IRC clients here


Thanks

El jue., 29 nov. 2018 17:51, > escribió:


Hi,

sadly I can't mentor it, but getting the demo Laptop (the Dell D531)
finally completely running would be _very_ helpfull. I think
getting the
GPU completely running will be a could candidate for GSoC (The
drivers
are already working in a very rough shape). To my last
information, the
driver is blocked by an PnP issue
(https://jira.reactos.org/browse/CORE-14464) .

There are rather many bug reports of graphic driver problems, so the
GSoC project could be extended in any way - be it more ATI GPU,
trying
AMD (thus newer) GPUs, or give Intel drivers a try to get the vast
majority working. NVivida could be worth a try as well.

Best regards,
Michael Fritscher

P.S. Or should I try to add it to the wiki even despite the fact I
will
not be able to mentor it (because of lack of knowledge) ?

P.P.S. Another idea could be a OS AC97/HDA audio driver or network
drivers for broadcom/intel/realtek (the latest still existing in a
way).

Am 2018-11-29 11:01, schrieb Colin Finck:
> Hi all!
>
> While there is still some time until the February 6, 2019
application
> deadline for projects, we should already begin planning our GSoC
> participation now!
>
> As today's meeting already has a long agenda, I delibereately
didn't
> add
> GSoC to it. But I've already created
> https://reactos.org/wiki/Google_Summer_of_Code_2019 and
> https://reactos.org/wiki/Google_Summer_of_Code_2019_Ideas
>
> Please decide whether you want to be a GSoC org admin or mentor
and add
> your ideas to the list or remove deprecated ones.
> My experience from the Mentor Summit tells me that proper
planning and
> advertising can make a huge difference for our 2019
participation and
> will certainly get us more students :)
>
>
> Cheers,
>
> Colin
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org 
> http://reactos.org/mailman/listinfo/ros-dev

___
Ros-dev mailing list
Ros-dev@reactos.org 
http://reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Status Meeting (November 2018)

[Mark Jansen]

We can discuss this if you are present, but I don't see the value in discussing it without you.We have seen before that something discussed without the initiator being present is time not well spent, since it is a bit hard to argue with only one side of the argument presentOp 26 nov. 2018 12:15 schreef hermes.belu...@sfr.fr:Hello,

I may not be available as it's the day when I'm going somewhere for a conference; it just depends at which time I arrive at destination.

For the meeting we may talk about the best way we can move to delivering all-in-one ReactOS ISOs (containing livecd + installation in both text and GUI modes), and which changes this could imply for our infrastructure (buildbots/website...).

Best regards,
Hermes
De : "Javier Agustìn Fernàndez Arroyo"
A : "ReactOS Development List"
Envoyé: samedi 24 novembre 2018 22:06
Objet : Re: [ros-dev] Status Meeting (November 2018)
 

I'm at work but I will do my best to attend!
 


El sáb., 24 nov. 2018 21:38, Colin Finck  escribió:

Hi all!

Let me invite you to the November 2018 meeting, taking place next
Thursday, November 29, 2018 at 19:00 UTC.
Invited members will again receive their credentials shortly before the
meeting.

This will be the first meeting since August and I hope we get some more
topics than just the obligatory Status Reports. Please send your
proposals by replying to this mail.


Best regards,

Colin

___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev




___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev

 

___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Upcoming Google Summer of Code Mentor Summit

[Mark Jansen]

Hey,Seeing how other projects curate a list of ideas might be interesting indeed.I would also be interested how they determine if someone is a suitable mentor, since this was a problem for us this year.Regards,___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Broken booting since commit ae11022712db7a5a1e818e33a5f4052eac7e8e3c

[Mark Jansen]

Check out sdk/tools/gen_baseaddress.pyBasically, create the build you want to fix (msvc, gcc with or without dwarf)Run this script with the build output folder as command line argument, and it will give you data to paste into the baseaddress.cmakeRegards,MarkOp 30 aug. 2018 00:55 schreef "David Quintana (gigaherz)" :I believe from the testbot log, that my commit made some DLLs grow out of their assigned memory allocation, but I don't know how to update the dll address mappings. Help appreciated.
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Test_VBox finally fixed - but a flawed test remains

[Mark Jansen]

Hey,

We could have rosautotest move the cursor to somewhere in the upper 
right before starting any test?


Regards,


On 27-8-2018 11:34, Colin Finck wrote:

Hi all,

I took some time during Hackfest to upgrade our Test_VBox Testbot to
Ubuntu 18.04, which finally brings us VirtualBox 5.2.x support for
sysreg2. Pierre also worked on the relevant BuildBot scripts to improve
their reliability.

This has resulted in
https://github.com/reactos/buildbot_config/commit/388a831eb5ccf67535d8cbd6df2cc927fb9af5a9
and since using that script, the infamous "IVirtualBox object is null"
bug hasn't occurred again :)
The upgrade from VirtualBox 4.3.40 to 5.2.10 also resulted in unbearably
slow serial port output at first, but this could be fixed by
https://github.com/reactos/sysreg2/commit/a4eb4a4551618b4af4dc1985ad8c55fe0b3a57b2.
Have a look at this commit if you encounter a slow serial port output in
one of the latest VirtualBox versions with either operating system.

This only leaves a funnily flawed WINE test left, which currently causes
the entire regression testing process to come to a standstill:
https://jira.reactos.org/browse/CORE-14975


Cheers,

Colin



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS Software installer ignores proxy settings

[Mark Jansen]

Hey,

If you are talking about 'Rapps', currently we only have an issue in our 
issue tracker that it crashes with a proxy:

https://jira.reactos.org/browse/CORE-12219

If you observed different behavior, would you mind filing a new issue 
with the exact settings used?


Regards,

Mark.


On 23-7-2018 16:17, Thomas Schweikle wrote:

ReactOS Software installer ignores proxy settings. If you are behind
some firewall allowing internet connections only by proxy, you are
lost. The software installer ignores any proxy setting.




___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Website migrated to a new Login system

[Mark Jansen]

Thanks for the upgrade Colin!


On 4-7-2018 15:44, Colin Finck wrote:

Hello all,

Our website has been migrated to a new Login system today and all
components have been upgraded to their latest versions.
In the course of that, the user database has also been moved into an
LDAP directory and cleaned from accounts that have never been used.

Please check that everything is working alright and report bugs in our
JIRA: https://jira.reactos.org
You are also advised to change your password in the self-service at
https://reactos.org/roslogin/?p=selfservice - even to the same one.
Every password change from now on will use a state-of-the-art hashing
algorithm (salted SHA-512 with 6000 rounds) to protect your account from
credential theft.

Unfortunately, there have been several newer accounts, for which the
password could not be migrated.
If you encounter problems logging in, please reset your account password
at https://reactos.org/roslogin/?p=forgot to regain access.

Best regards,

Colin Finck



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Status Meeting (June 2018)

[Mark Jansen]

I use CloudIRC, but that requires an account.


On 28-6-2018 18:48, David Quintana (gigaherz) wrote:

AndChat worked well last time I used it.

On Thu, 28 Jun 2018, 18:37 Javier Agustìn Fernàndez Arroyo, 
mailto:elh...@gmail.com>> wrote:


Err... Do you know any Android irc client?

El jue., 28 jun. 2018 18:32, Colin Finck mailto:co...@reactos.org>> escribió:

Credentials have been sent, please check your inboxes!

Colin


Am 24.06.2018 um 10:59 schrieb Colin Finck:
> Hi all!
>
> Let me invite you to the June 2018 meeting, taking place
this Thursday,
> June 28, 2018 at 19:00 UTC.
> Invited members will again receive their credentials shortly
before the
> meeting.
>
> The current agenda is:
>
>    1. Status Reports
>    2. ReactOS Hackfest on August 16 - 21
>    3. 0.4.9 release on July 14
>
> I'm open for additional proposals.
>
> Best regards,
>
> Colin
>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org 
> http://www.reactos.org/mailman/listinfo/ros-dev
>

___
Ros-dev mailing list
Ros-dev@reactos.org 
http://www.reactos.org/mailman/listinfo/ros-dev

___
Ros-dev mailing list
Ros-dev@reactos.org 
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS mirror repo detected on GitLab

[Mark Jansen]

Well, I have not heard of anyone working on this,
and considering noone replied I would say it's not official.


On 8-6-2018 16:55, Stas'M wrote:

I've found this mirror repo on GitLab, it was created today:
https://gitlab.com/reactos/reactos

Does it belong to the ReactOS team? If not, we may have problems.


Regards,
Stas'M
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] RFC: Change Rapps 'Size' field

[Mark Jansen]

Hello,

I'd like to propose a change for the 'Size' field:
Currently this is a localized, pre-formatted field.
By changing this to the actual size in bytes:
- We can use StrFormatByteSizeW to format it locale dependent (without 
the need to manually translate it)
- We can use this value to display the progress bar, in case the 
download itself does not provide this value (for example, web.archive 
does not provide this).


For backwards compatibility we should probably add this as another 
field, so that the 'old' rapps can still read the 'Size' field.


Regards,

Mark


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Making bluescreens more useful

[Mark Jansen]

Let's just start with the basic idea, a bsod with a stacktrace.
Then, we can add onto that, maybe a qr code, or translate the addresses 
etc..



On 13-1-2018 12:24, Hermès BÉLUSCA - MAÏTO wrote:


I suppose the idea of putting an idiotic smiley was the "idea" of an 
intern ^^


Also our qr code would be actually useful, instead of the hardcoded 
ones win10 seems to display (as it looks the idea of thomas would 
include the backtrace in it).


H.





De : David Quintana (gigaherz)
Date : 13 janvier 2018 11h17
À : ros-dev@reactos.org
Cc :
Objet : Re: [ros-dev] Making bluescreens more useful

Whatever we do, DO NOT put a smiley in it. It feels like an insult.

On 13 January 2018 at 10:36, Ged Murphy > wrote:


You’ve been looking at too many Win10 blue screens

*From:*Ros-dev [mailto:ros-dev-boun...@reactos.org
] *On Behalf Of *Timo Kreuzer
*Sent:* 12 January 2018 20:23
*To:* ros-dev@reactos.org 
*Subject:* Re: [ros-dev] Making bluescreens more useful


I like it. I recently thought about another possibility to make
the BSOD more useful: A QR code.
A QR code can contain up to almost 3 KB of arbitrary data or 4 KB
text.

Here's a quick example (1425 characters)
Try it out, use your phone and scan it :)





Am 11.01.2018 um 00:48 schrieb Thomas Faber:

We often get bug reports with just a screenshot of a bluescreen; we then

go ahead and tell people that bluescreens are basically useless, they

should get a debug log and a backtrace, and also remember to tell us

what version they're using.

  


Since there's actually no reason why bluescreens need to be useless, I

thought I'd try to change that.

I've attached an example. The source for this quick PoC can be found at


https://github.com/ThFabba/reactos/commit/6a9f172b76bd11f763598c16e5d47299eec1971c



  


Thoughts?




___

Ros-dev mailing list

Ros-dev@reactos.org 

http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org 
http://www.reactos.org/mailman/listinfo/ros-dev






___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] JIRA up again - Do we still need FishEye?

[Mark Jansen]

Hey,

Well as far as I know, the only use we had for FishEye were code reviews 
and smart commits,
and since we can now do CR's on github, the only use FishEye has is 
integration with jira. (close issues, bind commits to jira issues).
If there is another way of getting functionality like that, I think we 
should go for it.


Regards,


On 14-10-2017 17:38, Colin Finck wrote:

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

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Git Migration: The documentation, rossubsys and wallpapers directories

[Mark Jansen]

How about having a separate repository for wallpapers,
and in 'master' or whatever only have the 'last release' wallpaper +
one or 2 alternatives?

The wallpaper repo can then have a structure where there is a folder
per release,
and an additional folder for potential candidates for next releases.

On 8 September 2017 at 16:47, Colin Finck  wrote:
> Am 08.09.2017 um 14:34 schrieb Hermès BÉLUSCA-MAÏTO:> It seems that both
> these links :
> https://stackoverflow.com/questions/3946538/git-clone-just-the-files-please
> , and
> https://stackoverflow.com/questions/120/using-git-to-get-just-the-latest-revision
>>
>> give a clue on how to just download the files without the history... >
>
>> [...]
>>
>>>
>>> The builder(s) can have a "working" directory, in which they check-out
>>> the
>>> different "projects" they need for the build: reactos source can be DL'ed
>>> into
>>> "working/reactos.git" ; the wallpapers, rostests etc... can be DL'ed into
>>> "working/rostests" and "working/wallpapers", then symlinks (OK on *nix &
>>> windows) into the "working/reactos.git/modules" can be created that point
>>> to "working/wallpapers" and "working/rostests" , and then we build as
>>> usual
>>> ?
>
>
> Both of your ideas destroy the automatic relationship of a specific revision
> of "reactos" with a specific revision of the modules.
>
> We don't want to start telling people to use that particular version of
> "reactos" with that particular version of "rostests". It gets even worse if
> you want to hack on both in a branch..
> So matching versions must always stay together, and this is why I want to
> keep them in a single repository, only enabled/disabled by a CMake variable.
>
> Of course, the logical next step would be overhauling our tree layout.
> But first things first ;)
>
>
 * 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.

>>> As long as they can be found easily in the history, then ok.
>
>
> As with every Version Control System, the difficulty of finding deleted
> files in history boils down to the creativity of your used GUI :)
>
> Shortcut for you to find related commits:
>   git log --name-only | grep -C 5 rossubsys
>
>
> I have updated my conversion scripts and rules at
> https://github.com/ColinFinck/reactos-git-conversion-scripts to split off
> "documentation" into its own repository.
> Also they now perform the "reactos" directory reorganization and add the
> "0.4.7-dev" tag for git describe.
>
>
> Cheers,
>
> Colin
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Licensing - Make ReactOS conform again!

[Mark Jansen]

No objections here!

On 18 August 2017 at 01:53, Colin Finck  wrote:
> 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/Licensing.pdf
> 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
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Enabling themes in 3rd stage

[Mark Jansen]

I like this theme!

Op 31 jul. 2017 16:44 schreef "Ged Murphy" :

> A link to the theme I mentioned would probably help...
> http://aportz19.deviantart.com/art/Basic-Lite-and-Basic-
> 8-Visual-Style-for-Windows-XP-393826050
>
>
> -Original Message-
> From: Ged Murphy [mailto:gedmurphy.mailli...@gmail.com]
> Sent: 31 July 2017 15:43
> To: 'ReactOS Development List' 
> Subject: RE: [ros-dev] Enabling themes in 3rd stage
>
> Do you have some pics??
>
> I've always been a big fan of seeing the Basic Lite theme being on by
> default, which would give ros a much more modern look and feel.
> We're missing the start menu implementation for this though.
>
>
>
> -Original Message-
> From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Giannis
> Adamopoulos
> Sent: 31 July 2017 15:29
> To: ros-dev@reactos.org
> Subject: [ros-dev] Enabling themes in 3rd stage
>
> 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
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Enabling themes in 3rd stage

[Mark Jansen]

It would be nice to enable it by default,
But give 2nd stage and unattended an option to disable it

Op 31 jul. 2017 16:57 schreef "Giannis Adamopoulos" <
giannis.adamopou...@reactos.org>:

> Lautus: http://i.imgur.com/lqrqvtu.png
> Basic lite (without any font changes): http://i.imgur.com/BcTIF9m.png
>
> To make basic lite look better needs to substitute its fonts with some we
> already have.
>
>
> Ged Murphy  wrote on Mon, July 31st, 2017,
> 4:44 PM:
> > A link to the theme I mentioned would probably help...
> > http://aportz19.deviantart.com/art/Basic-Lite-and-Basic-
> 8-Visual-Style-for-Windows-XP-393826050
> >
> >
> > -Original Message-
> > From: Ged Murphy [mailto:gedmurphy.mailli...@gmail.com]
> > Sent: 31 July 2017 15:43
> > To: 'ReactOS Development List' 
> > Subject: RE: [ros-dev] Enabling themes in 3rd stage
> >
> > Do you have some pics??
> >
> > I've always been a big fan of seeing the Basic Lite theme being on by
> default, which would give ros a much more modern look and feel.
> > We're missing the start menu implementation for this though.
> >
> >
> >
> > -Original Message-
> > From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Giannis
> Adamopoulos
> > Sent: 31 July 2017 15:29
> > To: ros-dev@reactos.org
> > Subject: [ros-dev] Enabling themes in 3rd stage
> >
> > 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
> >
> > ___
> > Ros-dev mailing list
> > Ros-dev@reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >
> >
> > ___
> > Ros-dev mailing list
> > Ros-dev@reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS Hackfest 2017 - Are you in?

[Mark Jansen]

Hello,

I would like to attend!

Regards,

Mark

On 21 June 2017 at 23:09, Eric Kohl  wrote:
> Hi Colin,
>
> I would like to attend the Hackfest 2017! But I will have to find a
> stand-in before I can make a final decision.
>
> Regards,
> Eric
>
>
> Am 21.06.2017 12:04, schrieb Colin Finck:
>> Hi all!
>>
>> I'm currently planning the ReactOS Hackfest 2017 in the Cologne/Bonn
>> area in Germany. Currently, the plan is to book a meeting room from
>> Monday, August 14 to Friday, August 18. We can then use the weekend
>> before to get to Cologne and explore the city a bit. After the Hackfest,
>> everybody interested can join us at FrOSCon in Bonn the weekend after.
>>
>> As booking a room there involves significant costs, I'd like to know who
>> of you can definitely make it for the Hackfest and who of you is
>> definitely out.
>>
>> Please reply now to prevent me from bugging you on IRC all the time! ;)
>>
>>
>> Cheers,
>>
>> Colin
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [mjansen] 74693: [KERNEL32] Initial implementation for BaseCheckRunApp, calling into apphelp to check for compatibility fixes CORE-10368

[Mark Jansen]

Feel free to revert it,
I cannot look at this until at least tomorrow evening.

On 29 May 2017 at 12:06, Thomas Faber  wrote:
> Testbots seem to dislike this commit, looks like 3rd stage boot is
> broken in some way. :(
>
>
>
> On 2017-05-28 21:27, mjan...@svn.reactos.org wrote:
>>
>> Author: mjansen
>> Date: Sun May 28 19:27:51 2017
>> New Revision: 74693
>>
>> URL: http://svn.reactos.org/svn/reactos?rev=74693=rev
>> Log:
>> [KERNEL32] Initial implementation for BaseCheckRunApp, calling into
>> apphelp to check for compatibility fixes CORE-10368
>>
>> Modified:
>>  trunk/reactos/dll/win32/kernel32/client/appcache.c
>>  trunk/reactos/dll/win32/kernel32/client/utils.c
>>
>> Modified: trunk/reactos/dll/win32/kernel32/client/appcache.c
>> URL:
>> http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/appcache.c?rev=74693=74692=74693=diff
>>
>> ==
>> --- trunk/reactos/dll/win32/kernel32/client/appcache.c  [iso-8859-1]
>> (original)
>> +++ trunk/reactos/dll/win32/kernel32/client/appcache.c  [iso-8859-1] Sun
>> May 28 19:27:51 2017
>> @@ -16,7 +16,20 @@
>>   /* GLOBALS
>> /
>> ULONG g_ShimsEnabled;
>> -
>> +static BOOL g_ApphelpInitialized = FALSE;
>> +static PVOID g_pApphelpCheckRunAppEx;
>> +static PVOID g_pSdbPackAppCompatData;
>> +
>> +typedef BOOL (WINAPI *tApphelpCheckRunAppEx)(HANDLE FileHandle, PVOID
>> Unk1, PVOID Unk2, PWCHAR ApplicationName, PVOID Environment, USHORT ExeType,
>> PULONG Reason,
>> + PVOID*
>> SdbQueryAppCompatData, PULONG SdbQueryAppCompatDataSize, PVOID* SxsData,
>> PULONG SxsDataSize,
>> + PULONG FusionFlags, PULONG64
>> SomeFlag1, PULONG SomeFlag2);
>> +typedef BOOL (WINAPI *tSdbPackAppCompatData)(PVOID hsdb, PVOID
>> pQueryResult, PVOID* ppData, DWORD *dwSize);
>> +
>> +#define APPHELP_VALID_RESULT0x1
>> +#define APPHELP_RESULT_NOTFOUND 0x2
>> +#define APPHELP_RESULT_FOUND0x4
>> +
>> +
>>   /* FUNCTIONS
>> **/
>> BOOLEAN
>> @@ -136,7 +149,120 @@
>>   DPRINT("BaseCheckAppcompatCache is UNIMPLEMENTED\n");
>> if (Reason) *Reason = 0;
>> -return TRUE;
>> +
>> +// We don't know this app.
>> +return FALSE;
>> +}
>> +
>> +static
>> +VOID
>> +BaseInitApphelp(VOID)
>> +{
>> +WCHAR Buffer[MAX_PATH*2];
>> +UNICODE_STRING DllPath = {0};
>> +PVOID ApphelpAddress;
>> +PVOID pApphelpCheckRunAppEx = NULL, pSdbPackAppCompatData = NULL;
>> +
>> +RtlInitEmptyUnicodeString(, Buffer, sizeof(Buffer));
>> +RtlCopyUnicodeString(, );
>> +RtlAppendUnicodeToString(, L"\\system32\\apphelp.dll");
>> +
>> +if (NT_SUCCESS(LdrLoadDll(NULL, NULL, , )))
>> +{
>> +ANSI_STRING ProcName;
>> +
>> +RtlInitAnsiString(, "ApphelpCheckRunAppEx");
>> +if (!NT_SUCCESS(LdrGetProcedureAddress(ApphelpAddress, ,
>> 0, )))
>> +pApphelpCheckRunAppEx = NULL;
>> +
>> +RtlInitAnsiString(, "SdbPackAppCompatData");
>> +if (!NT_SUCCESS(LdrGetProcedureAddress(ApphelpAddress, ,
>> 0, )))
>> +pSdbPackAppCompatData = NULL;
>> +}
>> +
>> +if (InterlockedCompareExchangePointer(_pApphelpCheckRunAppEx,
>> RtlEncodeSystemPointer(pApphelpCheckRunAppEx), NULL) == NULL)
>> +{
>> +g_pSdbPackAppCompatData =
>> RtlEncodeSystemPointer(pSdbPackAppCompatData);
>> +}
>> +}
>> +
>> +/*
>> + *
>> + */
>> +BOOL
>> +WINAPI
>> +BaseCheckRunApp(IN HANDLE FileHandle,
>> + IN PWCHAR ApplicationName,
>> + IN PWCHAR Environment,
>> + IN USHORT ExeType,
>> + IN PULONG pReason,
>> + IN PVOID* SdbQueryAppCompatData,
>> + IN PULONG SdbQueryAppCompatDataSize,
>> + IN PVOID* SxsData,
>> + IN PULONG SxsDataSize,
>> + OUT PULONG FusionFlags)
>> +{
>> +ULONG Reason = 0;
>> +ULONG64 Flags1 = 0;
>> +ULONG Flags2 = 0;
>> +BOOL Continue, NeedCleanup = FALSE;
>> +tApphelpCheckRunAppEx pApphelpCheckRunAppEx;
>> +tSdbPackAppCompatData pSdbPackAppCompatData;
>> +PVOID QueryResult = NULL;
>> +ULONG QueryResultSize = 0;
>> +
>> +if (!g_ApphelpInitialized)
>> +{
>> +BaseInitApphelp();
>> +g_ApphelpInitialized = TRUE;
>> +}
>> +
>> +pApphelpCheckRunAppEx =
>> RtlDecodeSystemPointer(g_pApphelpCheckRunAppEx);
>> +pSdbPackAppCompatData =
>> RtlDecodeSystemPointer(g_pSdbPackAppCompatData);
>> +
>> +if (!pApphelpCheckRunAppEx || !pSdbPackAppCompatData)
>> +return TRUE;
>> +
>> +if (pReason)
>> +Reason = *pReason;
>> +
>> +Continue = pApphelpCheckRunAppEx(FileHandle, NULL, NULL,
>> ApplicationName, Environment, ExeType, ,
>> +   

Re: [ros-dev] Status Meeting - rescheduled

[Mark Jansen]

I could not attend this week,
so a reschedule is convenient :)

On 24 May 2017 at 11:48, David Quintana (gigaherz)  wrote:
> Works for me.
>
> On 24 May 2017 at 11:38, Aleksey Bragin  wrote:
>>
>> Hello,
>>
>> I propose to reschedule our monthly meeting to Thursday next week (1st of
>> June), as tomorrow is a holiday in some countries, and also I have tight
>> meetings schedule this week.
>>
>> Regards,
>> Aleksey Bragin
>>
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] retiring 'shellext/slayer'

[Mark Jansen]

The shell extension 'slayer' will soon be removed.
It has been surpassed by the shell extension 'acppage'.

Since neither of the modules is yet active, this should not pose a problem.

Related issues:
CORE-10375 and CORE-13111

Regards,

Mark.

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Vgal USB patches

[Mark Jansen]

What kind of problems with github?
For his build problem: try completely deleting everything from that
build dir, and re-generating build files.

Regards,

Mark

On 4 April 2017 at 12:17, Alexander Rechitskiy  wrote:
> Vgal told me that he still has major problems with github. So code  review
> at code.reactos.org is the only option. Also he is a bit tired with his
> local test builds and thinks that inclusion into trunk will speed up his
> developments
>
> And one more problem that he faced. He could not build proper VC bulds after
> new ISO format was adopted.
> https://pastebin.com/AtUqfGf9
>
> 04.04.2017, 02:41, "Hermès BÉLUSCA-MAÏTO" :
>
> Hi !
>
> A proper code review may be in order, where/how can we do that?
>
>
>
> Regards,
>
> Hermès BÉLUSCA - MAÏTO
>
>
>
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Alexander
> Rechitskiy
> Envoyé : mardi 4 avril 2017 01:18
> À : ReactOS Development List
> Objet : [ros-dev] Vgal USB patches
>
>
>
> Hello all!
>
>
>
> Vgal showed significant progress in his USB patches. With his test images
> almost every sungle  usb keyboard and mouse works. We (russian community)
> have reached the top corner of our testing capabilities and we could not
> find any new bugs in his work anymore. So Vgal usb patches are now in very
> mature state.
>
>
>
> Now we probably need to make the next step and put all his work or parts of
> it into trunk. But before  this Vgal said that it is important to test his
> drivers against Windows 2003 server to be sure in compatibilty. And this
> where russian community can not provide enough help with . I know that many
> developers are familiar with this procedure. So probably it is your turn
> now.
>
>
>
> We need this patches in trunk in order to make our next release great again!
> And we have not so many but still enough time to finish this effort.
>
>
>
>
>
> P.S. Here is the link to legal VHD-image of Microsoft Windows Server 2003 R2
> Enterprise Edition for test purposes
>
> https://www.microsoft.com/en-us/download/details.aspx?id=19727
>
> --
> Best regards,
>
> Alexander Rechitskiy
>
> ,
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
> --
> Best regards,
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Opening up #reactos-dev to the public

[Mark Jansen]

In that case I can stop paying attention to jira, since the perception
is that we do not care anyway.
This will free up a reasonable amount of time that I can spend on
parts of reactos that only i care about.

On 25 March 2017 at 14:01, Alexander Rechitskiy <art1st...@yandex.ru> wrote:
>
>
> “Talk is cheap. Show me the code.” ― Linus Torvalds
>
>
>
>
> Speed of development of ReactOS is really slow. Developers do not care even
> about reports in JIRA. This discussion is sensles and useless because
> regardless of the it's result nothing will be better in ReactOS.
>
>
>
>
> 25.03.2017, 15:52, "Robert Naumann" <gonzo...@gmail.com>:
>
> There should simply be more devs in #reactos. Some are, but many are not.
> Everyone of us is able to give voice to newbies and direct dev related
> conversations to the dev channel. When we open this chan to the public we
> could instead remove it and do everything via #reactos.
>
> Am 25.03.2017 13:33 schrieb "David Quintana (gigaherz)"
> <gigah...@gmail.com>:
>
> I don't see any usefulness in a #reactos-gsoc. It would isolate the gsoc
> people, rather than help them integrate into the team. Remember Google isn't
> just giving projects some free labor, the goal is to introduce new devs into
> the communities with the idea of them remaining in those communities. So
> being in the main channels should be part of the goal of gsoc.
>
> On 25 March 2017 at 08:53, Michael Fritscher <mich...@fritscher.net> wrote:
>
> Too many chans will clutter it, in the end the devs will have to join 10
> chans. The chans aren't that high-traffic ones.
>
> I think we should yust try to do a -m and see what happens.
>
>> Yes, that's a better idea. #reactos-gsoc
>>
>> On Fri, Mar 24, 2017 at 6:53 PM, Alex Ionescu <ion...@videotron.ca> wrote:
>>
>>> I don't agree. Maintain the auto-voice lists and get someone in charge
>>> of
>>> operations, like I used to be for many years on IRC.
>>>
>>> Instead, why not create a #reactos-gsoc or something?
>>>
>>> Best regards,
>>> Alex Ionescu
>>>
>>> On Fri, Mar 24, 2017 at 11:19 AM, Mark Jansen <learn0more+...@gmail.com>
>>> wrote:
>>>
>>>> We can always try it out?
>>>> If it doesnt work, restoring it is a simple as setting a flag on the
>>>> channel.
>>>>
>>>> On 24 March 2017 at 16:31, David Quintana (gigaherz)
>>>> <gigah...@gmail.com>
>>>> wrote:
>>>> > I disagree -- if we can be firm about the channel being only for
>>>> development
>>>> > talk, things should remain mostly as they are now.
>>>> >
>>>> > In any community, there's inevitably going to be idle talk, offtopic
>>>> > conversations, etc. If you only have ONE place to talk in, all those
>>>> thigns
>>>> > are going to be mixed in with actual dev talk, but if you have clear
>>>> rooms
>>>> > set for each thing, the majority of people will be happy to leave all
>>>> the
>>>> > offtopic talk to the main channel, and dev talk to the dev channel.
>>>> >
>>>> > It works for plenty other projects and communities so there's no
>>>> reason
>>>> to
>>>> > be pessimistic and think that "our idiots are worse". It's simply not
>>>> true.
>>>> >
>>>> > I vote for trying, and we can always put back the +m if things get
>>>> out
>>>> of
>>>> > hand.
>>>> >
>>>> > On 24 March 2017 at 16:13, Hermès BÉLUSCA-MAà TO
>>>> <hermes.belu...@sfr.fr>
>>>> > wrote:
>>>> >>
>>>> >> I don’t approve the idea. The fact is that if the devs quit
>>>> originally
>>>> >> #reactos, it’s because it was generally too noisy, etc… . If we
>>>> remove
>>>> the
>>>> >> moderation irc bit in #reactos-dev, you may expect the same
>>>> phenomenon
>>>> to
>>>> >> occur in #reactos-dev too.
>>>> >>
>>>> >>
>>>> >>
>>>> >> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de
>>>> David
>>>> >> Quintana (gigaherz)
>>>> >> Envoyé : vendredi 24 mars 2017 11:35
>>>> >> À : ReactOS Development List
>>>> >> Objet : Re: [ros-dev] Opening up #reactos-dev to the 

Re: [ros-dev] [ros-diffs] [khornicek] 74209: [RAPPS] - Add a custom build of the Mesa 3D Graphics Library. This build contains mesa, gallium and llvmpipe. It provides an enormous performance boost ove

[Mark Jansen]

How about doing the same as with gecko?
Provide the user with a question (or a list of optional components)
that he can install.

On 21 March 2017 at 10:40, Kamil Hornicek  wrote:
> Basically this. I'll only add few other points:
>
> - Mesa sources is 5k files, llvm is 15k, so we have 20k files we'd have to
> add to trunk.
> - We had Mesa in our tree once and I only managed to update it once or twice
> during the nine(?) years I'm with the project, because it's *HUGE* and it
> requires a siginificant effort to pull it off.
> - If you're still not convinced you can try updating the Mesa code we
> currently have in opengl32 and that's just a tiny chunk of the Mesa
> codebase.
>
> Having Mesa in our tree would actually make it much harder to update it,
> believe me I've been there.
>
> Also this is just a temporary solution until we fully support graphics cards
> drivers. Any more time spent on this would be wasted.
>
> Let's not discuss adding Mesa to the tree, let's instead come up with a
> solution for providing the user with some "essential/optional" binaries
> during or after the setup process.
>
> K.
>
>
> Dne 21.3.2017 1:48, Zachary Gorden napsal(a):
>>
>> Mesa is really not a good example of something that should be added to
>> the ROS tree due to desired functionality. Its src is almost 5K files by
>> itself, when trunk is only a little under 20K files. Then there's its
>> rather esoteric build setup. I'm mildly curious as to whether Kamil
>> actually built it on Windows or if he needed to pull off a
>> cross-compilation on Linux instead. Getting RosBE to be able to build
>> Mesa is a nontrivial exercise. To try to incorporate Mesa is to take on
>> a large engineering task for what is not necessarily a big payoff. We
>> have an existing opengl implementation. Its performance sucks, sure, but
>> if you wanted actually performant 3D graphics you would need to go and
>> install a proper graphics driver anyway. For out of the box, all it
>> needs to do is provide a sufficient degree of compatibility.
>>
>> SVN also has the equivalent of modules, externals. The project just
>> never bothered setting up the repo to make use of them.
>>
>> On Mon, Mar 20, 2017 at 6:51 PM, Hermès BÉLUSCA-MAÏTO
>> > wrote:
>>
>> And another reason to make our SVN source tree structure modularized.
>>
>> -Message d'origine-
>> De : Ros-dev [mailto:ros-dev-boun...@reactos.org
>> ] De la part de Colin Finck
>> Envoyé : lundi 20 mars 2017 23:05
>> À : ros-dev@reactos.org 
>>
>> Objet : Re: [ros-dev] [ros-diffs] [khornicek] 74209: [RAPPS] - Add a
>> custom build of the Mesa 3D Graphics Library. This build contains
>> mesa, gallium and llvmpipe. It provides an enormous performance
>> boost over the software implemen...
>>
>> Am 20.03.2017 um 09:44 schrieb Kamil Hornicek:
>>  > few other people asked me, but Jerome did it right. Mesa code base
>> is
>>  > rather big and llvm is not small either. Integrating it in our
>>  > building process and keeping it in sync would require huge amount
>> of
>>  > effort. It would also increase both the ISOs and the build time.
>>
>> I'm seeing more and more people afraid of adding anything "big" to
>> our tree. But this is just natural for a project that aims to become
>> a fully fledged operating system!
>>
>> The worst thing would be an OS that can be quickly compiled from
>> scratch and then needs lots of binary blobs to be useful. Even
>> worse, those binary blobs could hardly be verified and patched.
>> Don't forget we already had that with our schannel.dll
>> implementation that depended on an external GnuTLS binary.
>> Fortunately, this is fixed by now and ReactOS supports TLS out of
>> the box.
>> I would like to see the same for a Mesa/Gallium/llvmpipe stack.
>> Having one somewhere hidden in RAPPS, but not in an out of the box
>> ReactOS installation from the ReactOS giveaway CDs would be very
>> disappointing...
>>
>> I also understand the group though who wants the default ReactOS
>> build to be lightweight. So maybe Mesa/Gallium/llvmpipe could become
>> part of another module which is added through our "modules"
>> subdirectory.
>> Our current SVN setup with just one ReactOS repository does not
>> really encourage adding new modules. Another reason for a move to
>> Git where everybody could easily put his big module into an own
>> repository :)
>>
>>
>> Cheers,
>>
>> Colin
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org 
>> http://www.reactos.org/mailman/listinfo/ros-dev
>> 
>>
>>
>> 

Re: [ros-dev] New ideas added to GSoC Ideas list

[Mark Jansen]

Well,

I was thinking a sort of 'hybrid' approach:
We have a generic resource 'template' file (english?), that is used
for strings / dialogs.
Then each translation will have it's .po file.
Translations that need a different dialog layout create a new 'template' file.

To build this, we will need an extra pre-process step (like we do for
utf16 .inf files), to combine the resource template and .po file into
a real resource file.

This saves developers from having to edit 30 resource files when
altering one dialog.




On Wed, Mar 15, 2017 at 1:52 AM, Hermès BÉLUSCA-MAÏTO
<hermes.belu...@sfr.fr> wrote:
> I’m sorry but I should remind you that we *already* have *MANY* apps & dlls
> (not from Wine) where dialog layouts are already different for different
> locales, examples being for French and German languages (amongst others)
> where having adapted sizes for buttons, static text controls, … are
> mandatory, because these languages use frequently long words, etc… . So it’s
> clear we will never go back to a single layout that is shared between
> different locales.
>
>
>
> I should reassure you however, that we don’t care at all about
> “pixel-perfect layout compatibility with windows”.
>
>
>
> A suggestion then, would be to have a resource editor, that can display
> nicely, for a given dialog ID, all the (possibly only the selected ones)
> different dialogs of the different languages, in e.g. mosaic positioning,
> which should help the translator to easily see whether he needs to adapt a
> layout for a given language, or whether he can just copy/paste an existing
> layout.
>
>
>
> Hermès.
>
>
>
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Rafal
> Harabien
> Envoyé : mardi 14 mars 2017 23:44
> À : ReactOS Development List
> Objet : Re: [ros-dev] New ideas added to GSoC Ideas list
>
>
>
> PO files supports "context" markers to make it possible to differentiate
> usage of the same string in different contexts.
> About different layout - yes, we would have only one layout but IMO for
> project like this with human resource problems its more important to make
> development less boring and easier to maintain than to customize dialogs for
> every locale without significant profit. If project treats pixel-perfect
> layout compatibility with windows as requirement it would be a problem but I
> don't think ROS needs it.  We already import multiple dialogs from Wine...
>
>
> W dniu 14.03.2017 o 23:29, David Quintana (gigaherz) pisze:
>
> Gettext-style translations are really really bad, because they use the
> original text (usually in english) as a translation key, which means they
> simply can not handle situations where the same english text needs different
> translations depending on where the text is used. And yes, I have come
> across that issue once upon a time.
>
> You are right that editing a dialog is annoying, but due to the way win32
> resource dialogs work, it's unavoidable. Even if we could have a serpate
> file for reaching the translations, there's often the situation where
> certain languages need different layouts, or at least different control
> sizes, to accomodate for longer / taller text, or RTL. So even if we
> switched to a different system, that annoyance wouldn't go away.
>
> I do agree that it would be nice to have some nicer tool for translators,
> but IMO, .po files are not it.
>
>
>
>
>
> On 14 March 2017 at 23:14, Rafał Harabień <raf...@reactos.org> wrote:
>
> In my opinion it's very sensible proposal. I remember changing  dialog
> layout in resources was a big pain because of amount of repeated work
> for all languages (and error prone). It was demotivating.
> On the other hand there are free translation platforms making project
> translation more organized and easier than editing raw resources. WINE
> is using PO for years and ReactOS IMO should do it as well.
> Just my two cents...
>
> W dniu 14.03.2017 o 14:31, Ștefan Fulea pisze:
>
>> Marți, 14 martie 2017 12:00:02 +, Mark Jansen
>> <learn0more+...@gmail.com> a scris:
>>> How about a better way to translate ros?
>>> For example integrating .po files with our rc files (possibly needs a
>>> preprocess step or something tho),
>>> Or creating a resource editor that allows multiple files to be edited
>>> at once?
>>>
>> Please don't push for .po resources, for these are not better. As for
>> improving the process, I doubt it'd repay the investment. After the
>> initial translation effort, the further maintenance requires very
>> little.
>>
>> ___
>> Ros-dev mailing list
>>

Re: [ros-dev] New ideas added to GSoC Ideas list

[Mark Jansen]

How about a better way to translate ros?
For example integrating .po files with our rc files (possibly needs a
preprocess step or something tho),
Or creating a resource editor that allows multiple files to be edited at once?



On Mon, Mar 13, 2017 at 11:50 AM, Colin Finck  wrote:
> Added that too together with Windows hive compatibility. Please check!
>
> - Colin
>
>
> Am 12.03.2017 um 22:28 schrieb Hermès BÉLUSCA-MAÏTO:
>> Victor thought also about adding registry hive healing.
>> Hermès.
>>
>> -Message d'origine-
>> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Colin Finck
>> Envoyé : dimanche 12 mars 2017 17:27
>> À : 'ReactOS Development List'
>> Objet : [ros-dev] New ideas added to GSoC Ideas list
>>
>> Hi all!
>>
>> Daniel and me collected some additional ideas for GSoC today, which I've 
>> added to our Wiki Ideas list:
>> https://reactos.org/wiki/Google_Summer_of_Code_2017_Ideas
>>
>> In particular:
>> * Fundamental WiFi components
>> * USBXHCI driver for supporting USB 3.x controllers
>> * Bluetooth Stack
>> * WebKit-based MSHTML implementation
>>
>> I'm open for comments and suggestions!
>> We can still add ideas until March 20, so let's give students a large pool 
>> to draw from.
>>
>> Cheers,
>>
>> Colin
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [mjansen] 74063: [NTDLL] Fix RtlDecodeSystemPointer for usage inside ntdll. CORE-10368

[Mark Jansen]

It's following the same style as RtlDecodePointer,
and since it's a simple xor

On Sat, Mar 4, 2017 at 10:02 PM, Michael Fritscher
 wrote:
> Hi,
>
> I don't know - but this looks somehow ... surprising.
>
> Best regards,
> Michael
>
>
>>  /*
>>   * @implemented
>> + */
>> +PVOID
>> +NTAPI
>> +RtlDecodeSystemPointer(IN PVOID Pointer)
>> +{
>> +return RtlEncodeSystemPointer(Pointer);
>> +}
>> +
>> +/*
>> + * @implemented
>
>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] Retiring rapps

[Mark Jansen]

Hello,

Soon (tm) we will be retiring rapps in favor of rapps_new.
If you have any local patches in these regions, now is the time to
step forward (and convert them to rapps_new!).

regards,

Mark Jansen

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] JIRA/FishEye upgrade on March 8

[Mark Jansen]

Colin,

Thanks for the update,
and for taking the time to work on this!

Regards,

Mark

On Fri, Feb 24, 2017 at 7:35 PM, Colin Finck  wrote:
> Hi all!
>
> Let me announce a definite date for our JIRA/FishEye upgrade:
>
>Wednesday, March 8, around 9:00 UTC
>
> Expect downtimes of several hours at https://code.reactos.org and
> https://jira.reactos.org around this time.
>
> I can say for sure that I will have enough time on this day and the
> following to deal with all possible incidents that could happen during
> the complex upgrade.
> This also allows me to get direct in-person feedback from all the devs
> attending CLT on the weekend after that :)
>
> The upgrade to JIRA 7.x is a major one, and Atlassian recommends
> everyone to have a look at the new features:
> https://confluence.atlassian.com/migration/jira-7/server_jira_product-changes
>
> Best regards,
>
> Colin
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Bootlogos for FOSDEM (was: "RE: FOSDEM 2017 - It's happening!")

[Mark Jansen]

c or d seem nice,
d is a bit better i think.

On Sat, Jan 28, 2017 at 6:43 PM, Colin Finck  wrote:

> Am 28.01.2017 um 16:29 schrieb Hermès BÉLUSCA-MAÏTO:
> > I have done several versions and I would like to hear what you think
> from them (if possible, make a choice).
>
> c is great! :)
>
> Cheers,
>
> Colin
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Invitation to join ReactOS Deutschland e.V.

[Mark Jansen]

I have sent my application on 25 nov,
so it should arrive any day now :)
​
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [mjansen] 73180: [SHELL32_APITEST] Add some tests for ShellExecuteEx showing extension completion with the App Paths registry key. Patch by Yaroslav Veremenko. CORE-12049

[Mark Jansen]

Hey,

I just saw the email on my phone, I'll fix it.

On Thu, Nov 10, 2016 at 12:14 AM, Yarolslav Veremenko <
yaros...@veremenko.info> wrote:

> Hi Thomas,
>
> I don't think mjansen is available today. It's my patch. I can update
> CORE-12049 with fixes, so you can commit or send it through mail list.
>
> Yaroslav
>
> -Original Message-
> From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Thomas
> Faber
> Sent: Wednesday, November 9, 2016 4:06 PM
> To: ros-dev@reactos.org
> Subject: Re: [ros-dev] [ros-diffs] [mjansen] 73180: [SHELL32_APITEST] Add
> some tests for ShellExecuteEx showing extension completion with the App
> Paths registry key. Patch by Yaroslav Veremenko. CORE-12049
>
> APITests should be named after a function.
> And in particular, they can't be named the same as a Wine test for the
> same module. This is currently causing result submission on Testbot to
> fail, so please rename this test.
>
>
> On 2016-11-09 23:13, mjan...@svn.reactos.org wrote:
> > Author: mjansen
> > Date: Wed Nov  9 22:13:26 2016
> > New Revision: 73180
> >
> > URL: http://svn.reactos.org/svn/reactos?rev=73180=rev
> > Log:
> > [SHELL32_APITEST] Add some tests for ShellExecuteEx showing extension
> > completion with the App Paths registry key. Patch by Yaroslav
> > Veremenko. CORE-12049
> >
> > Added:
> > trunk/rostests/apitests/shell32/shlexec.cpp   (with props)
> > Modified:
> > trunk/rostests/apitests/shell32/CMakeLists.txt
> > trunk/rostests/apitests/shell32/testlist.c
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [hbelusca] 72943: [PING] - Use a dynamic-allocated buffer with FormatMessageW, fixes messages disappearance (eg. ping help in russian). CORE-12108 #comment Fixed in r72943. -

[Mark Jansen]

Be careful with that, they do not have to be null-terminated!
the return value will give you the length in this case.

On Sun, Oct 9, 2016 at 9:45 AM, Colin Finck  wrote:

> hbelu...@svn.reactos.org wrote:
> > +#define RC_STRING_MAX_SIZE  4096
> > +
> > +WCHAR Format[RC_STRING_MAX_SIZE];
> > +LPWSTR lpMsgBuf = NULL;
> > +DWORD Len;
> >  va_list args;
> >
> >  if (!LoadStringW(GetModuleHandleW(NULL), id, Format,
> > _countof(Format)))
>
> Now instead of
>
> #define RC_STRING_MAX_SIZE  4096
> WCHAR Format[RC_STRING_MAX_SIZE];
> LoadStringW(GetModuleHandleW(NULL), id, Format, _countof(Format));
>
> just do a
>
> LPWSTR lpFormatBuf;
> LoadStringW(GetModuleHandleW(NULL), id, (LPWSTR), 0);
>
> and you have a perfect universal solution for any resource string length
> without caring about buffer sizes at all. It doesn't even need any extra
> memory :)
> This should actually be changed in a lot of places!
>
>
> - Colin
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Pale Moon drops ReactOS support

[Mark Jansen]

For the features where this is possible without kernel support,
there is a mechanism in the pipeline that makes this possible: 'apphelp'
Currently I am still working on the base layer,
but when that is progressed a bit more we could integrate it more tightly
in the Ldr,
so that it uses the target platform to apply automatic fixes (shims).

Having said that, it might be worth to upgrade parts of the kernel (only
where it makes sense) to NT6 already,
without exposing that to applications.
Especially in new parts, as it would mean that something is written for NT5
now, and first thing we do next is upgrade it to NT6.


On Thu, May 12, 2016 at 6:39 PM, Zachary Gorden 
wrote:

> Quite a few 'userland' features of NT6 requires kernel support to
> function properly. If we go in, it would be, do NT6 kernel and slowly
> bring the userland up to NT6. But we don't have a fully working NT5
> kernel yet, so
>
> On Thu, May 12, 2016 at 8:34 AM, David Quintana (gigaherz)
>  wrote:
> > If we do NT6, we may want to have latest NT6 instead of trying to stick
> to
> > an older one and having the same deprecation issue in a couple years?
> >
> > Also, what about the "idea" of keeping the majority of the kernel and
> large
> > part of the usermode NT5, but having compatibility profiles that
> > implement/emulate NT6 API functions using the existing NT5 feature set?
> Is
> > that unrealistic?
> >
> > On 12 May 2016 at 14:39, Aleksey Bragin  wrote:
> >>
> >> Which again brings in the topic of updating the version we are
> targeting.
> >> Windows 7 would be a minimum target these days, IMO.
> >>
> >> Regards,
> >> Aleksey Bragin
> >>
> >> On 12.05.2016 14:04, Ged Murphy wrote:
> >>>
> >>> Yeah it's nonsense. No one drops support for ReactOS, they drop support
> >>> for
> >>> older versions of Windows which likely includes reactos too.
> >>> If they were adding in ReactOS specific code, they were doing it wrong.
> >>>
> >>> The bigger issue here is that a lot of apps are starting to drop
> support
> >>> for
> >>> XP and recommend a minimum of Win7. If we don't do something about our
> >>> insistence on sticking with 2k3, we'll soon be in a position where no
> >>> browsers will run on ros, as well as a whole other list of apps.
> >>>
> >>> Ged.
> >>>
> >>
> >>
> >> ___
> >> Ros-dev mailing list
> >> Ros-dev@reactos.org
> >> http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >
> >
> > ___
> > Ros-dev mailing list
> > Ros-dev@reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] ReactOS SVN Version Naming

[Mark Jansen]

This way of numbering seems very confusing to me, and I assume to other
people as well..
When ReactOS presents itself as 0.5-SVN, I would expect this to be a 0.5
release, and not a 0.4 release that is working towards a 0.5.


regards,

Mark


PS: I wasn't subscribed at the time this was sent, so sending a 'fake'
reply :)


*Ged Murphy* gedmurphy.maillists at gmail.com
> 
> *Mon Feb 29 16:07:49 UTC 2016*
>
> Because that’s what is being worked towards now, and there will be an
> unknown number of point releases until it’s reached.
>
> It’s also a bit of nostalgia, it’s what we’ve always done :)
>
>
>
>>
>> From: Ros-dev [mailto:ros-dev-bounces at reactos.org 
>> ] On Behalf Of Hermès
>> BÉLUSCA - MAÏTO
>> Sent: 29 February 2016 16:00
>> To: ReactOS Development List > >
>> Subject: [ros-dev] ReactOS SVN version naming
>>
>> Hi guys,
>>
>> I would like to understand what’s 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.
>
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev