I like the practice of putting the revision number for the check-in in
the bug report when you close the issue out. For 3.1 changes going
forward we would expect to see two revision numbers listed - one for the
branch and one for the trunk integration.
As Sathyan mentioned and I'll reiterate again we will announce when the
trunk is open for general (non-3.1) changes. I anticipate this would be
sometime next week.
We ran into a problem with the RC build last night. The problem is
being fixed and we hope to promote this afternoon.
Chris
On 01/28/11 09:08, Sathyan Catari wrote:
> One way to make sure that required checkins are happening in both
> branch and trunk,
> is to mandate that commit message along with revision #s should be added
> in the
> bug system, when the submitter marks the bug as fixed/resolved. I think
> two more questions
> should be added to the Change control
> doc(http://wikis.sun.com/display/GlassFish/3.1ChangeControl).
>
> -Commit message with version# for Branch.
> -Commit message with version# for Trunk.
>
> If the fix doesn't apply to the trunk(ex package naming/versions), then
> the submitter could
> answer N/A to message for trunk.
>
> Given the controlled changes expected in 3.1 at this point of time, I
> think we can defer finding
> ways to automate this to the next release.
>
> Thanks
> Sathyan
>
>
>
>
> On 1/28/11 8:57 AM, Tom Mueller wrote:
>> I haven't heard any announcement that the trunk is open for
>> 3.2-related work yet.
>>
>> Every change for 3.1 now has to be committed twice, once in the trunk
>> and once in the 3.1 branch. Some people choose to implement and commit
>> first in the branch and forward port to the trunk. Others choose to
>> implement and commit first in the trunk and backport to the branch.
>> Without a good process, some doing the former might implement only in
>> the branch and forget/neglect to forward port into the trunk, which
>> eventually will result in regressions in 3.2. That's why I recommend
>> doing the latter: implement and commit first on the trunk and
>> backport. I wish we could get sustaining to do that too, but that
>> would probably add too much to sustaining release development cycles.
>>
>> Tom
>>
>>
>> On 1/28/2011 10:45 AM, Jason Lee wrote:
>>> I'm confused a bit, I think. Is the branch for 3.1 final and the
>>> trunk open for 3.2-related work?
>>>
>>> On 1/28/11 9:46 AM, Tom Mueller wrote:
>>>> Can we have the process be to always implement everything in the
>>>> trunk first, and then backport to the 3.1 branch if necessary?
>>>> Tom
>>>>
>>>> On 1/28/2011 3:59 AM, Sahoo wrote:
>>>>> On Friday 28 January 2011 06:31 AM, Chris Kasso wrote:
>>>>>> Please integrate all 3.1 changes into the new 3.1 branch*and*
>>>>>> the existing trunk.
>>>>>>
>>>>> Is there a process in place for ensuring that all check-ins to
>>>>> 3.1-branch are eventually forward ported to trunk?
>>>
>>>
>>> --
>>> Jason Lee
>>> Senior Member of Technical Staff
>>> GlassFish REST API / Administration Console
>>>
>>> Oracle Corporation
>>> Phone +1 405-216-3193
>>> Bloghttp://blogs.steeplesoft.com