Joachim Henze wrote:
> commit adee5ca255b7ed21f359ca8c1ca06bd44db90dcf
> Author: Joachim Henze <Joachim.Henze at reactos.org>
> AuthorDate: Mon Jun 28 02:05:56 2021 +0200
> Commit: Joachim Henze <Joachim.Henze at reactos.org>
> CommitDate: Mon Jun 28 02:05:56 2021 +0200
>
> [COMCTL32] Addendum to last commit (#3674) CORE-17199
>
> Keep that section like we had it to
> support compilation on VS2010.
> It does still work like that.
>
> [...]
>
> diff --git a/dll/win32/comctl32/datetime.c b/dll/win32/comctl32/datetime.c
> index 71bb3d238b0..51e58fc71f1 100644
> --- a/dll/win32/comctl32/datetime.c
> +++ b/dll/win32/comctl32/datetime.c
> @@ -130,8 +130,13 @@ static const WCHAR allowedformatchars[] = L"dhHmMstyX";
> static const int maxrepetition [] = {4,2,2,2,4,2,2,4,-1};
>
> /* valid date limits */
> +#ifndef __REACTOS__
> static const SYSTEMTIME max_allowed_date = { .wYear = 9999, .wMonth = 12, .wDayOfWeek = 0, .wDay = 31 };
> static const SYSTEMTIME min_allowed_date = { .wYear = 1752, .wMonth = 9, .wDayOfWeek = 0, .wDay = 14 };
> +#else
> +static const SYSTEMTIME max_allowed_date = { /*.wYear =*/ 9999, /*.wMonth =*/ 12, /*.wDayOfWeek =*/ 0, /*.wDay =*/ 31 };
> +static const SYSTEMTIME min_allowed_date = { /*.wYear =*/ 1752, /*.wMonth =*/ 9, /*.wDayOfWeek =*/ 0, /*.wDay =*/ 14 };
> +#endif
This adds an unnecessary ReactOS-specific diff to a file that was
perfectly in sync with Wine 6.0 before, just for supporting an old
compiler that has not only been abandoned by us, but obviously also
upstream.
Being able to source this file unmodified (and eventually sourcing all
of comctl32 automatically via a Git submodule/subpath/repo xml file)
beats any such hack.
I therefore call for a revert.
Even worse than all of that, this commit has been silently sneaked on
top of a PR without any review!
Joachim, you love to criticize the instability of the master branch, yet
continue to ignore basic development practices we have established.
And this isn't happening for the first time. Another example is
https://github.com/reactos/reactos/commit/889eab78ca7c0f17a2ada9ff20de5807a…
where you disable sanity checks and create a diff to upstream. All
without reviews and all just for your private goal of reducing the
binary size of debug builds, something that is not important at the
current stage of ReactOS.
I would love to see PRs for your ideas, and then we can discuss
everything that hasn't been decided before (i.e. not VS2010 support again).
But if this doesn't stop, I have no chance other than removing your push
access to the GitHub repo, as everything else would mean condoning that
uncooperative behavior.
Best regards,
Colin
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
Whoa so many volunteers. ^^
Ok, I will note all down and then tomorrow check the limits we have. If one is not allowed to be added by me anymore I will still more than welcome everyone who wants to join the party. Maybe we even can add more on our own later. :D
Greetings
Daniel
Stas'M <binarymaster(a)mail.ru> schrieb am Sa, 20.02.2021 21:44:
> It seems Aleksey and Alexander are in, so it's going to be very interesting!
>
> Daniel, count me in :)
>
>
> --
> Stas'M was here
>
>
> Thursday, 18 February 2021, 12:54 +03:00 from "Daniel Reimer" <daniel.reimer(a)reactos.org>:
> > 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(a)reactos.org
> > http://reactos.org/mailman/listinfo/ros-dev
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://reactos.org/mailman/listinfo/ros-dev
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
Hello!
It seems for me that it's time to bring up the topic about our RC
version - 0.4.14.
Our current "stable", 0.4.13 was branched on 30 September, 2019
(remember those peacefull pre-COVID times :D)
That's quite some time, but not the main issue I'd like to discuss.
0.4.14 was branched on 24 April, 2020. That's almost a year already.
And we're in a difficult situation here - there are regressions, but
nobody fixed them within this long time.
According to https://reactos.org/wiki/Tests_for_0.4.14, there are 29
unfixed regressions found for this release. I'd like to point out: most
of them are among usermode and non-kernel/driver functionality, and as
our development is mostly focused in the kernel right now, it's
unexpected for them to be fixed unless a volunteer comes up.
A quick reminder. Our "releases" mechanism is useful for finding
regressions in the first place, there is no that much benefit for users
here, because we're still a "deep" alpha. Correct me if I'm wrong.
Joakim made a great job finding all regressions, and this work won't be
lost in any case.
We can't wait forever and I think it's time to resolve this situation
somehow. I see two options:
1. Release 0.4.14 as-is. There were a lot more buggy releases, nobody
dies from this.
2. Skip 0.4.14. This already happened once in the history of the
project - 0.3.2 was skipped. I wasn't around at the time, but I may
guess that reasons were similar to what we have today.
(3.) Fix the bugs quickly. I don't expect this to happen, but who
knows, maybe a volunteer appears :)
Let's vote. This seem to be the only way for us to decide on things.
Votes from the team members will be collected until 1 March.
===
I personally vote for skipping the release. The work on finding
regressions is already done, so the most important part of a release
cycle for us is there (thanks Joakim!)
If we do a release now, all the stuff we were writing in news reports
for the last 6 month would be missing from it. That would cause (as I
think) a lot of confusion to people. Moreover 0.4.14 is not that
featureful release itself (compared to 0.4.13, which brought the new
USB stack)
So I suggest to move on and start checking 0.4.15 for regressions. I
expect quite some of them to appear and we need time for fixing.
Cheers,
Victor
Hey Tom,
USB-Boot works with current nightlies and GPT is in the Works AFAIK(Hermes
should know more details).
Best Regards
Robert
Thomas Mueller <mueller6723(a)twc.com> schrieb am Mi., 10. Feb. 2021, 11:01:
> from Colin Finck:
>
> > This is not the kind of participation that has any place on the mailing
> list
> > of an open-source project.
> > Unsubscribed and blocked that person.
>
> > Colin
>
>
> > Am 09.02.2021 um 17:26 schrieb Dick:
>
> > > Hi,
> > > as a potential user this project makes me extremely tired. in 2000 or
> > > something like that i was excited because afvree windows replacement
> > > would be there...... it is 221!!! years later and there is...... still
> > > nothing, jst deep alpha as stated in last email. and 0.14 woudl have
> even
> > > regressions for 0.4.13. wouldnt it be more smart to finally build a
> > > timeline for this all? or to discuss the fact if this project makes any
> > > sense yet, it seems just a waste of time this way.
>
> First of all, I sent the wrong message a couple times, to ros-general.
> Now for the intended message:
>
> I have been idle with ReactOS because of no place to put it, and ReactOS's
> inability to boot from a USB stick.
>
> I can't install ReactOS on hard drive because of lack of GPT.
>
> I would need to be able to use ROSBE and write the result to a USB stick
> to boot, but don't think that is workable.
>
> Tom
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://reactos.org/mailman/listinfo/ros-dev
>
Hi all!
Our IServ system used for mail and mailinglists will be down for
maintenance on
THURSDAY, 4TH FEBRUARY 2021
15:00 ~ 17:00 UTC
During this time, you won't be able to send or receive any mails using
your @reactos.org address. Mail that is sent to an @reactos.org address
will usually be delivered later.
Other services won't be affected by this migration. In particular, all
means of communication through Mattermost or the website/forums will
stay live.
Best regards,
Colin Finck
Hello everyone!
We've got accepted to FOSDEM 2021, which (as you may already know) will be going online.
FOSDEM provides a place on their stands website, we need to prepare a page for that.
There is also a place for videos in case we want to share some :)
Their website uses Hugo and is available on Github (https://github.com/FOSDEM/stands-website)
The documentation is provided here: https://github.com/FOSDEM/stands-website/blob/master/README.md
Let's discuss what should we present there, there is not that much time left! The conference is held on 6-7 February
Cheers,
Victor
What about that discussion about why we have ditched out MSVC 2010 support
(starting to depend on that fact, and thus, breaking any possibility of
self-hosting ROS building on ROS using MSVC compiler (without the IDE),
since later versions of MSVC only work on Vista+, and as an indirect
consequence, too, opening the can of worms, that is, being able to
"pollute", involuntarily or not, the ReactOS core code (kernel + drivers)
with C99+ non-standard portable code -- ),
and without having first warned heavily through all the mailing lists etc. ,
thus allowing the developers to voice their concerns publicly in the MLs ?
This was done around in mattermost only, after we decided for some reason
that we wouldn't need the VC2010 buildbots anymore.
Hermes.
-----Original Message-----
From: Ros-dev <ros-dev-bounces(a)reactos.org> On Behalf Of Colin Finck
Sent: Sun Nov 15 17:24:22 UTC 2020
To: ReactOS Development List <ros-dev(a)reactos.org>
Subject: [ros-dev] Status Meeting (November 2020)
Hi all,
With several people asking for a status meeting, let's have another one
before the year is over.
Let me invite you to the meeting on
Thursday, 26th November 2020
19:00 UTC
Mattermost private channel "Meeting"
So far, there is only one point on the agenda:
* Achievements and Future Outlook (everyone)
What have you been working on and what are your plans?
Please submit further agenda proposals by answering to this mail.
Looking forward to see you!
Colin
I wanted to add, that vgal and Doug Lyons were also favoring continued VS2010 support, as we can see clearly
in the PRs discussion https://github.com/reactos/reactos/pull/2658
Please do count also those contributors voices.
Some more regarding some brought up arguments:
>>"BTRFS and its sync will benefit from the drop":
I see a working BTRFS in 0.4.14RC60, which has VS2010 support.
And I see a totally broken BTRFS that does not even boot at all any longer in master head 0.4.15-dev-1605-gab45955.
A fact.
>>"We should replace all proven compilers with superior Clang"
I have not seen a ros yet, that would even boot at all with Clang.
Also according to discussions they do still lack SEH 32bit support.
And even if they would develop that one day, how big will the resulting ros isos be then?
And that still would not solve the compat to older build platforms 2k3sp2/XPSP3 and ros.
Wishful thinking just.
>>"We need the drop for the new standard library."
And where is that library? No one did ever integrate that into ros, although the compilers drop has been rushed into master months ago already.
As Hermes said already: I see no gain, but I do see a lot of pain and unfinished WIP+wishful thinking.
Hello guys,
I have just read at Facebook that Andrew Greenwood's father (andrew's nick
is *silverblade* at ReactOS) passed away last night due to CoVid19.
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
Hello,
as Colin already mentioned, I have tried to compile libc++ for ReactOS.
I stopped the project for two reasons:
1. The current state of the CRT in ReactOS.
2. The ongoing discussion about MSVC 2010.
With MSVC 2010 it is of course impossible to compile a current version of
libc++. So why should I waste my time?
Without a clear commitment to using current C++ compilers, it simply makes
no sense.
As Colin described in detail, current technologies would increase the pace
of development and attract more interested developers.
Developers like me, who simply do something else without the project ever
knowing about them.
But don't get me wrong, this is not about me or libc++. Maybe libc++ cannot
be used for other reasons after all! But with MSVC 2010 you don't even have
to start.
All the best,
Dominik
I totally and vehemently agree with Hermes here: We should NOT ditch VS2010.
Arguments that were raised by others against VS2010 and my reply:
-"ditching it brings in new developers to ros magically" <- I do ask then, where are they? I don't see any.
-"we should not be limited to strict C89" <- No one did request for that. All we want is to remain compatible to VS2010. A subset.
-"syncing BTRFS is a bit harder" <- So what? Then let others do the job. Actually BTRFS is not even a mandatory feature of ros. Having it in the tree is just luxury.
-"libc++" <- I see no urgent need and nothing it would give in return that would outweight what we would sacrifice.
My arguments again for keeping VS2010:
-VS2010 creates the smallest binaries of all compilers we do support
-VS2010 CAN be installed in ros, when ros is installed as Server during 2nd stage, (yes this was not the case for a very short moment, unfortunately exactly when we discussed in https://github.com/reactos/reactos/pull/2658 but now it works again, even in 0.4.14-RC51)
-VS2010 can now even open the VS2010 cmd prompt see https://jira.reactos.org/secure/attachment/57140/57140_0.4.15-dev-203-g711f…
-no other VS>2010 can even complete its setup in ros, and that will remain like that for many years to come
-VS2010 is the last version that runs on XPSP3 (which is important for some of our devs including myself)
-VS2010 is the last version that runs on 2k3SP2 which is our current target
-VS2010 is reliable with industry-proven stability, and itself no moving target (unlike VS2019 which breaks our builds every few weeks when MS upgrades it)
-VS2010 DOES provide std::unique_ptr. Stating anything else is just a lie. It covers > 95% of CPP2011-standard. It is absolutely possible and not complicated to write leak-free-code with it.
Hello,
Please note that I would like to cast a vote in favor of restoring
compatibility for VS2010.
Thanks very much,
Doug Lyons
--
This email has been checked for viruses by AVG.
https://www.avg.com
Hi all,
With several people asking for a status meeting, let's have another one
before the year is over.
Let me invite you to the meeting on
Thursday, 26th November 2020
19:00 UTC
Mattermost private channel "Meeting"
So far, there is only one point on the agenda:
* Achievements and Future Outlook (everyone)
What have you been working on and what are your plans?
Please submit further agenda proposals by answering to this mail.
Looking forward to see you!
Colin
Would on August 31 be alright for you? I'm asking because I won't be available by September 5 or 7 from now on due to a temporary job that I'm going to have soon.
Regards,
George
Colin Finck <colin(a)reactos.org> wrote on Fri, August 14th, 2020, 5:24 PM:
> 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
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
Hola que tal, estoy realizando mi tesis basándose en ReactOS y quisera
saber mas informacion sobre el SO, tengo curiosidad si ustedes también
trabajan con GNUPG o algun tipo de sistema de cifrado para los archivos y/o
particiones del disco duro y si me podrian explicar porque esa parte no
esta explicado en ninguna documentacion de ReactOS, se los agreadeceria si
me podrian brindar esa informacion y/o orientarme les agredeceria de
antemano.
Muchas gracias.
--
Saludos
--
Sthip Harrisson Russell Panduro.
Correo: sthiplife(a)gmail.com
Hi,
I'm Frédéric from QubesOS project. I wanted to try your latest release ReactOS 0.4.13 today and I've managed to install it on our latest QubesOS R4.1 in development within a HVM domain. First text installer for partitioning is fine and the graphical setup for languages and parameters too. At first OS boot while seeing the desktop for the first time, it popups a window pci device detection but then, just few seconds after the VM is freezing. Looking at Xen status, the stubdomain is not frozen at all, but the VM itself yes with 100% CPU usage. I've tried IDE driver for disk too but the same behavior appeared.
Any idea on how I can catch errors or having logs? Should I try your debug ISO?
Thank you in advance for your help.
Frédéric
PS: https://jira.reactos.org/browse/CORE-13358
I'd like to propose what I have on my mind:
- 0.4.14 release status, what's left to do (should be a short one)
- Unifying our contribution guidelines. I've found out that we have too many places with instructions for contributors. And if fact they don't quite indicate our expectations of a good pull request.
A couple of weeks ago we gathered our ideas for contributor's and reviewer's guidelines and put them in a google doc: https://docs.google.com/document/d/1osRfG0PelNyDAwlwGFrIL-D12WeuxV3BO_GzW0N…
I'd like to have a bit of a discussion about all we wrote there and then we will try to compile new guidelines from it.
- This partly overlaps with the previous one. We have some pull requests where people with relevant experience are missing in our team. (atm I'm talking mainly about LSASS PR https://github.com/reactos/reactos/pull/2230, but such situation is possible in future)
I suggest treating such PRs with a "light" scheme: only check for code style, some obvious mistakes etc. Otherwise they will be stuck forever
Colin Finck <colin(a)reactos.org> wrote on Tue, June 23rd, 2020, 8:44 AM:
> Short reminder that the meeting is going to take place this week's Thursday.
>
> Unfortunately, I didn't get a single mail regarding the meeting agenda.
> However, I took from Mattermost that some people (Daniel in particular)
> want to talk about channel moderation, so I'm putting it on the agenda:
>
> * Channel moderation (Daniel)
>
> There may have been other things I missed, which is why I reiterate to
> send all agenda proposals by E-Mail.
>
> See you then,
>
> Colin
>
>
> Am 04.06.2020 um 09:13 schrieb Colin Finck:
> > Hi all!
> >
> > Let me invite you to the (almost) bi-monthly status meeting, taking
> > place Thursday, 25th June, 19:00 UTC, in the Mattermost private channel
> > "Meeting".
> >
> > I missed to announce a meeting last month and also didn't get any
> > proposals for the agenda. But apparently there is a need to discuss a
> > few things.
> > Therefore, please submit your agenda proposals by E-Mail to me now.
> > I will then announce the final agenda one week in advance.
> >
> > Topics I would like to speak about:
> >
> > * Achievements and Future Outlook (everyone)
> > What have you been working on and what are your plans?
> >
> > * GSoC 2020 Status (org admins and mentors)
> > Just a short update on how the GSoC projects are doing
> >
> >
> > Best regards,
> >
> > Colin
> >
> >
> > _______________________________________________
> > Ros-dev mailing list
> > Ros-dev(a)reactos.org
> > http://reactos.org/mailman/listinfo/ros-dev
> >