You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Patrick Linskey <pl...@gmail.com> on 2008/07/02 02:11:49 UTC
Re: svn commit: r670740 - in /openjpa/branches/wls-maintenance: ./ 1000mp1/
> If you can't just establish a "starting point" for your maintenance
> release
> and use an existing branch, then I would suggest a branch name of
> 0.9.7-r547073. At least we know it's somewhere beyond 0.9.7, but
> not quite
> 1.0.0.
Sounds good. Srinivasa: can you delete the branch that you created,
and create a new one at /openjpa/branches/0.9.7-r547073?
Moving forward, of course, it makes sense both for WebLogic (and other
consumers) and for the OpenJPA community to strive to release off of
actual published versions. FYI, it's currently our (Oracle's)
intentions to do exactly that with the 1.1.0 release and the upcoming
WebLogic 10.3 product.
-Patrick
On Jun 27, 2008, at 11:51 AM, Kevin Sutter wrote:
> Patrick and others,
>
> On Fri, Jun 27, 2008 at 1:29 PM, Patrick Linskey
> <pl...@gmail.com> wrote:
>
>> 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 agree with your concern here. We (IBM) have had the same concerns
> with
> internal repositories. That's why we have decided to build,
> package, and
> ship the binaries from the OpenJPA svn repository. As we have
> released
> various versions of WebSphere that supports OpenJPA, we have either
> used a
> released version of OpenJPA (ie. 1.0.0) or we have chosen a specific
> SNAPSHOT revision number. In either case, we have kept track of the
> specific svn revision so that we know the "starting point" for
> service.
>
> This "starting point" has always been somewhere in our existing branch
> structure. We currently have the following branches available in our
> OpenJPA svn repository:
>
> 0.9.6-incubating
> 0.9.7-incubating
> 1.0.x
> 1.1.x
>
> And, now we have a branch called wls-maintenance. To expand on Mike's
> earlier post, where does this "wls-maintenance" branch fit into the
> heirarchy? If someone commits a change to this "wls-maintenance"
> release,
> how can we easily determine whether the fix affects any of the other
> branches? The point being is that we're not following our established
> conventions for naming of branches and releases.
>
> And, I don't want to clutter up our branches with lots and lots of
> confusing
> names. For example, if we start with this wls-maintenance, that
> would open
> the door for ibm-maintenance, sun-maintenance, geronimo-maintenance,
> bobs-maintanence, etc.
>
> If you can't just establish a "starting point" for your maintenance
> release
> and use an existing branch, then I would suggest a branch name of
> 0.9.7-r547073. At least we know it's somewhere beyond 0.9.7, but
> not quite
> 1.0.0.
>
> Kevin
>
>
>>
>> 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.02
>>>>>
>>>>> I have no problems with 1. Posthumously creating a branch will
>>>>> happen
>>>>> from
>>>>> time to time.
>>>>>
>>>>> I think that 2 can cause problems. It's not clear to me from the
>>>>> branch
>>>>> name
>>>>> where 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
>>>>> branches
>>>>> for each consumer could cause a lot of confusion.
>>>>>
>>>>> -mike
>>>>>
>>>>> On Wed, Jun 25, 2008 at 4:04 PM, Patrick Linskey <plinskey@gmail.com
>>>>> >
>>>>> 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 that
>>>>>> version).
>>>>>>
>>>>>> 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
>>>>>> more
>>>>>> general sentiment are:
>>>>>>
>>>>>> 1. this branch was created post facto, rather than up-front
>>>>>>
>>>>>> 2. the name of the branch has vendor connotations
>>>>>>
>>>>>> Are 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
>>>>>> repository
>>>>>>
>>>>>>> should 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
>>>>>>> which
>>>>>>> caused
>>>>>>> some concern for BEA. I'm guessing that rev 547073 is a point
>>>>>>> in time
>>>>>>> before
>>>>>>> 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. I
>>>>>>> checked
>>>>>>> out 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
>>>>>>> name
>>>>>>> of
>>>>>>> 0.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
>>>>>>> customers
>>>>>>> though.
>>>>>>>
>>>>>>> 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
>>>>>>> but
>>>>>>> it
>>>>>>> should fit the naming conventions we've laid out.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> -mike
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 25, 2008 at 2:08 PM, Craig L Russell <
>>>>>>> Craig.Russell@sun.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I agree with Kevin that we should eschew vendor tags in the
>>>>>>> OpenJPA
>>>>>>>
>>>>>>>> repository.
>>>>>>>>
>>>>>>>> It should be sufficient to have maintenance folks know from
>>>>>>>> which
>>>>>>>> branch
>>>>>>>> a
>>>>>>>> maintenance 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
>>>>>>>> you
>>>>>>>> need
>>>>>>>> to make patches for specific customers, it seems that a local
>>>>>>>> repository
>>>>>>>> would be appropriate. And once the patch is verified to work,
>>>>>>>> put the
>>>>>>>> update
>>>>>>>> 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 I
>>>>>>>>
>>>>>>>> didn't see your original posting asking for guidance, but I
>>>>>>>> really
>>>>>>>>> don't
>>>>>>>>> think we want WebLogic, WebSphere, Geronimo, or any other
>>>>>>>>> vendor's
>>>>>>>>> specific
>>>>>>>>> maintenance releases housed in the OpenJPA SVN repository.
>>>>>>>>>
>>>>>>>>> It looks like WebLogic shipped something between the
>>>>>>>>> 0.9.7-incubating
>>>>>>>>> and
>>>>>>>>> the 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? It
>>>>>>>>> would
>>>>>>>>> seem that customers would appreciate using an official
>>>>>>>>> release (post
>>>>>>>>> incubation) instead of the the one WebLogic initially shipped.
>>>>>>>>>
>>>>>>>>> Do you need a complete branch? Or, are you just interested in
>>>>>>>>> tagging
>>>>>>>>> the
>>>>>>>>> branch 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 the
>>>>>>>>> approach
>>>>>>>>> that you used.
>>>>>>>>>
>>>>>>>>> Kevin
>>>>>>>>>
>>>>>>>>> On Mon, Jun 23, 2008 at 3:36 PM, <ss...@apache.org> wrote:
>>>>>>>>>
>>>>>>>>> Author: ssegu
>>>>>>>>>
>>>>>>>>> Date: 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
>>>>>>>>>> released
>>>>>>>>>> from(rev #547073).
>>>>>>>>>>
>>>>>>>>>> http://www.nabble.com/OpenJPA-branches-td16547180.html#a16547180
>>>>>>>>>>
>>>>>>>>>> Added:
>>>>>>>>>> openjpa/branches/wls-maintenance/
>>>>>>>>>> openjpa/branches/wls-maintenance/1000mp1/
>>>>>>>>>> - copied from r547073, openjpa/trunk/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>> --
>>>> 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
>>
>>
--
Patrick Linskey
202 669 5907