openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@gmail.com>
Subject Re: svn commit: r569253 - in /openjpa/branches/1.0.0/openjpa-kernel/src/main: java/org/apache/openjpa/enhance/PCEnhancer.java resources/org/apache/openjpa/enhance/localizer.properties
Date Fri, 24 Aug 2007 19:42:31 GMT
> Straw proposal:  we never merge from any branch to the trunk.

The implication of this is that any fixes that are made on a branch
only need to be manually mirrored back down to trunk.

I'm ok with that, but I think that it is very important that we do
something to ensure that that happens. Otherwise, we'll have bugfixes
in branches but not in trunk.

Also, the rumor is that svn 2 will maintain merge history, which will
make inter-branch merging trivial, so we should be sure to remember
that any rules that we make to simplify our lives with svn 1 are not
written in stone.

-Patrick

On 8/24/07, Craig L Russell <Craig.Russell@sun.com> wrote:
>
> On Aug 24, 2007, at 12:27 PM, Patrick Linskey wrote:
>
> >> Since we will have active development on the trunk and on the 1.0
> >> branch, the release manager for the 1.0.1 release will need to do the
> >> work of merging desired fixes from the trunk back to the branch.
> >
> > I think that we should take a different approach: the people who want
> > particular fixes that were put into trunk should be responsible for
> > merging them into the 1.0 branch, and the release manager should be
> > responsible for merging any work that was done only in the 1.0 branch
> > back into trunk.
> >
> > Merging is a bit of a pain in svn currently, since we need to keep
> > track of when a merge was last made. We might want to write down some
> > procedures for the different types of merges that we expect and what
> > not to do. For example, I think that it's bad to "merge" from trunk to
> > 1.0 by just copying the changes from one branch to another, because
> > then svn will detect a conflict when merging back down.
>
> We should have a policy on merging that resolves this.
>
> Straw proposal:  we never merge from any branch to the trunk.
>
> Craig
> >
> > -Patrick
> >
> > On 8/24/07, Craig L Russell <Craig.Russell@sun.com> wrote:
> >>
> >> On Aug 24, 2007, at 10:11 AM, Patrick Linskey wrote:
> >>
> >>>> "1.0.0". As we discussed before, we don't have a "1.0" branch
> >>>> because
> >>>> we have not yet discussed a "1.0" roadmap.
> >>>
> >>> Let's put this bit to rest. I have been assuming per email
> >>> discussions
> >>> from last year and general best practices that we will have patch
> >>> releases that contain nothing but bugfixes. Given that, the 1.0.x
> >>> roadmap is by definition constrained to patches. A roadmap for 1.1
> >>> would be useful, but is totally separate from any need for a 1.0.x
> >>> branch.
> >>
> >> +1
> >>>
> >>>> The current "1.0.0" branch is *only* for changes that are to go
> >>>> into
> >>>> the 1.0.0 release. Full stop.
> >>>
> >>> ... and I think that this is unnecessary. I do not believe that the
> >>> concepts that you discussed are at all orthogonal to general 1.0.x
> >>> maintenance. It is just a pathological special case in which
> >>> there has
> >>> not yet been a 1.0.0 release, but is otherwise identical to the
> >>> requirements for a 1.0.1 release or a 1.0.2 release.
> >>>
> >>>> It sounds like there is an *orthogonal* concern that we do not yet
> >>>> have a branch on which changes destined for 1.0.x should go. That's
> >>>> an understandable concern, but it has nothing to do with the very
> >>>> specific and short-lived purpose of the branch that is called
> >>>> "1.0.0".
> >>>
> >>> I think that having a branch for this specific and short-lived
> >>> purpose
> >>> is a Bad Idea. I see no reason why we should not just create a
> >>> branch
> >>> for a release as described in my last two emails, rather than
> >>> creating
> >>> a branch, throwing it away, and hopefully properly re-creating a
> >>> branch with the same contents.
> >>>
> >>>> I'm perfectly fine with making a "1.0" branch on which we will
> >>>> commit
> >>>> changes destined for 1.0.x releases. Ideally, this would have been
> >>>> done before we branched for "1.0.0", so that we could have branched
> >>>> from the "1.0" branch, but I don't know if subversion actually
> >>>> cares
> >>>> about the hierarchy of branches when it comes to merging.
> >>>
> >>> Indeed, I think that ideally, it should have been done *instead* of
> >>> creating the "1.0.0" branch.
> >>
> >> +1
> >>>
> >>>> So how about we do the following?
> >>>>
> >>>> 1. Immediately create a branch off of trunk called "1.0".
> >>>> Maintenance
> >>>> changes destined for 1.0.1 will be made on that branch.
> >>>> 2. Once the 1.0.0 release is approved and published, merge the
> >>>> changes from the "1.0.0" branch into the "1.0" branch and tag the
> >>>> released bits in the "1.0.0" branch as "1.0.0", then delete the
> >>>> "1.0.0" branch.
> >>>> 3. In the future, cut the "1.0.1" branch off of the "1.0" branch.
> >>>
> >>> I think that we should do the following:
> >>>
> >>> 1. rename the "1.0.0" branch to "1.0". Maintenance changes destined
> >>> fro 1.0.1 will be made on that branch.
> >>
> >> +1
> >>>
> >>> 2. Once the 1.0.0 release is approved and published, create a 1.0.0
> >>> tag, and do not delete the 1.0 branch.
> >>
> >> +1
> >>
> >> Just note that the terms tag and branch have no meaning in svn (I
> >> think they actually did mean something in cvs). In svn, you just name
> >> a revision of a module and svn remembers it using copy-on-write. So
> >> there's no cost to making a tag or a branch. As a group we can decide
> >> that a branch continues to have development on it and a tag is read-
> >> only.
> >>>
> >>> 3. In the future, do not cut a "1.0.1" branch at all. Instead, when
> >>> the time comes for 1.0.1 work, do it directly from the 1.0 branch
> >>> (which, per my assertion above, contains only bugfixes, and so does
> >>> not risk tainting the branch), and create a tag from the branch.
> >>
> >> Once we agree on the naming we need to update http://
> >> cwiki.apache.org/
> >> confluence/display/openjpa/Releasing+OpenJPA
> >>
> >> Since we will have active development on the trunk and on the 1.0
> >> branch, the release manager for the 1.0.1 release will need to do the
> >> work of merging desired fixes from the trunk back to the branch.
> >>
> >> Craig
> >>>
> >>> I think that this simplifies and streamlines the process, and loses
> >>> none of the current source-isolation that we have in our
> >>> transient-branch strategy.
> >>>
> >>> -Patrick
> >>>
> >>> On 8/24/07, Marc Prud'hommeaux <mprudhom@apache.org> wrote:
> >>>>
> >>>> I think the point of having a release branch is so that:
> >>>>
> >>>> 1. Cosmetic/miscellaneous changes can be made in the release branch
> >>>> to fix problems with the candidate builds.
> >>>> 2. More importantly, other people can make changes on one of the
> >>>> parent branch(es) during the sometimes multi-week release voting
> >>>> process without messing up the release branch.
> >>>>
> >>>> The current "1.0.0" branch is *only* for changes that are to go
> >>>> into
> >>>> the 1.0.0 release. Full stop.
> >>>>
> >>>> It sounds like there is an *orthogonal* concern that we do not yet
> >>>> have a branch on which changes destined for 1.0.x should go. That's
> >>>> an understandable concern, but it has nothing to do with the very
> >>>> specific and short-lived purpose of the branch that is called
> >>>> "1.0.0". As we discussed before, we don't have a "1.0" branch
> >>>> because
> >>>> we have not yet discussed a "1.0" roadmap.
> >>>>
> >>>> I'm perfectly fine with making a "1.0" branch on which we will
> >>>> commit
> >>>> changes destined for 1.0.x releases. Ideally, this would have been
> >>>> done before we branched for "1.0.0", so that we could have branched
> >>>> from the "1.0" branch, but I don't know if subversion actually
> >>>> cares
> >>>> about the hierarchy of branches when it comes to merging.
> >>>>
> >>>> So how about we do the following?
> >>>>
> >>>> 1. Immediately create a branch off of trunk called "1.0".
> >>>> Maintenance
> >>>> changes destined for 1.0.1 will be made on that branch.
> >>>> 2. Once the 1.0.0 release is approved and published, merge the
> >>>> changes from the "1.0.0" branch into the "1.0" branch and tag the
> >>>> released bits in the "1.0.0" branch as "1.0.0", then delete the
> >>>> "1.0.0" branch.
> >>>> 3. In the future, cut the "1.0.1" branch off of the "1.0" branch.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Aug 24, 2007, at 12:23 PM, Patrick Linskey wrote:
> >>>>
> >>>>>> It seems like we should be able to accomplish that by renaming
> >>>>>> the
> >>>>>> 1.0.0branch to
> >>>>>> 1.0. When we're done with 1.0.0 we can create a new branch and
> >>>>>> tag
> >>>>>> with the
> >>>>>> correct name.
> >>>>>
> >>>>> I agree completely.
> >>>>>
> >>>>> I think that making the branch and then throwing it away and then
> >>>>> creating another branch with allegedly-identical contents sounds
> >>>>> error
> >>>>> prone and cumbersome.
> >>>>>
> >>>>> As I mentioned earlier, I think that we should change our
> >>>>> processes to
> >>>>> create a release branch for an x.y.0 release from wherever it is
> >>>>> that
> >>>>> that branch is being sourced (trunk, somewhere else, etc.), and
> >>>>> then
> >>>>> work on a release on that branch. Once the release is done, we
> >>>>> then
> >>>>> tag that moment in time, but keep the x.y release branch alive for
> >>>>> work that should go into x.y.1. When the time comes for the x.y.1
> >>>>> release, we then do not need to create one of these release
> >>>>> branches,
> >>>>> since the only work that's happening in the x.y branch should be
> >>>>> maintenance work anyways. We just work on the release in the
> >>>>> release
> >>>>> branch, get it done, and then tag it when it's ready.
> >>>>>
> >>>>> I think that our current model of making these transient
> >>>>> branches is
> >>>>> well-suited for a single-branch methodology. That worked well
> >>>>> while we
> >>>>> were working towards a 1.0.0 release, since we never planned to
> >>>>> have
> >>>>> hardening releases off of 0.9.7, for example. But now that we're
> >>>>> moving past 1.0.0, I think that it's important to have a branching
> >>>>> strategy in place that supports patch line maintenance.
> >>>>>
> >>>>> Thoughts?
> >>>>>
> >>>>> -Patrick
> >>>>>
> >>>>> On 8/24/07, Michael Dick <michael.d.dick@gmail.com> wrote:
> >>>>>> On 8/24/07, Patrick Linskey <plinskey@gmail.com> wrote:
> >>>>>>>
> >>>>>>> I agree with most of what Marc is saying. However, I strongly
> >>>>>>> feel
> >>>>>>> that we need to change how we're doing our branching strategy.
> >>>>>>> In my
> >>>>>>> opinion, creating these throwaway branches unnecessarily
> >>>>>>> complicates
> >>>>>>> the process of making a maintenance branch for a given release.
> >>>>>>
> >>>>>>
> >>>>>> +1. Marc (or any other release manager) shouldn't have to merge
> >>>>>> changes back
> >>>>>> into trunk.
> >>>>>>
> >>>>>> Can someone explain to me where we are going to do 1.0.1 work
in
> >>>>>> the
> >>>>>>> current process?
> >>>>>>
> >>>>>>
> >>>>>> Prior to our discussion in a different thread I thought that
> >>>>>> 1.0.1
> >>>>>> work
> >>>>>> would be done in the 1.0.0 branch that we're using now. Basically
> >>>>>> when we're
> >>>>>> done with 1.0.0 we would create a tag. Anything committed after
> >>>>>> that point
> >>>>>> would be part of 1.0.1 until we release it and create another
> >>>>>> tag.
> >>>>>>
> >>>>>> The new plan is to create a branch and call it 1.0. 1.0.0, 1.0.1,
> >>>>>> 1.0.2 etc
> >>>>>> are branches off of 1.0 (I think).
> >>>>>>
> >>>>>> It seems like we should be able to accomplish that by renaming
> >>>>>> the
> >>>>>> 1.0.0branch to
> >>>>>> 1.0. When we're done with 1.0.0 we can create a new branch and
> >>>>>> tag
> >>>>>> with the
> >>>>>> correct name.
> >>>>>>
> >>>>>> -Mike
> >>>>>>
> >>>>>> -Patrick
> >>>>>>>
> >>>>>>> On 8/24/07, Marc Prud'hommeaux <mprudhom@apache.org>
wrote:
> >>>>>>>> Kevin-
> >>>>>>>>
> >>>>>>>> Unless Patrick objects to the current (fourth) vote
on the
> >>>>>>>> 1.0.0
> >>>>>>>> artifact based on this commit, it won't make it into
the 1.0.0
> >>>>>>>> final
> >>>>>>>> release bits.
> >>>>>>>>
> >>>>>>>> Once 1.0.0 is released, I will tag the currently *released*
> >>>>>>>> source
> >>>>>>>> code in the 1.0.0 branch as "1.0.0", and then merge
the
> >>>>>>>> *latest*
> >>>>>>>> source code in the 1.0.0 branch back into the trunk,
so any
> >>>>>>>> additions
> >>>>>>>> to the 1.0.0 branch will certainly be merged back to
the trunk
> >>>>>>>> (although they will only be released in the 1.0.0 assembly
> >>>>>>>> if we
> >>>>>>>> happen to need to cut another release).
> >>>>>>>>
> >>>>>>>> I will document this process on the revised release
> >>>>>>>> instructions on
> >>>>>>>> the wiki once I get around to assembling them. We are
playing a
> >>>>>>>> little fast and loose with last-minute changes in what
should
> >>>>>>>> probably be a more solemn process, but since this is
the first
> >>>>>>>> major
> >>>>>>>> release as a TLP, I think we can make a few exceptions.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Aug 24, 2007, at 8:37 AM, Kevin Sutter wrote:
> >>>>>>>>
> >>>>>>>>> Patrick and Marc,
> >>>>>>>>> Help me understand our process here.  This commit
is
> >>>>>>>>> similar to
> >>>>>>>>> the
> >>>>>>>>> one I
> >>>>>>>>> did the other evening.  It was committed into the
1.0.0 branch
> >>>>>>>>> after the 4th
> >>>>>>>>> re-spin and [VOTE] was posted.  So, does this require
yet
> >>>>>>>>> another
> >>>>>>>>> respin?
> >>>>>>>>> If not, then what happens to these changes?  The
[VOTE] would
> >>>>>>>>> not
> >>>>>>>>> include
> >>>>>>>>> these changes.  So, would these changes automatically
become
> >>>>>>>>> part
> >>>>>>>>> of the
> >>>>>>>>> 1.0.1 snapshot release?
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Kevin
> >>>>>>>>>
> >>>>>>>>> On 8/24/07, pcl@apache.org <pcl@apache.org>
wrote:
> >>>>>>>>>>
> >>>>>>>>>> Author: pcl
> >>>>>>>>>> Date: Thu Aug 23 22:27:43 2007
> >>>>>>>>>> New Revision: 569253
> >>>>>>>>>>
> >>>>>>>>>> URL: http://svn.apache.org/viewvc?rev=569253&view=rev
> >>>>>>>>>> Log:
> >>>>>>>>>> Minor logging / exception handling improvements
> >>>>>>>>>>
> >>>>>>>>>> Modified:
> >>>>>>>>>>
> >>>>>>>>>>     openjpa/branches/1.0.0/openjpa-kernel/src/main/java/org/
> >>>>>>>>>> apache/
> >>>>>>>>>> openjpa/enhance/PCEnhancer.java
> >>>>>>>>>>     openjpa/branches/1.0.0/openjpa-kernel/src/main/resources/
> >>>>>>>>>> org/
> >>>>>>>>>> apache/openjpa/enhance/localizer.properties
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Modified:
> >>>>>>>>>> openjpa/branches/1.0.0/openjpa-kernel/src/main/java/org/
> >>>>>>>>>> apache/
> >>>>>>>>>> openjpa/enhance/PCEnhancer.java
> >>>>>>>>>> URL:
> >>>>>>>>>> http://svn.apache.org/viewvc/openjpa/branches/1.0.0/openjpa-
> >>>>>>>>>> kernel/
> >>>>>>>>>> src/main/java/org/apache/openjpa/enhance/PCEnhancer.java?
> >>>>>>>>>> rev=569253&r1=569252&r2=569253&view=diff
> >>>>>>>>>> =============================================================
> >>>>>>>>>> ==
> >>>>>>>>>> ==
> >>>>>>>>>> ====
> >>>>>>>>>> =========
> >>>>>>>>>>
> >>>>>>>>>> ---
> >>>>>>>>>> openjpa/branches/1.0.0/openjpa-kernel/src/main/java/org/
> >>>>>>>>>> apache/
> >>>>>>>>>> openjpa/enhance/PCEnhancer.java
> >>>>>>>>>> (original)
> >>>>>>>>>> +++
> >>>>>>>>>> openjpa/branches/1.0.0/openjpa-kernel/src/main/java/org/
> >>>>>>>>>> apache/
> >>>>>>>>>> openjpa/enhance/PCEnhancer.java
> >>>>>>>>>> Thu Aug 23 22:27:43 2007
> >>>>>>>>>> @@ -467,7 +467,8 @@
> >>>>>>>>>>          } catch (OpenJPAException ke) {
> >>>>>>>>>>              throw ke;
> >>>>>>>>>>          } catch (Exception e) {
> >>>>>>>>>> -            throw new GeneralException(e);
> >>>>>>>>>> +            throw new GeneralException(_loc.get("enhance-
> >>>>>>>>>> error",
> >>>>>>>>>> +                _managedType.getType().getName(),
> >>>>>>>>>> e.getMessage
> >>>>>>>>>> ()), e);
> >>>>>>>>>>          }
> >>>>>>>>>>      }
> >>>>>>>>>>
> >>>>>>>>>> @@ -2736,7 +2737,10 @@
> >>>>>>>>>>              } catch (Throwable t) {
> >>>>>>>>>>                  // last-chance catch for bug
#283 (which can
> >>>>>>>>>> happen
> >>>>>>>>>>                  // in a variety of ClassLoading
> >>>>>>>>>> environments)
> >>>>>>>>>> -                _log.warn(_loc.get("enhance-uid-access",
> >>>>>>>>>> _meta), t);
> >>>>>>>>>> +                if (_log.isTraceEnabled())
> >>>>>>>>>> +                    _log.warn(_loc.get("enhance-uid-access",
> >>>>>>>>>> _meta), t);
> >>>>>>>>>> +                else
> >>>>>>>>>> +                    _log.warn(_loc.get("enhance-uid-access",
> >>>>>>>>>> _meta));
> >>>>>>>>>>              }
> >>>>>>>>>>
> >>>>>>>>>>              // if we couldn't access the
> >>>>>>>>>> serialVersionUID, we
> >>>>>>>>>> will have
> >>>>>>>>>> to
> >>>>>>>>>> @@ -3672,10 +3676,13 @@
> >>>>>>>>>>       * attribute name for the backing field
<code>name</
> >>>>>>>>>> code>.
> >>>>>>>>>>       */
> >>>>>>>>>>      private String fromBackingFieldName(String
name) {
> >>>>>>>>>> -        if (_meta.getAccessType() ==
> >>>>>>>>>> ClassMetaData.ACCESS_PROPERTY
> >>>>>>>>>> +        // meta is null when doing persistence-aware
> >>>>>>>>>> enhancement
> >>>>>>>>>> +        if (_meta != null
> >>>>>>>>>> +            && _meta.getAccessType()
==
> >>>>>>>>>> ClassMetaData.ACCESS_PROPERTY
> >>>>>>>>>>              && _fieldsToAttrs.containsKey(name))
> >>>>>>>>>> -            name = (String) _fieldsToAttrs.get(name);
> >>>>>>>>>> -        return name;
> >>>>>>>>>> +            return (String) _fieldsToAttrs.get(name);
> >>>>>>>>>> +        else
> >>>>>>>>>> +            return name;
> >>>>>>>>>>      }
> >>>>>>>>>>
> >>>>>>>>>>      /**
> >>>>>>>>>>
> >>>>>>>>>> Modified:
> >>>>>>>>>> openjpa/branches/1.0.0/openjpa-kernel/src/main/resources/org/
> >>>>>>>>>> apache/openjpa/enhance/localizer.properties
> >>>>>>>>>> URL:
> >>>>>>>>>> http://svn.apache.org/viewvc/openjpa/branches/1.0.0/openjpa-
> >>>>>>>>>> kernel/
> >>>>>>>>>> src/main/resources/org/apache/openjpa/enhance/
> >>>>>>>>>> localizer.properties?
> >>>>>>>>>> rev=569253&r1=569252&r2=569253&view=diff
> >>>>>>>>>> =============================================================
> >>>>>>>>>> ==
> >>>>>>>>>> ==
> >>>>>>>>>> ====
> >>>>>>>>>> =========
> >>>>>>>>>>
> >>>>>>>>>> ---
> >>>>>>>>>> openjpa/branches/1.0.0/openjpa-kernel/src/main/resources/org/
> >>>>>>>>>> apache/openjpa/enhance/localizer.properties
> >>>>>>>>>> (original)
> >>>>>>>>>> +++
> >>>>>>>>>> openjpa/branches/1.0.0/openjpa-kernel/src/main/resources/org/
> >>>>>>>>>> apache/openjpa/enhance/localizer.properties
> >>>>>>>>>> Thu Aug 23 22:27:43 2007
> >>>>>>>>>> @@ -197,4 +197,5 @@
> >>>>>>>>>> no-accessor: Could not find method called {0}
in type {1}.
> >>>>>>>>>> unspecified-unenhanced-types: One or more of
the types in {0}
> >>>>>>>>>> have
> >>>>>>>>>> relations \
> >>>>>>>>>>      to other unenhanced types that were not
specified. These
> >>>>>>>>>> unspecified
> >>>>>>>>>> types \
> >>>>>>>>>> -    are: {1}
> >>>>>>>>>> \ No newline at end of file
> >>>>>>>>>> +    are: {1}
> >>>>>>>>>> +enhance-error: An error occurred while enhancing
{0}.
> >>>>>>>>>> Exception
> >>>>>>>>>> message:
> >>>>>>>>>> {1}
> >>>>>>>>>> \ No newline at end of file
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Patrick Linskey
> >>>>>>> 202 669 5907
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Patrick Linskey
> >>>>> 202 669 5907
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Patrick Linskey
> >>> 202 669 5907
> >>
> >> Craig Russell
> >> Architect, Sun Java Enterprise System http://java.sun.com/products/
> >> jdo
> >> 408 276-5638 mailto:Craig.Russell@sun.com
> >> P.S. A good JDO? O, Gasp!
> >>
> >>
> >>
> >
> >
> > --
> > Patrick Linskey
> > 202 669 5907
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>


-- 
Patrick Linskey
202 669 5907

Mime
View raw message