Ros-dev June 2019

ros-dev@reactos.org

3 participants
3 discussions

BuildBot Upgrade on Tuesday
by Colin Finck 23 Jun '19

23 Jun '19

Hi all! Our BuildBot at https://build.reactos.org is finally going to be upgraded from the ancient version 0.8.14 to the latest 2.3.1 release this Tuesday evening (CEST). We have postponed this for a very long time due to the fundamental UI changes in newer versions. The UI has been rewritten from scratch and its Waterfall View has been simplified. I used to be a strong opponent of this change. However, in one of the last meetings, it turned out that the current Waterfall View isn't that popular among our developers anyway. You can expect the new BuildBot to look like this: https://lidell.nu/xemacs-buildbot/ BuildBot also doesn't provide a direct migration path from the old to the new version. This means that previous build and log information will be gone after the upgrade. I used to consider this a blocker as well, but current BuildBot already purges old build/log information after some time and apparently it hasn't been missed. We still have all important information in Testman. I will make sure however that build numbers in the new version continue where they ended in the old version. On the plus side, this upgrade brings integrations with GitHub and Mattermost as well as proper Unicode support. Using an up-to-date BuildBot version also allows us to actually enhance it. In fact, this upgrade is a prerequisite for the Developer Web Interface our GSoC student Ayush Sinha is currently working on. Regarding Buildslaves (now called "workers"), the new BuildBot is still compatible with 0.8.x clients, so these don't need an upgrade right away. We just need a small change on workers submitting test results. Kudos go to Victor Perevertkin, who has already begun evaluating the new BuildBot version a long time ago and provided me with an updated master.cfg file, along with other help! I'm glad that the number of people maintaining our BuildBot setup is growing! :) Cheers, Colin

1 0

Coding style fixes/improvements
by Victor Perevertkin 07 Jun '19

07 Jun '19

Hi! Recently I've looked into Doxygen manual for writing documentation and noticed that an example on our Coding style <https://reactos.org/wiki/index.php?title=Coding_Style> page on wiki uses some statements in a wrong way. Namely, @name statement is for defining sections, groups and definitely not for functions/structs/classes etc. Another thing is a function description. Doxygen has two types of them: brief and detailed one. Brief description must be defined by @brief statement, but for detailed one @details can be omitted (which in fact was done in our example). Obviously, brief description should be used in first place (and that would be likely the only one) I've made some changes, to the page (see the latest change in page history) Btw, I think it can be extended to something like this ( http://micro-os-plus.github.io/develop/doxygen-style-guide/) sometime If you have any objections or suggestions, feel free to add them or discuss here. Cheers, Victor

1 0

Re: [ros-dev] [ros-diffs] [reactos] 02/02: [SETUPAPI] Fix a typo in CM_Query_Resource_Conflict_List.
by Thomas Faber 07 Jun '19

07 Jun '19

This does not seem right. On 2019-06-06 19:14, Eric Kohl wrote: > https://git.reactos.org/?p=reactos.git;a=commitdiff;h=c47ad98ff79ad98042ff2… > > commit c47ad98ff79ad98042ff2043d739be58770c2fbc > Author: Eric Kohl <eric.kohl(a)reactos.org> > AuthorDate: Thu Jun 6 19:12:44 2019 +0200 > Commit: Eric Kohl <eric.kohl(a)reactos.org> > CommitDate: Thu Jun 6 19:12:44 2019 +0200 > > [SETUPAPI] Fix a typo in CM_Query_Resource_Conflict_List. > --- > dll/win32/setupapi/cfgmgr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dll/win32/setupapi/cfgmgr.c b/dll/win32/setupapi/cfgmgr.c > index 8215d47ac63..d33a6497172 100644 > --- a/dll/win32/setupapi/cfgmgr.c > +++ b/dll/win32/setupapi/cfgmgr.c > @@ -6761,7 +6761,7 @@ CM_Query_Resource_Conflict_List( > if (lpDevInst == NULL) > return CR_INVALID_DEVNODE; > > - pConflictData = MyMalloc(sizeof(CONFLICT_DATA)); > + pConflictData = MyMalloc(sizeof(PCONFLICT_DATA)); > if (pConflictData == NULL) > { > ret = CR_OUT_OF_MEMORY; >

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev June 2019