openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.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:39:54 GMT

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!


Mime
View raw message