lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <chris.a.mattm...@jpl.nasa.gov>
Subject Re: Changes Mess
Date Sun, 05 Dec 2010 17:08:40 GMT
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 beginning to indicate contributions from folks and
it's worked well.

Cheers,
Chris

On Dec 4, 2010, at 10:03 PM, Mark Miller wrote:

> 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 add that (along 
> with a link). Certainly nice to have a 'hard' copy.
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315147&styleName=Text&projectId=12310110&Create=Create
> 
> The only thing I don't like is the loss of the current credit system - I 
> like that better than the crawl through JIRA method. I think prominent 
> credits are a good encouragement for new contributors.
> 
> Any comments on that?
> 
> - Mark
> 
> On 12/2/10 11:46 AM, Grant Ingersoll wrote:
>> 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
>> 3. A Pointer to full list of changes in JIRA.  Alternatively, I believe there is
a way in JIRA to export/generate a summary of all issues fixed.
>> 
>> #1 can be done right before release simply by going through #3 and doing the appropriate
wordsmithing.  #2 should be tracked as it is found.
>> 
>> It's kind of silly that we have all this duplication of effort built in, not too
mention having to track it across two branches.
>> 
>> We do this over in Mahout and I think it works pretty well and reduces the duplication
quite a bit since everything is already in JIRA and JIRA produces nice summaries too.  It
also encourages people to track things better in JIRA.  #1 above also lends itself well as
the basis of press releases/blogs/etc.
>> 
>> -Grant
>> 
>> 
>> On Dec 1, 2010, at 11:54 AM, Michael McCandless wrote:
>> 
>>> 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, 2010 at 9:22 AM, Uwe Schindler<uwe@thetaphi.de>  wrote:
>>>> 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 names
>>>> are between 3.x changes in trunk.
>>>> 
>>>> I copied over the 3.x branch CHANGES.txt over trunks 3.x section and
>>>> attached a patch of this. What should we do? Its messy :( Most parts seem
to
>>>> be merge failures. We should go through all those diff'ed issues and check
>>>> where they were really fixed (3.x or trunk) and move the entries
>>>> accordingly. After that in the 3.x branch and in trunk's 3.x section of
>>>> CHANGES.txt should be identical text!
>>>> 
>>>> Uwe
>>>> 
>>>> -----
>>>> Uwe Schindler
>>>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>>> http://www.thetaphi.de
>>>> eMail: uwe@thetaphi.de
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> 
>> 
>> --------------------------
>> Grant Ingersoll
>> http://www.lucidimagination.com
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
> 


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message