RE: [ros-dev] Pending 0.2.7 RC2

[Murphy, Ged (Bolton)]

Robert k. [e-mail] 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
[e-mail] 
mailto:[e-mail] 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

[Casper Hornstrup]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 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. [e-mail] 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

[Alex Ionescu]

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