Hello everybody,
Just to let you know, I've just added HTTP/WebDAV access for our
read-only Git mirror as requested by a developer.
This means that you can also clone from
http://git.reactos.org/reactos.git now if you sit behind a firewall
blocking the Git protocol.
Of course, the previous URL git://git.reactos.org/reactos.git will
continue to work.
Best regards,
Colin
HI,
recently I had to alter some inf-files for fixing a bug. At present we have
for each platform (i386, arm, amd64) separate files, which are hard to
maintain because of some identical, that aren't platform dependent. Therefore
I suggest the following change and I will write an example and the necessary
tool:
- combine all platforms to one file and work with special block markers
- block markers work like filters, empty markers means all platforms otherwise
the platforms limited to are given in comma separated lists
- we have to maintain only one single file and the alteration is minimal,
because the marker is a simple (syntactically comment) line
like ";#platform_a,platform_b#" or ";##"
- the needed file is extracted at build time, always up-to-date and shipped in
the same way as present
General remark: we have to make some efforts to bring (or at least to keep)
the project in understandable and maintanable state. We have to use and
introduce tools to reduce needless efforts resulted by managing multiple
similar files which could be better generated without failures (that people
tends to do). This and only this is my intention for this suggestion.
Request for comments - other ways or changes with same goal are welcome
Matthias
--
Matthias Kupfer phone +49 371 236 46 52
Wilhelm-Firl-Straße 21 mobile +49 160 859 43 54
09122 Chemnitz, Germany
Hi guys/devs/testers/translators/followers !
I have just received this information from the OSWC organization:
"Nos complace comunicarle que su propuesta presentada al Call for Paper ha sido
aprobada de forma preliminar por el Comité de Ponencias de la Conferencia
Internacional de Software Libre para su comunicación pública.
Actualmente el programa de la Conferencia se encuentra en una fase temprana de
elaboración, por ello solicitamos de usted nos comunique antes del próximo día
28 de septiembre de 2010, su disponibilidad para estar en Málaga tanto el día
27 de octubre, el 28 o ambos.
Agradecemos su dedicación e interés y esperamos disfrutar de su compañía en
Málaga
Atentamente "
You can use Google translator. Or summing up: "We are IN"
Thanks to anyone who has voted and wish me good luck :)
If anyone is interested about coming, please contact me before 28 September (there is one day just for professionals and closed to the general public) :)
Victor Martinez
"
> From: gedmurphy(a)gmail.com
> To: ros-dev(a)reactos.org
> Date: Thu, 23 Sep 2010 08:09:57 +0100
> Subject: Re: [ros-dev] 0.3.12 milestones status
>
> victor Martinez wrote:
>
> > In the same way, and imho, I think it is much better
> > to avoid sending critical code one month before the release.
>
> This isn't how you release.
> The whole point in branching for a release is so you can stabalise the
> branch whilst trunk continues to be 'bleeding edge'
> What's the point in branching otherwise? We may as well just tag trunk and
> do away with branching.
I am not agree :) As far as i see we have tried to (more or less)stabilize trunk before branching at least in the 2 latest releases. An i.e is the 0.3.12 release, if we are following the "bleeding edge" concept then we should have branched several months ago and just pulled the regression fixes from trunk to the branch. Our approach was different: Stabilizing trunk fixing the known regressions (which,btw,were marked as Milestones) and then branching.
There is not an incompatibility with the "stabilizing trunk" and "branching" concepts. First because exists the "Hack-releases" (fixes just applied for the release) and that just can be done in a branch. Second because a (more or less) stabilized trunk doesn't mean a regression-free trunk (but it could be).
The first main advantage (about avoid sending critical code in the month we are going to release) is that we will have a whole month to check if the critical changes has waken up underlying bugs (or if the critical changes has introduced Eisenbugs).If we are following the "bleeding edge" approach we can just pray to find those Eisenbugs in the Release Candidate ISO tests and, since there aren't a lot of testers checking the RC ISO, it is quite unprovable.
The second main advantage is that we reduce the Release Engineers amount of work. It is not the same bugging them to create just one RC ISO than bugging them to create 2 or 3 because playing with the "bleeding edge" concept.
> > I am not agree :) As far as i see we have tried to (more or less)
> > stabilize trunk before branching at least in the 2 latest releases.
> This is because trunk has been in a mess for the past few releases.
> Due to its instability it wasn't worth branching it as it was so far from
> being releasable.
> In the past we had (strived for) a 2 month release cycle.
> We branched every 2 months no matter what and then worked on getting that
> release out.
> This is how linux and most other serious open source projects work. It's all
> about discipline.
"About discipline" and about having a lot of developers which can cover all the needs a project has. ;)
And let me not talk about some "serious open source pojects" with tons developers/users which has introduced and released with critical regressions.
> > There is not an incompatibility with the "stabilizing trunk" and
> > "branching" concepts. First because exists the "Hack-releases" (fixes
> > just applied for the release) and that just can be done in a branch.
> > Second because a (more or less) stabilized trunk doesn't mean a
> > regression-free trunk (but it could be).
> This is exactly what it's for. Branch, fix bugs or hack bugs away.
> Merge real bug fixes back into trunk, tag and release.
Sure, I was just answering to your "What's the point in branching otherwise?" which seemed to be a question about an incompatibility with "avoiding critical commits" and "stabilizing trunk" before branching.
> > The first main advantage (about avoid sending critical code in the
> > month we are going to release) is that we will have a whole month to check
> > if the critical changes has waken up underlying bugs
>
> This is the ongoing job of the testers to do both in trunk and more
> importantly, in release branch.
> If any serious bugs are found late in the process, drop the branch, fix in
> trunk and rebranch.
Just 2 words: Im-possible. :) You need a testing time frame.
There is something called "Probability" of finding a regression(even more finding an eisenbug). If you branch right after a critical commit and that critical commit has introduced a regression you have much less "Probability" to find it that if the last critical commit was made 1 month ago.
Even more, Release Candidates are mainly just tested by the Testers. So finding the regression depends mainly on "Probability Testers find a regression in one week"
But during that Quarantine month other commits (non critical ones) can be sent and developers can feel/find regressions too. So finding the regressions would depend mainly on "Probability Testers and Devs find a regression in one month". Notice that the testing group is wider and so the time.
We don't have Testing manpower to find a regression the next day/week it was commited.
> > The second main advantage is that we reduce the Release Engineers amount of work.
> But you hamper development. Locking down trunk for a month before every
> release is a sure way to drive away all of your developers.
> I would refuse to work on a project which worked in this way, as would most
> other devs I assume.
Who talked about freezing trunk? I should define 1-month Quarantine better: "Avoid commiting to critical areas. The trunk is open for those non-critical ones. You can send meanwhile your critical patches to a branch and after the release pushing them to trunk.". You have a ReactOS branch if needed.
> If you're finding when release time comes that no devs work on fixing the
> release branch and instead continue adding new code to trunk, then you have
> a developer discipline issue not a release process issue.
If we pay our developers we can ask for discipline meanwhile we can just accept their patches or refuse them.
Will you refuse a Patch? Or maybe revoke a Dev commit access to create discipline? Any useful ideas?
> Locking trunk is just a way to work around your developer discipline problem
> instead of tackling the real problem, your devs can't be bothered to fix
> existing code and continue to ignore their duties and add new code instead.
Noone talked about Locking Trunk, and there are no duties. IIRC you were the first person that explained me why there are no dutie$ in this project.
> Ged.
Vic
Hello,
0.3.12 was branched today, so I removed the lock from trunk. However,
I want to really ask everyone not to jump into modern fancy features
but pay more attention to fixing core parts of the system.
Victor is doing the change log draft, and if Colin has time I would
like to ask him to apply our usual release stuff.
WBR,
Aleksey Bragin.
You have done a pretty cool work.
0.3.12 Changelog is opened, I have added a "Regression", "General Bugs" section where i reflect the Bugs fixed from 0.3.11 to 0.3.12. This is a little bit more user-friendly.
You can find it here: http://www.reactos.org/wiki/ChangeLog-0.3.12#General
The Bugzilla stats shows the next:
- There were 259 General Bugs fixed (Regressions fixed are not counted here)
- There were 20 Translations sent in 11 different Languages.
- And you fixed 61 Regressions
So more than 320 bugs has been fixed in less than 300 days.
(Without counting Bugfixes in branch)
You have killed more than 10 bugs older than 3 years old. And the eldest one is "#969 Minimized windows are shown on desktop" which is 5 years old.
Congratz :)
[CC] dll/win32/kernel32/file/file.c
cc1: warnings being treated as errors
dll/win32/kernel32/file/dir.c:21: error: 'gDebugChannel' defined but not used
make: *** [/mnt/ramdisk/buildbot/release/obj/dll/win32/kernel32/file/dir_kernel32.o]
Error 1
make: *** Waiting for unfinished jobs....
Hello,
After the switch in 48124 to PE FreeLDR, I am unable to boot FreeLDR any longer.
I have tried official, as well as various unofficial freeldr.sys, none worked.
47892 version works fine, 48124 does not.
On a 512MB IDE disk, I got the "_" VGA cursor scrolling endlessly/randomly on the screen, before even seeing "Loading FreeLDR..."
With a 1GB SCSI disk, tested also with a 6GB IDE disk, it remains stuck at "Loading FreeLDR...".
This seems strange: "Now booting from fat partitions (looks like that's what sysreg does) works again. It's safe under the condition that the cluster size is at least 4352 bytes, which is true for harddisks of sizes bigger than 272MB. Booting from smaller fat disks, like floppy breaks when freeldr.sys gets fragmented, which should rarely happen."
Please advise.
-r
