Hi,I guess I see things a bit differently than does Craig. Pragmatically- speaking, it is quite difficult to "just" use an internal svn repository. Would that we all used git, my tune might be different.
Setting up a separate svn repository for distribution-specific maintenance is a difficult proceeding, and is tantamount to a fork. Such a process would erect artificial barriers to pushing bugfixes back into the Apache OpenJPA repository, which directly damages the OpenJPA project and its goals.
Additionally, currently, a WebLogic Server end user can find out exactly what revision of OpenJPA they're running. This is possible because we (WebLogic) have worked hard to ensure that all our external releases are built directly from the public Apache svn repository. As soon as we start using an internal snapshot + changes of that repository, that transparency is eliminated, and a chunk of OpenJPA end users suffer along the way, which indirectly damages the OpenJPA project and its goals.
I see this as different from, for example, an agreement by the OpenJPA project to cut an early release, create a branch, and release a version (that happens to be used by a commercial product) and then maintain that version.
I only see a temporal difference. Is there something else that I'm missing?
There was no vote or other action by the project to establish the branch
I wasn't aware that branching was a vote-dependent action. Additionally, while there was no vote, there definitely was "other action". Srinivasa started a discussion on this topic a few months ago [1]. At the time, no objections (or comments of any sort) were raised.
and it's not a group of OpenJPA developers
I don't understand what you're getting at here. To the best of my knowledge, there are a group of OpenJPA contributors who intend to work on the branch in question.
If asked to explain why we have branched the repository and are doing maintenance on that branch, I'd have to say that it's solely for the support of a commercial product.
One could also say "it is for ongoing support and hardening of a widely-distributed packaging of OpenJPA".
-Patrick [1] http://www.nabble.com/OpenJPA-branches-td16547180.html#a16547180 On Jun 26, 2008, at 5:01 PM, Craig L Russell wrote:
The biggest issue I have with the use of the Apache svn repository for this purpose is that the repository tag was not created nor will it be used to further the goals of the OpenJPA project.If asked to explain why we have branched the repository and are doing maintenance on that branch, I'd have to say that it's solely for the support of a commercial product. There was no vote or other action by the project to establish the branch and it's not a group of OpenJPA developers working on a sub-project that needs a branch. It's "just" a commercial entity with its stuff in the Apache svn repo.I see this as different from, for example, an agreement by the OpenJPA project to cut an early release, create a branch, and release a version (that happens to be used by a commercial product) and then maintain that version.I'd suggest that for this purpose, BEA just use an internal svn repository for maintenance.Crag On Jun 25, 2008, at 5:21 PM, Patrick Linskey wrote:So, going back to the original thread, one of the suggestions for naming was:http://svn.apache.org/repos/asf/openjpa/branches/r547073/It sounds like you'd prefer that approach. What about Craig and Kevin? I'm assuming that Srinivasa is ok with that approach, since he suggested it in his original email.-Patrick On Jun 25, 2008, at 2:55 PM, Michael Dick wrote:Just my $0.02I have no problems with 1. Posthumously creating a branch will happen fromtime to time.I think that 2 can cause problems. It's not clear to me from the branch namewhere wlsmaintenance fits. Is it before or after 1.1.0? If I'm a new developer should I try to merge my patch from trunk to wlsmaintenance/1000mp1?Where it gets ugly is if the trend continued. Potentially creating branchesfor each consumer could cause a lot of confusion. -mikeOn Wed, Jun 25, 2008 at 4:04 PM, Patrick Linskey <[EMAIL PROTECTED]> wrote:Personally, I don't see anything wrong with the approach taken so far. It's definitely not the most ideal, but it seems to be a fair approach given the situation (no branch was made at the time that WebLogic 10.0 shipped initially, and now there are changes that need to be made against thatversion). As discussed earlier, with the 1.1.x branch, which was driven by us(WebLogic), we hope to minimize the changes made to the branch to important bugfixes only, such that we can simply track that branch moving forward. I expect that other organizations that push for a given release at a given time to dovetail with their release trains will have similar desires.It seems like the only differences between the case at hand and that moregeneral sentiment are: 1. this branch was created post facto, rather than up-front 2. the name of the branch has vendor connotationsAre your objections to issue 1 (i.e., the existence of a post- facto branch)or issue 2 (a vendor name appearing in a branch)? -Patrick On Jun 25, 2008, at 1:16 PM, Michael Dick wrote:I agree with Craig and Kevin. Vendor tags in the Apache SVN repositoryshould be avoided.I'm also leery of adding another branch to maintain. Patrick alluded to potentially dangerous changes which went into the 1.0.x branch whichcausedsome concern for BEA. I'm guessing that rev 547073 is a point in timebefore similar changes went in.If that's the motivation for creating a branch I'm not entirely opposed to it, but it should fit in with the rest of our naming conventions. Icheckedout rev 547073 and pom.xml lists the version as 1.0.0-SNAPSHOT. Any branch made at this point would be between 0.9.7 and 1.0.0. I'd suggest a nameof0.9.x for the new branch. The poms should be rolled back and so on - might have to do something to make OpenJPAVersion look correct to BEA customersthough.Without looking at the differences between 547073 and 1.0.0 I can't say whether we really need this branch. I am not opposed to creating one butit should fit the naming conventions we've laid out. Regards, -mikeOn Wed, Jun 25, 2008 at 2:08 PM, Craig L Russell <[EMAIL PROTECTED] >wrote:I agree with Kevin that we should eschew vendor tags in the OpenJPArepository.It should be sufficient to have maintenance folks know from which branchamaintenance release was cut (r547073, openjpa/trunk/ is really where you shipped from??? After creating a 1.1.0 tag?). And we now have trunk,1.1.x, and 1.0.x branches as active code lines.The only reason that I can think of to have a vendor tag is so you can do vendor maintenance in it. And I don't think we want to do that. If youneedto make patches for specific customers, it seems that a local repository would be appropriate. And once the patch is verified to work, put theupdate into an Apache svn branch. What do others think? Craig On Jun 23, 2008, at 2:36 PM, Kevin Sutter wrote:Wait a minute, Srinivasa. This doesn't seem right. I will admit that Ididn't see your original posting asking for guidance, but I really don't think we want WebLogic, WebSphere, Geronimo, or any other vendor'sspecific maintenance releases housed in the OpenJPA SVN repository.It looks like WebLogic shipped something between the 0.9.7- incubatingandthe official 1.0.0 release. Is there some reason why you couldn't just support your WebLogic customers using the 1.0.x service stream? Itwouldseem that customers would appreciate using an official release (postincubation) instead of the the one WebLogic initially shipped.Do you need a complete branch? Or, are you just interested in taggingthebranch so that you can easily find the start of your service stream?I think we need to do something different here. I don't like theapproach that you used. Kevin On Mon, Jun 23, 2008 at 3:36 PM, <[EMAIL PROTECTED]> wrote: Author: sseguDate: Mon Jun 23 13:36:41 2008 New Revision: 670740 URL: http://svn.apache.org/viewvc?rev=670740&view=rev Log:Branched from revision that BEA WebLogic Server 10.0 MP1 was releasedfrom(rev #547073).http://www.nabble.com/OpenJPA-branches- td16547180.html#a16547180Added: openjpa/branches/wls-maintenance/ openjpa/branches/wls-maintenance/1000mp1/ - copied from r547073, openjpa/trunk/ Craig 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 5907-- Patrick Linskey 202 669 5907Craig 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!
-- Patrick Linskey 202 669 5907
smime.p7s
Description: S/MIME cryptographic signature
