Axis-dev'ers:
Any commentary on this? Votes?
--Glen
Glen Daniels wrote:
Hi Folks:
Sanjiva Weerawarana wrote:
That's a **itload of work for the RM to have to do this for each and
every fix going into the trunk. I don't see this as a scalable
proposition.
I agree that the RM shouldn't be the one to do the merge - the person
who makes the fix should be responsible for merging. That way the
person most familiar with the code does the work on both branches.
However, the RM might want to be the "gateway" for permission to do the
merge. We can start out with people just using their discretion as to
whether or not to merge, and if that becomes problematic we can throttle
it down via the RM.
So the current proposal as I see it is:
1. RM goes through JIRA and sets "fix for" to point to both "NIGHTLY"
and the new branched release number for the fixes that are still
targeted for the release after branch is cut.
2. Asignee/coder fixes JIRA issues or makes other changes *on the
trunk*. If JIRA is set to branched release as target, or upon coder's
discretion, they then merge the fix over to the release branch.
3. When Asignee resolves JIRA, they confirm it's been fixed in both
branches, if appropriate.
This way the only times we make fixes directly on the release branch are
as follows:
* For release-specific fixes (references to version number, taking out
SNAPSHOTs, release notes, etc)
* For post-release bug fixes - IF the trunk has moved on in an
incompatible way (if the bug hasn't been fixed on trunk it should as per
usual be fixed there first and merged)
Otherwise, everything that goes into the release branch should be a
merge over from the trunk.
Sound reasonable?
--Glen
Davanum Srinivas wrote:
Yes, trunk first and then branch later seems the right thing to do.
The RM can choose which fixes go into branch.
thanks,
-- dims
On 4/14/07, Glen Daniels <[EMAIL PROTECTED]> wrote:
Hi Afkham!
Afkham Azeez wrote:
> Do the fixes in the branch need to be necessarily carried out on the
> trunk as well. I'm asking this since we'd be merging the code in the
> branch with the trunk eventually.
The problem is that the longer we go without merging, the more
likely it
is we'll have conflicts, or heaven forbid fix the same problem twice
(if
someone working on trunk hasn't noticed that the bug has been fixed on
the branch, say). It also becomes much more of a pain to have one
person do a giant merge where they don't necessarily have intimate
knowledge of all the conflicts, as opposed to the people making the
individual fixes simply merge them over when they're fresh in the mind.
Also, we always want the trunk to carry the latest fixes and
improvements so people can move forward there without having to wait
for
a big post-release merge to pick up fixes. In fact, I think it likely
makes the most sense to fix bugs on the trunk *first*, and then merge
those changes over to the release branch, rather than the other way
around.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
