incubator-droids-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eugen Paraschiv <>
Subject Re: Moving some minor issues from 0.0.2 to 0.0.1 to get them committed before the release?
Date Mon, 07 Mar 2011 18:50:54 GMT
This is the list of issues in 0.0.2 that I think can be moved forward to
0.0.1 and committed before the release:
There are a few more that I have not attached patches yet, but these are the
first 3.
Can someone look at them in order to be able to move them to 0.0.1?

On Sat, Mar 5, 2011 at 6:16 AM, Richard Frovarp <> wrote:

> On 3/3/2011 1:53 AM, Chapuis Bertil wrote:
>> You are probably right. I see the stable branch more as a snapshot of the
>> trunk, and the merges should mainly be done from trunk to stable, however I
>> don't know how time consuming it is to perform these merges. The point is
>> that the release should not be blocking. Do you think we can find another
>> alternative?
> Yes, the merges would go from trunk to stable. But if they are being done
> all of the time, there isn't much gain, it's just an extra step. If they
> aren't being done all of the time, it becomes a lot more work.
> The amount of time that a release would really be blocking should be quite
> minimal, and for a low volume project it shouldn't be that big of a deal.
> The biggest blocking issue here is that we're trying to figure out how to do
> a release, and are waiting for that before calling a vote. In fact, all we
> would really vote on is the code denoted by a revision number in SVN.
> Identify that revision number, tag it as an RC, and let the trunk continue
> on development. If necessary you branch the RC to create new RCs and merge
> any bug fixes into trunk. A project like this probably isn't going to go
> through many RCs for a release.
> I am personally of the belief that I would much rather rarely bring patches
> forward from an RC to trunk than the more frequent path of trunk to stable.
> I'm not opposed to the idea of stable, I just think it's more work. However,
> if there are going to be frequent releases, or long release processes,
> stable might prove to be very helpful.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message