On Aug 26, 2007, at 5:51 PM, [EMAIL PROTECTED] wrote:
Why? It seems like if the commiters are responsible about only committing things that would belong on the maintenance branch eventually anyways, then that's good enough.
We're talking about a process here. The RM is trying to cut a release and if developers are continuing to check code into all possible code lines I smell disaster. IMHO the RM should be able to play in a stable sandbox.
Let's play this out with specifics. Let's say that the 1.0 branch is open to checkins while RM finalizes the release. At some point RM tags 1.0.0 before building the release candidate. The 1.0 branch continues to have checkins that developers have decided belong in both trunk and maintenance. The vote fails. The RM merges the 1.0 branch into the 1.0.0 tag, picking up the checked in bug fixes that developers thought would be good. Testing shows one of the bug fixes is bad and the release has to be respun.
A better process would be to give the RM control over the 1.0 branch. Nothing gets checked in unless RM approves it. RCs are cut from the living end of 1.0 branch and voted on. At some point the vote succeeds and tag 1.0.0 is created. The 1.0 branch is opened again to developers, although I don't think many developers will bother checking anything into it. Once someone wants to make a maintenance release, RM goes through all the checkins from trunk to decide which can safely be applied to the maintenance release and merges those in.
I'm still curious about why developers would bother checking code into both trunk and all the active maintenance branches. Do we want developers to concern themselves with all the branches that the fix applies to and run all their tests on each branch? Or do we have the RM responsible for a maintenance branch review the patches that they think are relevant?
Craig
The benefit is that if the release does need to be rebuilt, then the additional tweaks automagically get picked up. Bear in mind that the RM can tag the revision used to make the RC. -Patrick On 8/26/07, Craig L Russell <[EMAIL PROTECTED]> wrote:Hi Kevin, On Aug 24, 2007, at 5: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?This is a problem. IMHO, the release manager should be the only person deciding what gets checked into a branch that is going to be released. If Marc ok'd the checkin after the release was voted, then he should be prepared to respin the release. If he didn't ok the checkin, then it should not have been checked in.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?How I think this should be managed is the release manager for 1.0.0 should be approving all checkins into the branch. (Whether the branch is named 1.0.0 or 1.0 isn't relevant to this discussion). Once a VOTE is called, no further checkins should be allowed until the VOTE is complete or rescinded. If rescinded, other checkins can happen at the discretion of the release manager. Once complete, the branch should be tagged and the contents reset to be a SNAPSHOT of the next release on the branch. In this case, 1.0.1-SNAPSHOT. CraigThanks, Kevin On 8/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 fileCraig RussellArchitect, Sun Java Enterprise System http://java.sun.com/products/ jdo408 276-5638 mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
