: commited to) and have new (optional) fields indicating what FV
: has been
: used for in the past:
: How significant is are the changes resulting from this issue?
: A - major bug fix; no api changes; should be put into an
: X.Y.Z
: releases ASAP
:
Otis Gospodnetic wrote:
Regarding your payloads example and 2.1 vs. 3.0, there is a simpler approach,
and one that we have
>pretty much (unintentionally?) been using. Larger chunks of work take
longer,
need more eyes to check them, to test them locally, iron out bugs, etc. and
finally
>app
Therefore, while this work is in progress, it's all done via
patches in JIRA,
and people's local repositories.
This is pretty close to a separate "payloads" branch. That just provides
a shared branch, should the number of people working on that code line
require it for better com
looking for a change here.
Otis
- Original Message
From: Steven Parkes <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Friday, October 27, 2006 4:45:16 PM
Subject: RE: releases
not neccessarily ... if somethings in the trunk, you're saying
it should
be included
Sev
- Original Message
From: Steven Parkes <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Friday, October 27, 2006 4:45:16 PM
Subject: RE: releases
not neccessarily ... if somethings in the trunk, you're saying
it should
be included in a release eventually .
not neccessarily ... if somethings in the trunk, you're saying
it should
be included in a release eventually ... but that doesn't
neccessarily need
ot be the 2.1 release ,it might be the 3.0 release
I can see this in theory, but do our use patterns for svn support it? My
un
: And an observation: shouldn't everything currently in Resolved have a
: FVs that includes 2.1? I can see optionally adding 2.0.1, too, but since
: it's already committed to trunk, it's obviously planned to be fixed in
: 2.1, right?
not neccessarily ... if somethings in the trunk, you're saying
Hi,
- Original Message
From: Steven Parkes <[EMAIL PROTECTED]>
And an observation: shouldn't everything currently in Resolved have a
FVs that includes 2.1? I can see optionally adding 2.0.1, too, but since
OG: I never specify FV. I bet you will see most issues in Resolved state have
n
- Original Message
From: Chris Hostetter <[EMAIL PROTECTED]>
: But consistency would help me and I suppose I still favor flagging
: everything as 2.1 now. If not for the simple reason that I don't know
: how to decide if something should go into some 2.0.1 when I don't know
: what's going
I've been thinking this all through and I guess my question is with the
synchronization between Jira and svn. The fact that Resolved/Fixed is
usually tied to a commit shows we all think they are related: we're all
using Jira to reflect svn to some extent, right?
I'd like to be able to look at Jira
: I guess I figure the process for 2.0.1, if there was a compelling need
: for it, would be to review all the changes that have happened since 2.0
: was cut. Were I to do this, I'd look at the ones flagged as 2.1 as well
: as the 2.0.1, so I don't see that flagging early really buys much.
It's ki
ow
what's going to trigger the need for it.
I kinda feel like I should apologize for belaboring all this but I got
people that want answers to these questions. I'll right up the wiki
summary.
-Original Message-
From: Doug Cutting [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 26, 20
Chris Hostetter wrote:
this is the past thread i was thinking about before...
http://www.archivum.info/java-dev@lucene.apache.org/2006-06/msg00012.html
...refering to leaving the release branches clean untill just before a
point release when all the desired changes can get merged in.
That's t
: I don't recall any commits in the lucene_2_0 branch, I think everything
: since 2.0 has been getting committed in the trunk, and my guess is those
: are just human errors in JIRA. But I think your interpretation of how
: Fix Versions should be read is correct.
this is the past thread i was thi
Steven,
I don't recall any commits in the lucene_2_0 branch, I think everything since
2.0 has been getting committed in the trunk, and my guess is those are just
human errors in JIRA. But I think your interpretation of how Fix Versions
should be read is correct.
Otis
- Original Message -
: There a number of resolved Jira issues that spec the Fix Version/s as
: 2.0.1. I'm wondering if I'm interpreting this correctly: to me, this
: would mean that the changes have been checked into branches/lucene_2_0,
: not trunk. But these were actually checked into trunk. As far as the
I believe
16 matches
Mail list logo
