Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of markrmiller@gmail.com
 designates 209.85.216.48 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=WdoRiwDS0VkOSxuwbRqH1N2wcuV88MV91OIqQyWl5Rg78vrSvNDyTgqyGwJ+itQ3BF
         aHWpBZFB24xfTw1F4DqN67uPPHTy/YTNNIYtv+2RraCARHX62ufKQa6eLgDybSw0CgRz
         r/Mh2FfkIhj1Cf2JkEBWpifeXVwDGgNR6RfzA=
Message-ID: <4CFB2B3F.4050308@gmail.com>
Date: Sun, 05 Dec 2010 01:03:43 -0500
From: Mark Miller <markrmiller@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:2.0b8pre) Gecko/20101116 Thunderbird/3.3a1
MIME-Version: 1.0
To: dev@lucene.apache.org
Subject: Re: Changes Mess
References: <000d01cb9163$22ac2d10$68048730$@thetaphi.de>
 <AANLkTimw-HECMVU2imASbmouE+n8VikH_Z8KXPMd6pFy@mail.gmail.com>
 <D199B09F-7CF0-4E4A-8DF7-702EF4F80F41@apache.org>
In-Reply-To: <D199B09F-7CF0-4E4A-8DF7-702EF4F80F41@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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