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: 1.0 steps?
Date Mon, 09 Jul 2007 17:13:04 GMT

On Jul 9, 2007, at 10:07 AM, Patrick Linskey wrote:

>> to make a branch. Once the branch is cut, fixes would have to be made
>> in both branch and trunk, so it's not a trivial decision.
>
> Actually, modern VCS systems allow changes to be merged from a branch
> back down to the mainline. In my experience, this is fairly
> straightforward assuming that the merges happen in a timely fashion,
> so I think that this is a fairly trivial decision.

Just remember that tools help but a person needs to actively make the  
decision as to which branch a fix is merged into, and then turn the  
crank. There are also test cases and regression testing considerations.

Trivial? I wouldn't say so. But I agree with the strategy.
>
> In my experience, it's much better in general to make changes in one
> place and then do VCS operations to merge them back down to trunk.

I agree.
>
> That said, I do look forward to the day when svn supports
> automatically keeping track of branching history.

Not sure what more svn should do for us here...

Craig
>
> -Patrick
>
> On 7/9/07, Craig L Russell <Craig.Russell@sun.com> wrote:
>> I think we need to first go through the list of JIRA issues for 0.9.8
>> and 1.0.0 and really think hard about whether they should be fixed or
>> not.
>>
>> We also need a release manager (a person who will do what Marc and
>> Mike did for 0.9.6 and 0.9.7).
>>
>> Maybe we should post the list of proposed deferred JIRA issues for
>> discussion and then move them. I like the idea of defining both a
>> 1.0.1 and 1.1.0 release target to which to defer issues.
>>
>> I think once there is consensus on the non-deferred issues and an
>> identified JIRA owner for them, the release manager can propose when
>> to make a branch. Once the branch is cut, fixes would have to be made
>> in both branch and trunk, so it's not a trivial decision.
>>
>> Maybe a wiki with a table of JIRA issues and proposed target release
>> and some justification (with author's name) would be useful. It's not
>> too hard to set up but still might not be worth the effort.
>>
>> Craig
>>
>> On Jul 9, 2007, at 9:50 AM, Kevin Sutter wrote:
>>
>> >>
>> >> What is remaining to get to a 1.0 release? Are there any things in
>> >> particular that people think are important to work on? Maybe it's
>> >> about time for us to create a branch for 1.0 finalization and
>> >> hardening.
>> >
>> >
>> > This probably depends on what our goal is for a 1.0 release.  If
>> > it's just
>> > to have a 1.0 release since we graduated to a TLP, then we're
>> > probably close
>> > to starting that process.  But, if we are looking for a certain
>> > level and
>> > hardness of function, then we still may have a fews things to clean
>> > up.  I'm
>> > okay with going for a 1.0 release just to have one, but I would
>> > then like to
>> > start working on defining the follow-on release (1.0.1 or 1.1).
>> >
>> > No matter what type of 1.0 release we decide to go for, maybe we
>> > should
>> > incorporate the voting mechanism within JIRA to help determine what
>> > Issues
>> > are important?  I am not totally familiar with this process, but it
>> > allows
>> > users to vote on the Issues that are most important to them.  Each
>> > user is
>> > allowed a certain number of votes (to keep them from voting for  
>> "all"
>> > Issues).  We can use that as input to our selection criteria.
>> >
>> > But, before we open up for a vote, do we need some time to review
>> > all of the
>> > open Issues and assert 1.0 vs post-1.0?  Something along the lines
>> > of what
>> > Patrick did for the previous release?  I just find it kind of
>> > difficult to
>> > be working on various problems and then "ding", the timer goes off
>> > and we've
>> > cut off development for a given release.  It's probably time to  
>> start
>> > working out a candidate release cycle and content.
>> >
>> > Kevin
>>
>> 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