Robert k. rob@koepferl.de wrote:
Hi,
since there was just one change to the branch 0.2.7 I did not yet publish the RC2 version. I decided to wait until monday to publishing RC2.
It seems RC1 is being forgotten about.
I know this has been discussed a few times before, but can we not look into the possibility of branching off for releases in a different way.
Although it means changing SVN URL for HEAD, is it not better to follow the path of branching a new HEAD and freezing the current address for the next release. This may help people to remember to concentrate more on bugfixes for the upcoming release and not on implementing new features to HEAD.
I'd hate to see another buggy release like 0.2.6, which was possibly a regression on 0.2.5
Ged.
************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster@exideuk.co.uk mailto:postmaster@exideuk.co.uk and then delete this message.
Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com
-----Original Message----- From: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] On Behalf Of Murphy, Ged (Bolton) Sent: 20. juli 2005 16:47 To: 'ReactOS Development List' Subject: RE: [ros-dev] Pending 0.2.7 RC2
Robert k. rob@koepferl.de wrote:
Hi,
since there was just one change to the branch 0.2.7 I did not yet publish the RC2 version. I decided to wait until monday to publishing RC2.
It seems RC1 is being forgotten about.
I know this has been discussed a few times before, but can we not look into the possibility of branching off for releases in a different way.
Although it means changing SVN URL for HEAD, is it not better to follow the path of branching a new HEAD and freezing the current address for the next release. This may help people to remember to concentrate more on bugfixes for the upcoming release and not on implementing new features to HEAD.
I'd hate to see another buggy release like 0.2.6, which was possibly a regression on 0.2.5
Ged.
You are confusing HEAD with trunk. Trunk is the main development branch. HEAD is the youngest (highest) revision in the repository. HEAD is not tied to any particular branch.
If you run a company where you pay your developers their $70K/year to work for you, then your approach might be better. For ReactOS however, it is not better since forcing people to do work is not something we do around here. You might find that developers just don't contribute anything at all during the freeze if you make trunk read-only. You also assume that anyone can fix any bug in ReactOS. Were I to track down and fix a bug in say win32k today, I could probably spend most of my day doing that. If I were to track down and fix a bug in rbuild today, I could probably do it much faster.
Casper
Casper Hornstrup wrote:
If you run a company where you pay your developers their $70K/year to work for you, then your approach might be better. For ReactOS however, it is not better since forcing people to do work is not something we do around here.
I believe Ged used the term "remember to concentrate more on bugfixes" and not "force people". Those are very different terms...From my discussions, I believe a majority of developers feel that there shoudl be more concentration towards bug fixes during releases instead of new implementations.
You might find that developers just don't contribute anything at all during the freeze if you make trunk read-only.
Making trunk read-only, on the other head, is not a good idea and might hinder some developers if they really wanted to implement something new/unrelated to a bug fix, so I don't agree with it either.
I believe the normal established methods of "concentration bug fixes" should work well. That is, don't ship until blocking bugs are fixed.
Best regards, Alex Ionescu