Does anyone feel like there is consensus here?
On Dec 8, 2010, at 1:42 PM, Chris Hostetter wrote:
>
> I'm going to side step the "use jira to generate changes.txt debate, and
> focus on what i think is the broader problem with a simpler fix.
>
> FWIW, i like CHANGES.txt myself, i think the jir
On Dec 8, 2010, at 10:42 AM, Chris Hostetter wrote:
> ***
>
> ...my vote is to start having CHANGES.txt focus solely on the changes
> commited to the branches that lead to that release (so 4.1.1's CHANGES.txt
> will list 4.0, 4.1, 4.2, and 4.2.1 - but not 3.1, or 4.1.1) but i could
> als
I'm going to side step the "use jira to generate changes.txt debate, and
focus on what i think is the broader problem with a simpler fix.
FWIW, i like CHANGES.txt myself, i think the jira generate pages
compliment it, and give you a differnet view of the same info, but i
prefer CHANGES.txt bec
On Tue, Dec 7, 2010 at 3:14 PM, Steven A Rowe wrote:
> On 12/7/2010 at 3:03 PM, Michael McCandless wrote:
>> Could we do something hybrid? Since we have no full control over
>> Jira, could we eg append a comment on the the Jira issue starting with
>> "CHANGES: ", if it needs a changes entry (many
I was going by what Uwe said :)
But if indeed we can make our own fields, this seems like a great
solution? We could add a CHANGES entry field, and a maybe a CHANGES
category ("New feature", "Bug fix", "API change", "Back-compat
exception", etc.)?
Mike
On Tue, Dec 7, 2010 at 8:53 PM, Mattmann,
Hey Mike real quick I'm not sure what you mean by not having full control over
JIRA. I know that you can customize the field types, issue types etc. You just
ask infra and they take care of enabling perms for whomever would like to
manage this for the project.
Cheers,
Chris
Sent from my iPhon
...@thetaphi.de
> -Original Message-
> From: Steven A Rowe [mailto:sar...@syr.edu]
> Sent: Tuesday, December 07, 2010 9:15 PM
> To: dev@lucene.apache.org
> Subject: RE: Changes Mess
>
> On 12/7/2010 at 3:03 PM, Michael McCandless wrote:
> > Could we do something hyb
On 12/7/2010 at 3:03 PM, Michael McCandless wrote:
> Could we do something hybrid? Since we have no full control over
> Jira, could we eg append a comment on the the Jira issue starting with
> "CHANGES: ", if it needs a changes entry (many issues do not)?
Can't we add a field? I see we already h
Both approaches have tradeoffs...
I love that the CHANGES today is carefully edited and as a result very
consumable to users. The verbiage we put into a CHANGES entry is
necessarily different from the title we put into Jira since it's a
different audience.
But I don't like the confusion over whi
Jumping in late to this thread, though I've read most of it.
As a user and committer, I find the current CHANGES very convenient!
It's very easy for me to read what has changed in 3.0, and very easy
for me to put a CHANGES entry whenever I work on something that
warrants such entry.
And if an iss
This is out of thread, but I realized that some entries for DIH are in
solr/CHANGES.txt. These should go solr/contrib/dataimporthandler/CHANGES.txt
(Some of them are my fault). I also found that solr/contrib/*/CHANGES.txt
have "1.5-dev" title. These should be "4.0-dev" or "3.1-dev".
I'll open a t
Hey Robert,
I feel ya. +1 to releasing more often! :)
Cheers,
Chris
On Dec 6, 2010, at 8:31 AM, Robert Muir wrote:
> On Mon, Dec 6, 2010 at 11:20 AM, Mattmann, Chris A (388J)
> wrote:
>>
>> Yeah in the end all I can say is that you basically get out of JIRA what you
>> put into it. What you
On Mon, Dec 6, 2010 at 11:20 AM, Mattmann, Chris A (388J)
wrote:
>
> Yeah in the end all I can say is that you basically get out of JIRA what you
> put into it. What you call extra work is just something that I would do
> anyways working on some of my projects. I'm not saying it's *not difficult
Hi Robert,
On Dec 6, 2010, at 7:11 AM, Robert Muir wrote:
>
> So I don't know how jira would handle this case? because we merged
> contrib/snowball with contrib/analyzers in 3.1 i would have to create
> a separate jira issue just so that 3.1 has the correct
> description/path name in its release
On Mon, Dec 6, 2010 at 10:42 AM, Grant Ingersoll wrote:
> Our new Changes could be structured like below. The important thing about
> this approach is that it can all more or less be written at release time
> other than the contributor list and perhaps the back compat section.
Well this is im
Grant, +1...
Cheers,
Chris
On Dec 6, 2010, at 7:42 AM, Grant Ingersoll wrote:
>
> On Dec 5, 2010, at 12:18 PM, Robert Muir wrote:
>
>> On Sun, Dec 5, 2010 at 12:08 PM, Mattmann, Chris A (388J)
>> wrote:
>>> Hi Mark,
>>>
>>> RE: the credit system. JIRA provides a contribution report here, lik
On Dec 5, 2010, at 12:18 PM, Robert Muir wrote:
> On Sun, Dec 5, 2010 at 12:08 PM, Mattmann, Chris A (388J)
> wrote:
>> Hi Mark,
>>
>> RE: the credit system. JIRA provides a contribution report here, like this
>> one that I generated for Lucene 3.1:
>>
>
> My concern with this is that it lea
On Dec 6, 2010, at 9:58 AM, Mattmann, Chris A (388J) wrote:
>
>> Would you mind naming these Apache projects? I'd like to take a look.
>
> Tika, Nutch, OODT.
Add in Mahout. I believe Hadoop does too.
-
To unsubscribe, e-mai
On Mon, Dec 6, 2010 at 9:56 AM, Mattmann, Chris A (388J)
wrote:
> What's the difference between Mike going and writing up a more informative
> CHANGES.txt entry than say updating JIRA with the information from that entry
> to have a more descriptive title?
>
Well, you are right, but its anothe
> Would you mind naming these Apache projects? I'd like to take a look.
Tika, Nutch, OODT.
Cheers,
Chris
++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Ma
> CHANGES file:
> LUCENE-2658: Exceptions while processing term vectors enabled for
> multiple fields could lead to invalid ArrayIndexOutOfBoundsExceptions.
>
> JIRA description:
> LUCENE-2658: TestIndexWriterExceptions random failure: AIOOBE in
> ByteBlockPool.allocSlice
>
> So you see the stor
If you have full control on your Jira installation, you could define a custom
field named "changes entry and credits". This field could be used for a report.
But we have no separate installation to have all control.
Uwe
"Robert Muir" schrieb:
>On Sun, Dec 5, 2010 at 10:35 PM, Mattmann, Chri
On Sun, Dec 5, 2010 at 10:35 PM, Mattmann, Chris A (388J)
wrote:
> Hi Robert,
>
> True, JIRA isn't a perfect solution for this matter, but works good enough
> usually since many times (especially with prodding) those same users who
> report the bugs are those that report the JIRA issues.
>
I ag
Chris,
> > Yet another way would be to declare the problem non-existent and screw
> > our users by insulting them with a honking great mass of changes without
> > any indication about what they are or how they are inter-related. (You
> > won't be surprised at this point, I think, by my -1 to this
>
> Yet another way would be to declare the problem non-existent and screw our
> users by insulting them with a honking great mass of changes without any
> indication about what they are or how they are inter-related. (You won't be
> surprised at this point, I think, by my -1 to this.)
Right,
Hi Chris,
On 12/5/2010 at 10:36 PM, Chris Mattman wrote:
> Yep, like you state below JIRA *could* be configured to deal with this.
>
> In all honesty, putting tons of thought and effort into how to precisely
> deal with the changes you specify below might be somewhat overkill.
I think dumping CH
Hi Steven,
Yep, like you state below JIRA *could* be configured to deal with this.
In all honesty, putting tons of thought and effort into how to precisely deal
with the changes you specify below might be somewhat overkill.
Cheers,
Chris
On Dec 5, 2010, at 12:17 PM, Steven A Rowe wrote:
> On
Hi Robert,
True, JIRA isn't a perfect solution for this matter, but works good enough
usually since many times (especially with prodding) those same users who report
the bugs are those that report the JIRA issues.
Cheers,
Chris
On Dec 5, 2010, at 9:18 AM, Robert Muir wrote:
> On Sun, Dec 5, 2
On 12/5/2010 at 12:19 PM, Robert Muir wrote:
> On Sun, Dec 5, 2010 at 12:08 PM, Mattmann, Chris A (388J)
> wrote:
> > Hi Mark,
> >
> > RE: the credit system. JIRA provides a contribution report here, like
> > this one that I generated for Lucene 3.1:
> >
>
> My concern with this is that it leaves
On Sun, Dec 5, 2010 at 12:08 PM, Mattmann, Chris A (388J)
wrote:
> Hi Mark,
>
> RE: the credit system. JIRA provides a contribution report here, like this
> one that I generated for Lucene 3.1:
>
My concern with this is that it leaves out important email contributors.
For example if a user repo
Hi Mark,
RE: the credit system. JIRA provides a contribution report here, like this one
that I generated for Lucene 3.1:
http://s.apache.org/BpL
Just click on Reports > Contribution Report in the upper right of JIRA on the
main project summary page.
We've been using this in Tika since the beg
I like this idea myself - it would encourage better JIRA summaries and
reduce duplication.
It's easy to keep a mix of old and new too - keep the things that Grant
mentions in CHANGES.txt (back compat migration, misc info), but you can
also just export a text Changes from JIRA at release and ad
I think we should drop the item by item change list and instead focus on 3
things:
1. Prose describing the new features (see Tika's changes file for instance) and
things users should pay special attention to such as when they might need to
re-index.
2. Calling out explicit compatibility breaks
So, going forward...
When committing an issue that needs a changes entry, where are we
supposed to put it?
EG if it's a bug fix that we'll backport all the way to 2.9.x... where
does it go?
If it's a new feature/API that's going to 3.x and trunk... only in
3.x's CHANGES?
Mike
On Wed, Dec 1, 20
Hi all,
when merging changes done in 2.9.4/3.0.3 with current 3.x and trunk I found
out that 3.x changes differ immense between the trunk changes.txt and the
3.x changes.txt. Some entries are missing in the 3.x branch, but are
available in trunk's 3.x part or other entries using new trunk class na
35 matches
Mail list logo
