lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: Changes Mess
Date Sun, 05 Dec 2010 06:03:43 GMT
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


Mime
View raw message