Hello, the trunk of our SVN server has been locked to prevent even more regression from entering the tree.
So far, after more than 3 weeks after I filed the bug report and not including all previous time when people were complaining about rapps which can't download anything at all - either hangs or crashes, I see that now even PCNet network card is being recognized in my VMWare Workstation 6.5.
Trunk is writable right now by members of the bugfix team only, that's so far Cameron (because he is the one supposed to fix networking) and me. If someone volunteers to fix any of the existing regressions, please let me know on irc/email, I'll include you into the bugfix team.
Thanks for understanding, and patience. My patience is over.
WBR, Aleksey Bragin.
I assume trunk is now unlocked?? There's been no mention of it but commits have restarted
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Aleksey Bragin Sent: 17 November 2009 21:35 To: ReactOS Development List Subject: [ros-dev] Trunk locked
Hello, the trunk of our SVN server has been locked to prevent even more regression from entering the tree.
So far, after more than 3 weeks after I filed the bug report and not including all previous time when people were complaining about rapps which can't download anything at all - either hangs or crashes, I see that now even PCNet network card is being recognized in my VMWare Workstation 6.5.
Trunk is writable right now by members of the bugfix team only, that's so far Cameron (because he is the one supposed to fix networking) and me. If someone volunteers to fix any of the existing regressions, please let me know on irc/email, I'll include you into the bugfix team.
Thanks for understanding, and patience. My patience is over.
WBR, Aleksey Bragin.
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Aleksey announced via IRC that trunk is open for commits again.
2009/11/28 Ged Murphy gedmurphy@gmail.com
I assume trunk is now unlocked?? There's been no mention of it but commits have restarted
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Aleksey Bragin Sent: 17 November 2009 21:35 To: ReactOS Development List Subject: [ros-dev] Trunk locked
Hello,the trunk of our SVN server has been locked to prevent even more regression from entering the tree.
So far, after more than 3 weeks after I filed the bug report and not including all previous time when people were complaining about rapps which can't download anything at all - either hangs or crashes, I see that now even PCNet network card is being recognized in my VMWare Workstation 6.5.
Trunk is writable right now by members of the bugfix team only, that's so far Cameron (because he is the one supposed to fix networking) and me. If someone volunteers to fix any of the existing regressions, please let me know on irc/email, I'll include you into the bugfix team.
Thanks for understanding, and patience. My patience is over.
WBR, 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
You're probably all sick of me saying this (as I am saying it), but IRC is the wrong place to make such announcements.
From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Gregor Schneider Sent: 28 November 2009 16:40 To: ReactOS Development List Subject: Re: [ros-dev] Trunk locked
Aleksey announced via IRC that trunk is open for commits again.
2009/11/28 Ged Murphy gedmurphy@gmail.com
I assume trunk is now unlocked?? There's been no mention of it but commits have restarted
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Aleksey Bragin Sent: 17 November 2009 21:35 To: ReactOS Development List Subject: [ros-dev] Trunk locked
Hello, the trunk of our SVN server has been locked to prevent even more regression from entering the tree.
So far, after more than 3 weeks after I filed the bug report and not including all previous time when people were complaining about rapps which can't download anything at all - either hangs or crashes, I see that now even PCNet network card is being recognized in my VMWare Workstation 6.5.
Trunk is writable right now by members of the bugfix team only, that's so far Cameron (because he is the one supposed to fix networking) and me. If someone volunteers to fix any of the existing regressions, please let me know on irc/email, I'll include you into the bugfix team.
Thanks for understanding, and patience. My patience is over.
WBR, 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
Why the heck was the trunk even locked in the first place???
On Sat, Nov 28, 2009 at 11:06 AM, Ged Murphy gedmurphy@gmail.com wrote:
You’re probably all sick of me saying this (as I am saying it), but IRC is the wrong place to make such announcements.
*From:* ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] *On Behalf Of *Gregor Schneider *Sent:* 28 November 2009 16:40 *To:* ReactOS Development List *Subject:* Re: [ros-dev] Trunk locked
Aleksey announced via IRC that trunk is open for commits again.
2009/11/28 Ged Murphy gedmurphy@gmail.com
I assume trunk is now unlocked?? There's been no mention of it but commits have restarted
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Aleksey Bragin Sent: 17 November 2009 21:35 To: ReactOS Development List Subject: [ros-dev] Trunk locked
Hello,the trunk of our SVN server has been locked to prevent even more regression from entering the tree.
So far, after more than 3 weeks after I filed the bug report and not including all previous time when people were complaining about rapps which can't download anything at all - either hangs or crashes, I see that now even PCNet network card is being recognized in my VMWare Workstation 6.5.
Trunk is writable right now by members of the bugfix team only, that's so far Cameron (because he is the one supposed to fix networking) and me. If someone volunteers to fix any of the existing regressions, please let me know on irc/email, I'll include you into the bugfix team.
Thanks for understanding, and patience. My patience is over.
WBR, 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
To keep people from committing new changes that might break things. This is common practice before a release and has been done for at least the last year or so.
On Sat, Nov 28, 2009 at 11:48 AM, Sir Gallantmon ngompa13@gmail.com wrote:
Why the heck was the trunk even locked in the first place???
On Sat, Nov 28, 2009 at 11:06 AM, Ged Murphy gedmurphy@gmail.com wrote:
You’re probably all sick of me saying this (as I am saying it), but IRC is the wrong place to make such announcements.
*From:* ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] *On Behalf Of *Gregor Schneider *Sent:* 28 November 2009 16:40 *To:* ReactOS Development List *Subject:* Re: [ros-dev] Trunk locked
Aleksey announced via IRC that trunk is open for commits again.
2009/11/28 Ged Murphy gedmurphy@gmail.com
I assume trunk is now unlocked?? There's been no mention of it but commits have restarted
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Aleksey Bragin Sent: 17 November 2009 21:35 To: ReactOS Development List Subject: [ros-dev] Trunk locked
Hello,the trunk of our SVN server has been locked to prevent even more regression from entering the tree.
So far, after more than 3 weeks after I filed the bug report and not including all previous time when people were complaining about rapps which can't download anything at all - either hangs or crashes, I see that now even PCNet network card is being recognized in my VMWare Workstation 6.5.
Trunk is writable right now by members of the bugfix team only, that's so far Cameron (because he is the one supposed to fix networking) and me. If someone volunteers to fix any of the existing regressions, please let me know on irc/email, I'll include you into the bugfix team.
Thanks for understanding, and patience. My patience is over.
WBR, 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 mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Zachary Gorden wrote:
This is common practice before a release and has been done for at least the last year or so.
You make it sound like locking the whole trunk and making the majority of developers unable to work properly is a state we want to keep. Of course, this has mostly been done due to having no alternatives when using Subversion and our urgent need to fix these blockers. But still, it's generally the worst possible action I can think of when it comes to collaborating on Open-Source projects...
... which raises the question about switching to a distributed version control system for me again.
While Subversion has proven to be a viable solution for most of our needs, we still have to cope with its drawbacks from time to time. The major ones I can think of include:
* Build breakages in trunk prevent other developers from working.
Although some devs might have already get used to occasional build breaks, this could become a bigger problem when, for example, two developers constantly commit to a common component and update their working copies afterwards. They would immediately be forced to stop their work and wait for a fix, when a build break occurs, even if it's lying in a completely different component.
With Git or Mercurial, we could make wholly different workflows possible here. A better one might be that each developer only works on their own branches (which can be local and/or remote). Optionally, two or more developers working on the same component could also commit to a common branch, but still independent of the trunk or master branch. If one needs stuff from a different branch, he can easily merge single commits or fetch all changes from a branch.
Though SVN of course also provides branches, merging is far away from being a transparent and trivial task there. I guess that the devs, who often deal with our SVN branches, can confirm this. Git or Mercurial solve this task way better.
* Not all commits in trunk are well-tested and easily make it unstable.
The recent locking of trunk again showed that it's still a place where every trusted dev can, roughly speaking, commit whatever he wants. It should be obvious that this leads to unexpected problems from time to time. Many people might also well remember the GL case, when the drastic action of limiting one developer's SVN write access to branches was done to prevent him from committing possibly problematic stuff to trunk.
Using the branch workflow as described above would circumvent both problems and even make trunk an unattractive place to work on. If people have their own branches, where they can do everything they want, to prepare a big change (e.g. that network locking rewrite), nobody should ever need to work directly on trunk again. We would just need to establish new rules or methods to get commits from the branches into the trunk/master branch. Maybe a combination of automatic and manual testing (depending on the situation) can help us here.
Such problems will turn out to be more severe with the raising number of developers.
While this topic has already been partly discussed last year, the comfortable Windows support (= TortoiseSVN-like shell extensions) for both Git and Mercurial was still in very early stages of development at that time. This situation has improved much in the meantime. TortoiseGit and TortoiseHg should both provide most of the functions we need.
The differences between Git&TortoiseGit and Mercurial&TortoiseHg lie more in the general concepts.
As Git was designed with Unix principles in mind, it shares its one-tool-for-every-task approach. This way, it includes over 100 individual tools today to somehow solve every task and workflow. The official version also does not support Windows, but as msysgit and TortoiseGit exist today, this should be negligible. TortoiseGit is directly based on the TortoiseSVN source, so you should find it pretty easy to use.
Mercurial was designed with more usability and interoperability in mind, so it's properly supported under all major platforms. Compared to Git, it only supports the most common commands. On the other hand, its TortoiseHg was designed the same way, meaning that it's a GTK application targeted to run under several platforms as well. Therefore the user interface is quite different to that of TortoiseSVN.
After this rather long mail, I hope that we can eventually come to a conclusion about which distributed version control system to choose. Our existing Git mirror should be suitable for evaluating Git and I'm also doing a local import of the SVN repository into Mercurial right now (yes, it seems to work this time).
By the way, we can still maintain a SVN backend for the trunk/master branch afterwards, so that people may still read the repository the same way as they have done before.
Best regards,
Colin
On Sat, Nov 28, 2009 at 9:08 PM, Colin Finck mail@colinfinck.de wrote:
Zachary Gorden wrote:
This is common practice before a release and has been done for at least the last year or so.
You make it sound like locking the whole trunk and making the majority of developers unable to work properly is a state we want to keep. Of course, this has mostly been done due to having no alternatives when using Subversion and our urgent need to fix these blockers. But still, it's generally the worst possible action I can think of when it comes to collaborating on Open-Source projects...
... which raises the question about switching to a distributed version control system for me again.
While Subversion has proven to be a viable solution for most of our needs, we still have to cope with its drawbacks from time to time. The major ones I can think of include:
Build breakages in trunk prevent other developers from working.
Although some devs might have already get used to occasional build breaks, this could become a bigger problem when, for example, two developers constantly commit to a common component and update their working copies afterwards. They would immediately be forced to stop their work and wait for a fix, when a build break occurs, even if it's lying in a completely different component.
With Git or Mercurial, we could make wholly different workflows possible here. A better one might be that each developer only works on their own branches (which can be local and/or remote). Optionally, two or more developers working on the same component could also commit to a common branch, but still independent of the trunk or master branch. If one needs stuff from a different branch, he can easily merge single commits or fetch all changes from a branch.
Though SVN of course also provides branches, merging is far away from being a transparent and trivial task there. I guess that the devs, who often deal with our SVN branches, can confirm this. Git or Mercurial solve this task way better.
Not all commits in trunk are well-tested and easily make it unstable.
The recent locking of trunk again showed that it's still a place where every trusted dev can, roughly speaking, commit whatever he wants. It should be obvious that this leads to unexpected problems from time to time. Many people might also well remember the GL case, when the drastic action of limiting one developer's SVN write access to branches was done to prevent him from committing possibly problematic stuff to trunk.
Using the branch workflow as described above would circumvent both problems and even make trunk an unattractive place to work on. If people have their own branches, where they can do everything they want, to prepare a big change (e.g. that network locking rewrite), nobody should ever need to work directly on trunk again. We would just need to establish new rules or methods to get commits from the branches into the trunk/master branch. Maybe a combination of automatic and manual testing (depending on the situation) can help us here.
Such problems will turn out to be more severe with the raising number of developers.
While this topic has already been partly discussed last year, the comfortable Windows support (= TortoiseSVN-like shell extensions) for both Git and Mercurial was still in very early stages of development at that time. This situation has improved much in the meantime. TortoiseGit and TortoiseHg should both provide most of the functions we need.
The differences between Git&TortoiseGit and Mercurial&TortoiseHg lie more in the general concepts.
As Git was designed with Unix principles in mind, it shares its one-tool-for-every-task approach. This way, it includes over 100 individual tools today to somehow solve every task and workflow. The official version also does not support Windows, but as msysgit and TortoiseGit exist today, this should be negligible. TortoiseGit is directly based on the TortoiseSVN source, so you should find it pretty easy to use.
Mercurial was designed with more usability and interoperability in mind, so it's properly supported under all major platforms. Compared to Git, it only supports the most common commands. On the other hand, its TortoiseHg was designed the same way, meaning that it's a GTK application targeted to run under several platforms as well. Therefore the user interface is quite different to that of TortoiseSVN.
After this rather long mail, I hope that we can eventually come to a conclusion about which distributed version control system to choose. Our existing Git mirror should be suitable for evaluating Git and I'm also doing a local import of the SVN repository into Mercurial right now (yes, it seems to work this time).
By the way, we can still maintain a SVN backend for the trunk/master branch afterwards, so that people may still read the repository the same way as they have done before.
Best regards,
Colin
I have always found msysgit to be unusually slow in handling checkouts/branching. Of course, given what MSYS really is, that really isn't a surprise to me (MSYS is a fork of a really old version of Cygwin, 1.3.3 I believe).
And while TortoiseGit is similar to TortoiseSVN, my experience with it has led me to believe it is slower than its SVN counterpart.
TortoiseHG does work, but overall, I don't like using shell extensions, and I haven't really used TortoiseHG recently since I got my new x64 Windows desktop computer. It seems okay, but it looks sort of ugly on Vista and higher thanks to the fact that GTK+ doesn't really render widgets on that platform very well.
Mercurial itself, though, is very pleasant to use. I use it all the time for my projects, and I feel that it would work well for ReactOS.
Hi,
I worked with TortoiseHg some time, I thought I could get used to it, but to no avail.
From my experience, I can only say that almost *everything* is non
trivial or doesn't work Apart from the shitty interface. I just tested the latest version again, it's completely unintuitive, and merging gave me even more conflicts than I would have expected with SVN.
My experience with using a branch with TSVN is that there's no problem. Even merging hundreds of revisions from trunk to the branch worked quite well with rarely any conflicts and it's done with a few clicks.
We don't need a different versioning system, we need a better source organisation. Independency of modules. Independency from the tools/sdk. That would also help with working on branches.
Just my 2 cents, Timo
I have to agree that the DVCS I tried (Hg and Git) all are quite... let's be honest: crappy (on Windows). I also tried to work on my own branches using git, I tried to do Wine syncs using a special Wine branch in a local git repo. All failed, everything was non trivial, and required a lot more work.
Subversion just works. Also, a git mirror is provided, so that when the trunk is locked for some reason, devs still have an option to: a) create their own branch in SVN, work in a branch, do anything they like b) create their own git fork, work in it, publish it, get famous/ blamed, anything they like
There are no restrictions really, especially having in mind that our SVN repo is already clonable by everyone, so everyone can have 10+ years of ReactOS hard work on a DVD disk.
I don't really see any need to switch our VCS to anything else.
WBR, Aleksey Bragin.
On Nov 29, 2009, at 1:49 PM, Timo Kreuzer wrote:
Hi,
I worked with TortoiseHg some time, I thought I could get used to it, but to no avail. From my experience, I can only say that almost *everything* is non trivial or doesn't work Apart from the shitty interface. I just tested the latest version again, it's completely unintuitive, and merging gave me even more conflicts than I would have expected with SVN.
My experience with using a branch with TSVN is that there's no problem. Even merging hundreds of revisions from trunk to the branch worked quite well with rarely any conflicts and it's done with a few clicks.
We don't need a different versioning system, we need a better source organisation. Independency of modules. Independency from the tools/ sdk. That would also help with working on branches.
Just my 2 cents, Timo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I had similar ideas recently. Working with tortoisegit on Wine for one of my patches felt weird first, but being able to commit changes locally and is quite powerful. At first I wondered what it could be good for, but the locked trunk showed me just that.
Keeping a history of patches which include commit messages and which even might work separated from others is awesome. Concerning the tortoiseGit GUI I have to agree that it's not as intuitive as the SVN counterpart, but one always needs a certain time to get used to new tools.
Big problem with those systems is the final checkin into the master branch. The one person managing patch mails and applying all patches has the most boring job ever. Furthermore this person has to have A LOT of time. No clue which other concepts are supported by those two tools.
I remember seeing a GIT presentation by Torvalds at some Google event where he introduced the Linux kernel "team" organisation. Several maintainers who get patches for their area and himself being the bigboss just copying their repos and not doing any patches at all. When a checkout from a maintainer failed for him he just dropped it and took anotherone.
Pretty cool tree like structure sounds possible here, but the concept of maintainers or rather development areas/teams doesn't seem to work for ReactOS. From the time when I started following ReactOS I proposed it severeal times, but noone seems to be interested.
Gregor
2009/11/29 Colin Finck mail@colinfinck.de
Zachary Gorden wrote:
This is common practice before a release and has been done for at least the last year or so.
You make it sound like locking the whole trunk and making the majority of developers unable to work properly is a state we want to keep. Of course, this has mostly been done due to having no alternatives when using Subversion and our urgent need to fix these blockers. But still, it's generally the worst possible action I can think of when it comes to collaborating on Open-Source projects...
... which raises the question about switching to a distributed version control system for me again.
While Subversion has proven to be a viable solution for most of our needs, we still have to cope with its drawbacks from time to time. The major ones I can think of include:
Build breakages in trunk prevent other developers from working.
Although some devs might have already get used to occasional build breaks, this could become a bigger problem when, for example, two developers constantly commit to a common component and update their working copies afterwards. They would immediately be forced to stop their work and wait for a fix, when a build break occurs, even if it's lying in a completely different component.
With Git or Mercurial, we could make wholly different workflows possible here. A better one might be that each developer only works on their own branches (which can be local and/or remote). Optionally, two or more developers working on the same component could also commit to a common branch, but still independent of the trunk or master branch. If one needs stuff from a different branch, he can easily merge single commits or fetch all changes from a branch.
Though SVN of course also provides branches, merging is far away from being a transparent and trivial task there. I guess that the devs, who often deal with our SVN branches, can confirm this. Git or Mercurial solve this task way better.
Not all commits in trunk are well-tested and easily make it unstable.
The recent locking of trunk again showed that it's still a place where every trusted dev can, roughly speaking, commit whatever he wants. It should be obvious that this leads to unexpected problems from time to time. Many people might also well remember the GL case, when the drastic action of limiting one developer's SVN write access to branches was done to prevent him from committing possibly problematic stuff to trunk.
Using the branch workflow as described above would circumvent both problems and even make trunk an unattractive place to work on. If people have their own branches, where they can do everything they want, to prepare a big change (e.g. that network locking rewrite), nobody should ever need to work directly on trunk again. We would just need to establish new rules or methods to get commits from the branches into the trunk/master branch. Maybe a combination of automatic and manual testing (depending on the situation) can help us here.
Such problems will turn out to be more severe with the raising number of developers.
While this topic has already been partly discussed last year, the comfortable Windows support (= TortoiseSVN-like shell extensions) for both Git and Mercurial was still in very early stages of development at that time. This situation has improved much in the meantime. TortoiseGit and TortoiseHg should both provide most of the functions we need.
The differences between Git&TortoiseGit and Mercurial&TortoiseHg lie more in the general concepts.
As Git was designed with Unix principles in mind, it shares its one-tool-for-every-task approach. This way, it includes over 100 individual tools today to somehow solve every task and workflow. The official version also does not support Windows, but as msysgit and TortoiseGit exist today, this should be negligible. TortoiseGit is directly based on the TortoiseSVN source, so you should find it pretty easy to use.
Mercurial was designed with more usability and interoperability in mind, so it's properly supported under all major platforms. Compared to Git, it only supports the most common commands. On the other hand, its TortoiseHg was designed the same way, meaning that it's a GTK application targeted to run under several platforms as well. Therefore the user interface is quite different to that of TortoiseSVN.
After this rather long mail, I hope that we can eventually come to a conclusion about which distributed version control system to choose. Our existing Git mirror should be suitable for evaluating Git and I'm also doing a local import of the SVN repository into Mercurial right now (yes, it seems to work this time).
By the way, we can still maintain a SVN backend for the trunk/master branch afterwards, so that people may still read the repository the same way as they have done before.
Best regards,
Colin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
You all are so impatient that I couldn't even have had supper between I unlocked trunk and the moment of posting about this to the mailing list :)
Now, trunk is unlocked since last two major problems are solved: 1. Network is unegressed by reverting oskit locking rewrite. Despite it's a good thing, unfortunately it's buggy and finding this bug turned out to be non-trivial. 2. Uniata still needs higher delays (in VirtualBox), so we are going to fine tune it with Olaf or Gabriel who experience this problem and commit the result in trunk / merge to 0.3.11 branch.
0.3.11 release has been branched now, it's going to include a few more merges from trunk (the above), then a prerelease iso is going to be prepared by Colin and tested by Victor Martinez & co, after that we should release.
All of this (most of it) should (must) happen before ~Wednesday of next week, because I may not be available on wednesday and thursday. Don't forget changelogs!
WBR, Aleksey Bragin.
On Nov 28, 2009, at 8:06 PM, Ged Murphy wrote:
You’re probably all sick of me saying this (as I am saying it), but IRC is the wrong place to make such announcements.
From: ros-dev-bounces@reactos.org [mailto:ros-dev- bounces@reactos.org] On Behalf Of Gregor Schneider Sent: 28 November 2009 16:40 To: ReactOS Development List Subject: Re: [ros-dev] Trunk locked
Aleksey announced via IRC that trunk is open for commits again.
2009/11/28 Ged Murphy gedmurphy@gmail.com
I assume trunk is now unlocked?? There's been no mention of it but commits have restarted
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev- bounces@reactos.org] On Behalf Of Aleksey Bragin Sent: 17 November 2009 21:35 To: ReactOS Development List Subject: [ros-dev] Trunk locked
Hello,the trunk of our SVN server has been locked to prevent even more regression from entering the tree.
So far, after more than 3 weeks after I filed the bug report and not including all previous time when people were complaining about rapps which can't download anything at all - either hangs or crashes, I see that now even PCNet network card is being recognized in my VMWare Workstation 6.5.
Trunk is writable right now by members of the bugfix team only, that's so far Cameron (because he is the one supposed to fix networking) and me. If someone volunteers to fix any of the existing regressions, please let me know on irc/email, I'll include you into the bugfix team.
Thanks for understanding, and patience. My patience is over.
WBR, Aleksey Bragin.
Hi, I've tested FF 3.5 and Seamonkey 2.0 with the patch from Bug 4100, other than ugly alphanumeric issues, it works and should be added to head and merged into 0.3.11.
Thanks, James
Ref: http://www.reactos.org/bugzilla/show_bug.cgi?id=4100
On Sat, Nov 28, 2009 at 1:54 PM, Aleksey Bragin aleksey@reactos.org wrote:
You all are so impatient that I couldn't even have had supper between I unlocked trunk and the moment of posting about this to the mailing list :) Now, trunk is unlocked since last two major problems are solved:
- Network is unegressed by reverting oskit locking rewrite. Despite it's a
good thing, unfortunately it's buggy and finding this bug turned out to be non-trivial. 2. Uniata still needs higher delays (in VirtualBox), so we are going to fine tune it with Olaf or Gabriel who experience this problem and commit the result in trunk / merge to 0.3.11 branch. 0.3.11 release has been branched now, it's going to include a few more merges from trunk (the above), then a prerelease iso is going to be prepared by Colin and tested by Victor Martinez & co, after that we should release. All of this (most of it) should (must) happen before ~Wednesday of next week, because I may not be available on wednesday and thursday. Don't forget changelogs!
WBR, Aleksey Bragin.