On Aug 27, 2007, at 7:45 PM, Marc Prud'hommeaux wrote:
On Aug 27, 2007, at 9:43 PM, Craig L Russell wrote:Because I'm of the opinion that the RM should be able to say "I'm working on the release. Please no checkins until after the release is built."Note that the checkins were not particularly burdensome. While they had not been explicitly discussed and authorized, they were mostly fixes for identified problems with the release, and since they were relatively minor changes, it wasn't too difficult to handle them. In the future, a better solution would have been to have a parent "1.0" branch (as we've been discussion), and have bugfixes going into the parent branch.
This might be the solution to this issue, assuming that everyone agrees.
The RM can then choose to merge down the changes into the "1.0.0" branch between votes when deemed appropriate. We might even suggest that the RM might want to consider locking the "1.0.0" branch if they are concerned about accidental intra-vote commits slipping in.
Locking the release would only be necessary if people didn't respect the RM's control of the release branch.
[...] A release cannot be vetoed. If anyone has an issue with an excluded bit of code that the RM doesn't want to put in, a full vote is required.On a somewhat related note, I've been wondering if my rescinding of the previous votes were technically legal, since rescinding a vote is tantamount to vetoing it (which can't be done for a release).
The RM can veto a release by simply re-spinning it. For arbitrary and/ or capricious reasons you can suspend and call another vote. So you did nothing out of the ordinary.
While I expect that everyone agrees with the expediency of rescinding and re-starting the vote, I am concerned that it might be bad form.
No, not at all. In exchange for being the go-to guy for the release, you get god-like powers.
By the way, nice job on the release, Marc. You've earned your vacation/honeymoon.Thank you very much, but I'd hold off on the laudatory remarks until the release is actually published :)
Ok, but my patience is limited. ;-) Craig
On Aug 27, 2007, at 9:43 PM, Craig L Russell wrote:On Aug 27, 2007, at 4:09 PM, Patrick Linskey wrote:Granted, some of this discussion is with 20/20 hindsight. But, we need to figure out our approach and be consistent from the start. All of us havehad various experiences with creating and maintaining branches andreleases. We just need to find a common ground for us to live with.It sounds a whole lot like Kevin and Craig feel that I somehow made the process not work properly.No, what I assume is that you had permission from Marc to check in the changes you made during the release cycle.Can we cite a problem that occurredbased on what I did? If not, then can we alternately cite any concretereason why what I did was undesirable? If not, then why are we spending all this time going back and forth about this topic?Because I'm of the opinion that the RM should be able to say "I'm working on the release. Please no checkins until after the release is built."I must really be missing something here, but why would we merge the contents of the 1.0.0 branch back into trunk after the release has been approved?Typically, in the process of assembling a release, there will be changes that have to be made.Of course.For example, I noticed that one of thefirst RCs was still shipping with the now-unnecessary JCA jars. In myexperience, there are often quite a number of small tweaks that haveto be made, and it is typically far easier to make all of these in oneplace and then copy them all back to trunk at one time, rather than maintaining two branches all along throughout the process.That's fine, as long as the RM is willing to then merge the changes back to the trunk. But I don't believe that the RM should be required to do this on behalf of everyone who feels that they want to work on the release branch while the release is being stabilized.I think that maybe the big disconnect here is that Craig and Kevin seem to be trying to design something that prevents something from going wrong during the release process,Yes.whereas I feel it's more appropriate to design a system that is easy to handle in the happy case.In my own experience, a project as big as this one can use some help during release to avoid unnecessary respins simply because a late-breaking change was not perfect.In this case, the only anomaly was Kevin's checkin that missed a respin. If there had been better communication between Kevin and Marc, this could have been avoided. Obviously this isn't a big deal because the release seems to be ok. And I trust that someone will take responsibility for merging all the 1.0.0 changes into the trunk.In this situation, the happy case is where people do not committhings to the release branch that shouldn't be in there. Assuming thatthat happens, then letting multiple people check into the release branch helps the release manager by decreasing the patch-moving workload, and does not incur any additional cost that I am aware of.The critical concept here is "help the release manager". Assuming they want help. I'm ok with delegating this decision to the RM, but not mandating it.should not have been put into the 1.0.0 branch. At a minimum, Patrick's changes should have been put into trunk and optionally into the 1.0 branch(in preparation for a 1.0.1 branch).I'm not going to go that far. As long as Marc signed up for cleaning up the trunk after the release is done, I'm fine.If we determine that an RC5 isNote that we don't have a 1.0 branch; I believe that the consensus onthat other thread was that the release branch should either directlybecome the maintenance branch, or the release branch should be copiedto the maintenance branch.What matters to me is the before-condition and the after- condition, which I've documented in the other branch (or tag) of this discussion. How the branch and tag are created are serving suggestions. But in order to encourage new release managers to volunteer, we should document what their rights, responsibilities, and best practices are.I'll point out again that the difference between branch and tag is -0- to svn. It's only we who assign semantic value to a branch (which I mean to be a continuing code line) and a tag (which I consider to be a done finished complete point-in-time with a special name).In any event, it is pretty critical that the release branch contents make their way into the maintenance branch, and not via trunk.Absolutely.Given that this is the case, it seems likeputting minor fixes directly into the 1.0.0 branch is far and away themost expedient thing to do, since it means that in the case of a failed RC, the RM only needs to re-sync to the 1.0.0 branch. In the alternate case, the RM must do a patch-collection phase as well.Again, "the RM only needs to do" stuff after the release is approved seems to unduly burden the RM.Additionally, FWIW, the concept of designating one person as the onlyperson qualified to decide if a change should be in the release is directly counter to the release voting process.Not agree.The RM may make aunilateral decision during the release-construction phase, but anyonecan then vote against the release if the RM decides to exclude some bit of code from the release.Not really. A release cannot be vetoed. If anyone has an issue with an excluded bit of code that the RM doesn't want to put in, a full vote is required.IOW, the voting process already providesa fail-safe to prevent worst-case scenarios; it seems like the rest ofthe process should be designed for expediency.There are some cases where autocracy makes sense. I believe this is one of them. Long Live Release Manager.By the way, nice job on the release, Marc. You've earned your vacation/honeymoon.Craig-Patrick On 8/27/07, Kevin Sutter <[EMAIL PROTECTED]> wrote:Patrick's premise of merging from the 1.0.0 branch back into trunk reallythrew me... On 8/26/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:(In the case of the 1.0.0 line, I've been committing things to it directly and not to trunk, on the assumption that we'll be doing a bulk merge from 1.0.0 to trunk once we're done with the release.)I must really be missing something here, but why would we merge the contents of the 1.0.0 branch back into trunk after the release has been approved? In my mind, once a given x.y.z release has been approved, there are no more code updates in this branch. So, any updates done to this branch after the approved svn revision are basically "lost". They don't apply to any release unless manually moved to the appropriate release. I think I'm in agreement with Craig here that once a RM has declared a given x.y.z release, then s/he has complete control over what goes in or stays out. We shouldn't beputting more code against this branch.Here's how I thought the process should have worked... When we determined that we wanted to do the 1.0.0 release, we create the 1.0 branch like Patrick proposed a few notes back. Off of this branch, Marc would create the 1.0.0 branch. We've had a few RC's with fixes getting integrated into the 1.0.0 branch. Eventually, we declared RC4 on the 1.0.0 branch and hopefully this one will pass. But, each time Marc proposed a 1.0.0 build for a vote, that branch was frozen and under his control as to what went in and what stayed out. Since Marc didn't explicitly request Patrick's changes into the 1.0.0 branch (and thus force a respin), then Patrick's changes should not have been put into the 1.0.0 branch. At a minimum, Patrick's changes should have been put into trunk and optionally into the 1.0 branch (in preparation for a 1.0.1 branch). If we determine that an RC5 is required, then Marc may want Patrick's changes put into the 1.0.0 branch for a respin. Then again, he may not want to introduce any more churn and only take the specific change that is forcing him to do a respin. (Note that I am only using Patrick's change as an example to discuss, not attempting toassociate any type of complexity with it.)As an aside, trunk has become 1.1.0-SNAPSHOT until we determine we need a1.1 branch.Granted, some of this discussion is with 20/20 hindsight. But, we need to figure out our approach and be consistent from the start. All of us havehad various experiences with creating and maintaining branches andreleases. We just need to find a common ground for us to live with.Thanks, Kevin -PatrickOn 8/26/07, Craig L Russell <[EMAIL PROTECTED]> wrote: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 codelines 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 isopen 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.0branch 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 fixesis 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 theliving end of 1.0 branch and voted on. At some point the votesucceeds and tag 1.0.0 is created. The 1.0 branch is opened again todevelopers, although I don't think many developers will botherchecking 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 codeinto 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 theythink are relevant? CraigThe 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 theone I did the other evening. It was committed into the 1.0.0 branch after the 4thre-spin and [VOTE] was posted. So, does this require yet anotherrespin?This is a problem. IMHO, the release manager should be the onlyperson 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 thecheckin, then it should not have been checked in.If not, then what happens to these changes? The [VOTE] would notincludethese changes. So, would these changes automatically become partof 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 releaseon 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.javaopenjpa/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, wewill 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} haverelations \ 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}. Exceptionmessage: {1} \ No newline at end of fileCraig RussellArchitect, Sun Java Enterprise System http://java.sun.com/ products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!-- Patrick Linskey 202 669 5907Craig 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-- Patrick Linskey 202 669 5907Craig RussellArchitect, Sun Java Enterprise System http://java.sun.com/products/ jdo408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
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
