I know we have talked about this a few times, but not sure where we left off.

My understanding was that if we change something in trunk and merge to
3.x we *only* add it to the 3.x CHANGES.  If it is only for 4.x it
gets added to the 4.x CHANGES.  But it looks like we are actually
keeping the two versions in sync.  Is this just extra work?

I'm sure this has been discussed before, but can trunk changes only
track changes in trunk and keep anything before that in the 3.x
branch?

Can we delete everything past line 441 in:
https://svn.apache.org/repos/asf/lucene/dev/trunk/lucene/CHANGES.txt
and add a comment saying to look at:
https://svn.apache.org/repos/asf/lucene/dev/branches/branch_3x/lucene/CHANGES.txt

When trunk gets moved to branch_4x, the 3.x changes would get copied
over (and presumably not changed anymore)

thoughts?
ryan

---------------------------------------------------------------------

On Wed, Jun 1, 2011 at 11:21 AM, Ryan McKinley <[EMAIL PROTECTED]> wrote:
> I know we have talked about this a few times, but not sure where we left off.
>
> My understanding was that if we change something in trunk and merge to
> 3.x we *only* add it to the 3.x CHANGES.  If it is only for 4.x it
> gets added to the 4.x CHANGES.  But it looks like we are actually
> keeping the two versions in sync.  Is this just extra work?
>

you just commit it to the version it was added.

For example, if you are adding something to 3x and trunk, commit it to
the 3x section of trunk's CHANGES.txt
then when you svn merge, there will be no merge conflict, it will just work.

---------------------------------------------------------------------

: you just commit it to the version it was added.
:
: For example, if you are adding something to 3x and trunk, commit it to
: the 3x section of trunk's CHANGES.txt
: then when you svn merge, there will be no merge conflict, it will just work.

That assumes you know, before commiting to trunk, that it will (or wont)
be backported to 3x.

The approach (and the cleanness of the merges) completley breaks down if
you start out assuming a feature is targetting 4x, and then later decide
to backport it.

it will also break down in even more fun and confusing ways if/when we
have our first 4.0 release and then someone pushes for having a 3.42
feature release after that (to push out some high value features to people
not yet ready to upgrade to 4.0) because the changes legitimately need to
show up in both the 3.42 and 4.1 release notes.

I've tried to raise these concerns several times in the past and gotten
virtually no response...

http://markmail.org/message/s6zq4e7aomanxulp
http://search.lucidimagination.com/search/document/9a9b1327fe281305/solr_changes_3_1_4_0

I really think that the 4.0 section of CHANGES should list *every*
change on the trunk prior to the 4.0 release, even if it was backported to
3.1 or 3.3 -- because fundementally the "changes" are not neccessarily
identicle.  A bug fix that has been backported may be subtley different
because of the differneces between the branches.

I also (still) agree with Ryan about the "historic record" nature of
CHANGES.txt not making sense anymore now that we have multiple feature
release branches going at once...

>> Can we delete everything past line 441 in:
>> https://svn.apache.org/repos/asf/lucene/dev/trunk/lucene/CHANGES.txt
>> and add a comment saying to look at:
>> https://svn.apache.org/repos/asf/lucene/dev/branches/branch_3x/lucene/CHANGES.txt

+1

-Hoss

---------------------------------------------------------------------

On Thu, Jun 9, 2011 at 3:22 PM, Chris Hostetter
<[EMAIL PROTECTED]> wrote:
>
> : you just commit it to the version it was added.
> :
> : For example, if you are adding something to 3x and trunk, commit it to
> : the 3x section of trunk's CHANGES.txt
> : then when you svn merge, there will be no merge conflict, it will just work.
>
> That assumes you know, before commiting to trunk, that it will (or wont)
> be backported to 3x.
>
> The approach (and the cleanness of the merges) completley breaks down if
> you start out assuming a feature is targetting 4x, and then later decide
> to backport it.

you just first move your change to the 3.x section?

>
> it will also break down in even more fun and confusing ways if/when we
> have our first 4.0 release and then someone pushes for having a 3.42
> feature release after that (to push out some high value features to people
> not yet ready to upgrade to 4.0) because the changes legitimately need to
> show up in both the 3.42 and 4.1 release notes.

we already raised this issue and decided against it for a number of
reasons, it was raised on the dev list and everyone voted +1

http://www.lucidimagination.com/search/document/a42f9a22fe39c4b4/discussion_trunk_and_stable_release_strategy#67815ec25c055810

---------------------------------------------------------------------

: > The approach (and the cleanness of the merges) completley breaks down if
: > you start out assuming a feature is targetting 4x, and then later decide
: > to backport it.
:
: you just first move your change to the 3.x section?

so you're saying that to backport something from trunk to 3x you're
saying the process should be:
 * first you should commit a change to trunk's CHANGES.txt moving the
previously commited entry to the appropraite 3.x.y section
 * then you should merge the *two* commits to the 3x branch

?

that seems like kind of a pain in the ass considering it still doesn't
track reality: the change really was commited to two completly distinct
branches of development -- the underlying code changes made to
implement a feature/fix might be radically differnet -- both should be
tracked.

: we already raised this issue and decided against it for a number of
: reasons, it was raised on the dev list and everyone voted +1
:
: http://www.lucidimagination.com/search/document/a42f9a22fe39c4b4/discussion_trunk_and_stable_release_strategy#67815ec25c055810

i contest your characterization of "everyone" but clearly i missed that
thread back when it happened.  That only address the issue of 3.x feature
releases after 4.0 comes out -- but it still doesn't address the porblem
of bug fixes backported from 4.x to 3.x after 4.0 -- those will still be a
serious problem if we keep removing things from the trunk CHANGES.txt when
backporting.

As i've said before...

> Arguably we could dedup identical entries so that each entry appears
> only once (i suggested this before and now think i was wrong), but that
> loses information: people who see that LUCENE-9876 was fixed in 2.9.4
> have no context of wether that fix was in 3.0.2 or 3.0.3 -- to have that
> full context it makes sense for each "fix" commited in a branch to
> actually be listed in the first release on that branch that the fix was
> in.  

If 4.1 comes out, and then i commit a bug fix to trunk which gets
backported to the 3_7 branch and included in a 3.7.1 release it should
*still* be in the trunk CHANGES.txt for inclusion in the 4.2 CHANGES.txt.
-Hoss

---------------------------------------------------------------------

On Thu, Jun 9, 2011 at 4:44 PM, Chris Hostetter
<[EMAIL PROTECTED]> wrote:
>
> : > The approach (and the cleanness of the merges) completley breaks down if
> : > you start out assuming a feature is targetting 4x, and then later decide
> : > to backport it.
> :
> : you just first move your change to the 3.x section?
>
> so you're saying that to backport something from trunk to 3x you're
> saying the process should be:
>  * first you should commit a change to trunk's CHANGES.txt moving the
> previously commited entry to the appropraite 3.x.y section
>  * then you should merge the *two* commits to the 3x branch
>
> ?

I think so? I guess in general, most things unless they are
super-scary tend to get backported immediately to 3.x (and you know
up-front you are going to do this) so in practice this hasn't been a
problem?

>
> : we already raised this issue and decided against it for a number of
> : reasons, it was raised on the dev list and everyone voted +1
> :
> : http://www.lucidimagination.com/search/document/a42f9a22fe39c4b4/discussion_trunk_and_stable_release_strategy#67815ec25c055810
>
> i contest your characterization of "everyone" but clearly i missed that
> thread back when it happened.  That only address the issue of 3.x feature
> releases after 4.0 comes out -- but it still doesn't address the porblem
> of bug fixes backported from 4.x to 3.x after 4.0 -- those will still be a
> serious problem if we keep removing things from the trunk CHANGES.txt when
> backporting.

OK, well everyone that did vote, voted +1. If you disagree please
respond to that thread! I think it would make things confusing if we
released 4.0 say today, then released 3.3 later, and 4.0 couldnt read
3.3 indexes... but please reply to it.

As far as bugfix releases, in lucene we have always had this issue
(e.g. if we do 3.2.1 we have the issue now). Thats why we have in our
ReleaseTODO a task where we deal with this (and i noticed it had been
missing from one of the bugfix 3.0.x releases and fixed that for 3.2).

---------------------------------------------------------------------

>>
>> : we already raised this issue and decided against it for a number of
>> : reasons, it was raised on the dev list and everyone voted +1
>> :
>> : http://www.lucidimagination.com/search/document/a42f9a22fe39c4b4/discussion_trunk_and_stable_release_strategy#67815ec25c055810
>>
>> i contest your characterization of "everyone" but clearly i missed that
>> thread back when it happened.  That only address the issue of 3.x feature
>> releases after 4.0 comes out -- but it still doesn't address the porblem
>> of bug fixes backported from 4.x to 3.x after 4.0 -- those will still be a
>> serious problem if we keep removing things from the trunk CHANGES.txt when
>> backporting.
>
> OK, well everyone that did vote, voted +1. If you disagree please
> respond to that thread! I think it would make things confusing if we
> released 4.0 say today, then released 3.3 later, and 4.0 couldnt read
> 3.3 indexes... but please reply to it.
>

The release strategy and CHANGES strategy seem different (but related)
to me.  I agree with the release strategy outlined in that thread, but
don't see how it answers questions about maintaining CHANGES.txt

The thing that seems wierd is that the historic release info in
CHANGES.txt is potentially different then what will presumably be
released in the 3.x branch.  For example right now, if you take the
3.x lucene/CHANGES and paste them in the right place on trunk, there
there are a bunch of diffs for names with accents
-   have been deleted. (Christian Kohlsch├╝tter via Mike McCandless)
+   have been deleted. (Christian Kohlschⁿtter via Mike McCandless)

but also real differences like:
-* LUCENE-2130: Fix performance issue when FuzzyQuery runs on a
-  multi-segment index (Michael McCandless)
-

The same exercise in solr/CHANGES.txt reveals lots of differences.

Is this expected?  It seem more like a by-product of trying to keep
things in sync.  I suppose that could be fixed with some good

To simplify the process, I suggest we remove historic info from /trunk
and add point people to the CHANGE in the current stable branch (3.x)
-- when /trunk is moved to /branch_4x we would move everything there.
ryan

---------------------------------------------------------------------

: Is this expected?  It seem more like a by-product of trying to keep
: things in sync.  I suppose that could be fixed with some good
:
: To simplify the process, I suggest we remove historic info from /trunk
: and add point people to the CHANGE in the current stable branch (3.x)
: -- when /trunk is moved to /branch_4x we would move everything there.

Agreed.  This is something Grant and i both advocated last year and didn't
really get any feedback on.  Rather then trying to keep files on diff
branches in sync (what folks seem to be doing now) or "copying forward"
changes from release branches to the trunk (what we have done in the past)
let's just keep the CHANGES.txt file on each branch constrained to the
changes commited directly to that branch and point people to URLs where
then can find info about other releases.

This is all great, but it's actaully not my main concern at all.

My main concern is that this process of *removing* entries from the
"trunk" section of CHANGES.txt when merging those commits "back" to an
earlier release branch is losing history and will dangerously misslead
users who review the changes in a given branch.

Consider this hypothetical timeline...

* 3.2 is released
* 3.3 is released
* trunk is renamed branch_4x
* 4.0 is released off branch_4x
* a new trunk is created targeting 5.x
* LUCENE-8888 is created - critical bug affecting 3.3
* r8888888 is commited to branch_3x to fix LUCENE-8888
* 3.3.1 is released with fix for LUCENE-8888
* 4.1 is released
* LUCENE-9999 is created - critical bug affecting all versions
* r999999 is commited to trunk to fix LUCENE-9999
* r999999 is merged back to branch_4x
* r999999 is merged back to branch_3x
* 3.3.2 is released with fix
* 4.1.1 is released with fix

...if each of those merges follows the process described (only list a
change in the section for the oldest release merged to) then people could
be under the mistaken impression that 4.0 is safe and not at risk
for LUCENE-9999 because the issue is listed as fixed was in
3.3.2.

We got away with this kind of pattern in the past because we weren't
creating new branches for major releases.  The only time we
ran into a situations where we had an ${X}.${Y}.Z
bug fix release when there had already been an ${X+1}.Q release was the
2.9.x/3.0.x bug fix releases where we side stepped the issue by having
"lock step" bug fix releases and only listed a single set of changes for
*both* releases on each branch -- but expecting that same pattern to work
in all cases moving forward seems like a pipe dream.  we pulled it off
back then because the "branches" we're nearly identical (just removed
deprecations) so the bugs (and fixes) were nearly identical.

the 3x branch and trunk are differnet enough that not every bug/fix is
going to fit into that same patterm -- some bugs are only going to affect
some branches, and some bugs might affect both branches but require
different fixes.  we need to document our changes in a way that accurately
reflects what was fixed where, and if we move forward with this process of
"remove changes from trunk when backporting to 3x" that's going to fuck us
over down the road.

At a fundemental, philosophical, level i think that every release should
list the changes commited to that *branch* since the last release that was
an "ancestor" in the svn hierarchy.  When 4.0 comes out, it's "section" in
CHANGES.txt should be labeled "Changes since 3.0"  not "Changes since
3.{whatever-the-latest-3x-release-was}" and if/when 4.4 comes out it's
section should be "Changes since 4.3" and if 4.2.7 comes out it's section
should be "Changes since 4.2.6"  ... etc.

But i can understand that people might think that is stupid.  I can
understand people thinking that if a feature was backported and released
in 3.1, users who download 4.0 won't care that it was independently
commited to that branch as well, so it shouldn't be listed as a "Change"
in 4.0 -- maybe for "features" that makes sense.

Buf for bug fixes we really need to deal with this in a better way.  We
need to track *every* bug fix made on a branch, even if they were
backported to an earlier branch.

-Hoss

On Fri, Jun 10, 2011 at 9:31 PM, Chris Hostetter
<[EMAIL PROTECTED]> wrote:
>
> Buf for bug fixes we really need to deal with this in a better way. ��We
> need to track *every* bug fix made on a branch, even if they were
> backported to an earlier branch.
>

I think we have?

bugfixes are the only case (assuming we go with the plan where we
don't go back in time and issue 3.x feature releases after we release
4.x, etc) where we "go backwards".

I'll pick LUCENE-3042 as a random one.

Its in Lucene 3.2's CHANGES.txt
Its in branch-3.0's CHANGES.txt
its in branch-2.9's CHANGES.txt

its not in trunk's CHANGES.txt, since its fixed in a non-bugfix
release before 4.0 will be released.

In short, I don't think there is any problem... and as far back as I
can see, this is exactly how we have been handling all bugfixes with
the 2.9.x and 3.0.x bugfix releases.

---------------------------------------------------------------------

: I think we have?
:
: bugfixes are the only case (assuming we go with the plan where we
: don't go back in time and issue 3.x feature releases after we release
: 4.x, etc) where we "go backwards".

So you're saying after 4.0 is released, we'll stop "removing" changes
entries from the 4x section when they are backported to the 3x branch?

I guess that will work -- but it seem fundementally and philosophically
wrong to me to be doing this.

: I'll pick LUCENE-3042 as a random one.
:
: Its in Lucene 3.2's CHANGES.txt
: Its in branch-3.0's CHANGES.txt
: its in branch-2.9's CHANGES.txt
:
: its not in trunk's CHANGES.txt, since its fixed in a non-bugfix
: release before 4.0 will be released.

But there is no way for someone looking at the CHANGES for 4.0 to know
for certain that the bits that make up that bug fix are in the 4.0 release
-- the fact that it's listed in 3.2's CHANGES isn't an assurance, because
4.0 comes from a completely different line of development.

: In short, I don't think there is any problem... and as far back as I
: can see, this is exactly how we have been handling all bugfixes with
: the 2.9.x and 3.0.x bugfix releases.

when we had a singular trunk producing the 2.9, 3.0, and 3.1 releases
everything was linear and this type of linear CHANGES made sense -- but
with two branches whose common ancestor is (essentially) 3.0 it just isn't
the same thing - CHANGES should reflect *everything* that went into the
branch.

For the same reason that 3.6 release notes would list all "changes
since 3.5" and 3.6.1 release notes would list all "changes since 3.6"
the release notes for 4.0 should list *all* "Changes since 3.0" since
that's the common ancestor.

But to hell with it ... i've been arguing this for months and no one seems
to agree, so fuck it.  

I'll stop harping on it but i can't promise i'll remember/understand the
right way to add CHANGES to fall in line with the madness that's already
in progress -- continued cleanup may be needed if/when i commit stuff that
wins up backported.
-Hoss

---------------------------------------------------------------------

On Tue, Jun 21, 2011 at 1:09 PM, Chris Hostetter
<[EMAIL PROTECTED]> wrote:
>
> But there is no way for someone looking at the CHANGES for 4.0 to know
> for certain that the bits that make up that bug fix are in the 4.0 release
> -- the fact that it's listed in 3.2's CHANGES isn't an assurance, because
> 4.0 comes from a completely different line of development.
>

its in the 4.0 CHANGES.txt, under the 3.2 section.

---------------------------------------------------------------------

Robert,

Is the CHANGES.txt policy you advocate (and police) written up in one place?  I'm sure you'd like to not have to fix up everybody's entries....

Steve

> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 21, 2011 1:14 PM
> To: [EMAIL PROTECTED]
> Subject: Re: managing CHANGES.txt?
>
> On Tue, Jun 21, 2011 at 1:09 PM, Chris Hostetter
> <[EMAIL PROTECTED]> wrote:
> >
> > But there is no way for someone looking at the CHANGES for 4.0 to know
> > for certain that the bits that make up that bug fix are in the 4.0
> release
> > -- the fact that it's listed in 3.2's CHANGES isn't an assurance,
> because
> > 4.0 comes from a completely different line of development.
> >
>
> its in the 4.0 CHANGES.txt, under the 3.2 section.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

It wasn't anything i advocate, I'm just describing what it seems like
we do 99% of the time? (in my example, Uwe committed it, and I didnt
fix anything)

On Tue, Jun 21, 2011 at 1:23 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
> Robert,
>
> Is the CHANGES.txt policy you advocate (and police) written up in one place?  I'm sure you'd like to not have to fix up everybody's entries....
>
> Steve
>
>> -----Original Message-----
>> From: Robert Muir [mailto:[EMAIL PROTECTED]]
>> Sent: Tuesday, June 21, 2011 1:14 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: managing CHANGES.txt?
>>
>> On Tue, Jun 21, 2011 at 1:09 PM, Chris Hostetter
>> <[EMAIL PROTECTED]> wrote:
>> >
>> > But there is no way for someone looking at the CHANGES for 4.0 to know
>> > for certain that the bits that make up that bug fix are in the 4.0
>> release
>> > -- the fact that it's listed in 3.2's CHANGES isn't an assurance,
>> because
>> > 4.0 comes from a completely different line of development.
>> >
>>
>> its in the 4.0 CHANGES.txt, under the 3.2 section.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------

On 6/21/2011 at 1:26 PM, Robert Muir wrote:
> On Tue, Jun 21, 2011 at 1:23 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
> > Is the CHANGES.txt policy you advocate (and police) written up in one
> > place?  I'm sure you'd like to not have to fix up everybody's entries....
>
> It wasn't anything i advocate, I'm just describing what it seems like
> we do 99% of the time? (in my example, Uwe committed it, and I didnt
> fix anything)

I'm confused - seems like you're disavowing the role you've been playing as CHANGES policeman - yet I've seen at least 10 CHANGES-policing commits within the last six weeks?:

http://svn.apache.org/viewvc?rev=1137361&view=rev
http://svn.apache.org/viewvc?rev=1137359&view=rev
http://svn.apache.org/viewvc?rev=1130564&view=rev
http://svn.apache.org/viewvc?rev=1128248&view=rev
http://svn.apache.org/viewvc?rev=1128247&view=rev
http://svn.apache.org/viewvc?rev=1125127&view=rev
http://svn.apache.org/viewvc?rev=1125128&view=rev
http://svn.apache.org/viewvc?rev=1125134&view=rev
http://svn.apache.org/viewvc?rev=1125135&view=rev
http://svn.apache.org/viewvc?rev=1102119&view=rev

Again, you obviously have a concrete idea of what should be done - can you point to a writeup?

Thanks,
Steve

On Tue, Jun 21, 2011 at 1:47 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
> On 6/21/2011 at 1:26 PM, Robert Muir wrote:
>> On Tue, Jun 21, 2011 at 1:23 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
>> > Is the CHANGES.txt policy you advocate (and police) written up in one
>> > place?  I'm sure you'd like to not have to fix up everybody's entries....
>>
>> It wasn't anything i advocate, I'm just describing what it seems like
>> we do 99% of the time? (in my example, Uwe committed it, and I didnt
>> fix anything)
>
> I'm confused - seems like you're disavowing the role you've been playing as CHANGES policeman - yet I've seen at least 10 CHANGES-policing commits within the last six weeks?:
>

I do disavow this role: when CHANGES.txt is jacked up, i fix it, I
don't complain to anyone about it. I dont understand how this makes me
a policeman?

---------------------------------------------------------------------

On 6/21/2011 at 1:52 PM, Robert Muir wrote:
> On Tue, Jun 21, 2011 at 1:47 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
> > On 6/21/2011 at 1:26 PM, Robert Muir wrote:
> > > On Tue, Jun 21, 2011 at 1:23 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
> > > > Is the CHANGES.txt policy you advocate (and police) written up in
> > > > one place?  I'm sure you'd like to not have to fix up everybody's
> > > > entries....
> > >
> > > It wasn't anything i advocate, I'm just describing what it seems like
> > > we do 99% of the time? (in my example, Uwe committed it, and I didnt
> > > fix anything)
> >
> > I'm confused - seems like you're disavowing the role you've been
> > playing as CHANGES policeman - yet I've seen at least 10 CHANGES-
> > policing commits within the last six weeks?:
>
> I do disavow this role: when CHANGES.txt is jacked up, i fix it, I
> don't complain to anyone about it. I dont understand how this makes me
> a policeman?

CHANGES janitor???

Echoing Mark M., thanks for scrubbing.

I was looking to make it possible for others to share the load, by publicizing the target.

Steve

On Jun 21, 2011, at 1:47 PM, Steven A Rowe wrote:

>
>
> Again, you obviously have a concrete idea of what should be done - can you point to a writeup?
>
> Thanks,
> Steve
Thank you Robert for keeping Changes pretty.

-1 to more formalization, or "writeups". I've seen the opinions in the emails on the topic now and before. Writeups turn into more than they should be over time, half the time. They end up stale or over followed.

- Mark Miller
lucidimagination.com

---------------------------------------------------------------------

Mark,

Staleness is way better than digging through mail archives, guessing and getting it wrong, or re-invention.

Word of mouth doesn't scale.  The Lucene/Solr dev community is growing.

Where I see an opportunity to document current practice, where it is less than obvious what to do, I will, modulo free time of course.

Feel free to ignore my idiocy.

Steve

> -----Original Message-----
> From: Mark Miller [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 21, 2011 1:54 PM
> To: [EMAIL PROTECTED]
> Subject: Re: managing CHANGES.txt?
>
> On Jun 21, 2011, at 1:47 PM, Steven A Rowe wrote:
>
> > Again, you obviously have a concrete idea of what should be done - can
> you point to a writeup?
> >
> > Thanks,
> > Steve
>
>
> Thank you Robert for keeping Changes pretty.
>
> -1 to more formalization, or "writeups". I've seen the opinions in the
> emails on the topic now and before. Writeups turn into more than they
> should be over time, half the time. They end up stale or over followed.
>
> - Mark Miller
> lucidimagination.com

You 'remore prickly than me today Steve :)

You are of course free to document anything you see fit. And I'm free to weigh in on my opinion about documenting :)

That's how it works indeed, and it's a beautiful system.

- Mark

On Jun 21, 2011, at 2:08 PM, Steven A Rowe wrote:

> Mark,
>
> Staleness is way better than digging through mail archives, guessing and getting it wrong, or re-invention.
>
> Word of mouth doesn't scale.  The Lucene/Solr dev community is growing.
>
> Where I see an opportunity to document current practice, where it is less than obvious what to do, I will, modulo free time of course.
>
> Feel free to ignore my idiocy.
>
> Steve
>
>> -----Original Message-----
>> From: Mark Miller [mailto:[EMAIL PROTECTED]]
>> Sent: Tuesday, June 21, 2011 1:54 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: managing CHANGES.txt?
>>
>> On Jun 21, 2011, at 1:47 PM, Steven A Rowe wrote:
>>
>>> Again, you obviously have a concrete idea of what should be done - can
>> you point to a writeup?
>>>
>>> Thanks,
>>> Steve
>>
>>
>> Thank you Robert for keeping Changes pretty.
>>
>> -1 to more formalization, or "writeups". I've seen the opinions in the
>> emails on the topic now and before. Writeups turn into more than they
>> should be over time, half the time. They end up stale or over followed.
>>
>> - Mark Miller
>> lucidimagination.com
>

- Mark Miller
lucidimagination.com

---------------------------------------------------------------------

: > But there is no way for someone looking at the CHANGES for 4.0 to know
: > for certain that the bits that make up that bug fix are in the 4.0 release
: > -- the fact that it's listed in 3.2's CHANGES isn't an assurance, because
: > 4.0 comes from a completely different line of development.
...
: its in the 4.0 CHANGES.txt, under the 3.2 section.

(sigh ... i tried to let this go, i swear i did...)

You're missing my point entirely.  yes it's in the 3.2 section but all
that tells the user is that it was fixed on the 3x branch just prior to
the 3.2 release -- that doesn't give users *any* info about wether that
bug ever affected (or was fixed) on the completely and radically different
4x branch.  There were multiple commits -- the bits are not the same.
-Hoss

---------------------------------------------------------------------

On Tue, Jun 21, 2011 at 2:47 PM, Chris Hostetter
<[EMAIL PROTECTED]> wrote:
> You're missing my point entirely.  yes it's in the 3.2 section but all
> that tells the user is that it was fixed on the 3x branch just prior to
> the 3.2 release -- that doesn't give users *any* info about wether that
> bug ever affected (or was fixed) on the completely and radically different
> 4x branch.  There were multiple commits -- the bits are not the same.
>

Did 4.0 get released somehow without me noticing?

Users don't need to see whether the bug affected the 4.x branch.
There is no such thing.

4.0 is unreleased: if its a bug in 4.0, I generally add no CHANGES.txt
at all, unless its a non-committer contributing the patch, in which
case I add their name to the
new-4.0-feature-affected-by-the-bug-in-question.

There's no sense in CHANGES being a 'rolling list', when someone looks
at 4.0 they should be able to see whats DIFFERENT aka what CHANGED
from the past release.

The only possible use these rolling lists could have is for people
using trunk, but thats not its purpose: if you are using trunk, you
need to be subscribed to the commits@ list.

---------------------------------------------------------------------

: There's no sense in CHANGES being a 'rolling list', when someone looks
: at 4.0 they should be able to see whats DIFFERENT aka what CHANGED
: from the past release.

I agree completely, the disagreement is *which* past release the list
should be relative to.

I don't know how many more ways i can say it: I believe that the list of
changes for 4.0 should be labled (and contain) "Changes since 3.0" --
because that is the most recent "past release" sith a common development
history.

When we only had a single trunk and the 3.0 release branch was forked
from the same place as the 2.9 release branch it made sense to think of
the 3.0 changes list as "Changes since 2.9" because they were genuine
success of eachother -- any code in 2.9 was by definition in 3.0 unless it
was modified/removed by somehting listed in the 3.0 changes.

That is not going to be true for 3.3 and 4.0 (or 3.4 and 4.0, or 3.7 and
4.0 or whatever our last 3.x release is before 4.0).  

The list of changes
for a release should always make it clear *exactly* what is differnet
between that release and the previous release with common "lineage" of
source code -- it may sound weird, but it's what i believe and it's
consistent with how we've done bug fix releases in the past -- they've
refered to changes since their "parent" release, not since the last
calendar release.

Since no one seems to agree with me on this, I've tried to let this go
(twice!) by stating my position and conceeding that it's not concensus --
but if you keep reviving the argument, i'll happily keep restating my
beliefs.
-Hoss

---------------------------------------------------------------------

On Thu, Jun 30, 2011 at 6:02 PM, Chris Hostetter
<[EMAIL PROTECTED]> wrote:
>
> : There's no sense in CHANGES being a 'rolling list', when someone looks
> : at 4.0 they should be able to see whats DIFFERENT aka what CHANGED
> : from the past release.
>
> I agree completely, the disagreement is *which* past release the list
> should be relative to.

Definitely, at least we agree on something :)

>
> I don't know how many more ways i can say it: I believe that the list of
> changes for 4.0 should be labled (and contain) "Changes since 3.0" --
> because that is the most recent "past release" sith a common development
> history.
>

Right, I guess this is where I disagree. I think this is a
developer-oriented perspective: who cares about development history? A
user upgrading from Lucene 3.9 looks at 4.0's CHANGES.txt and wants to
know, what has changed since 3.9?

maybe they go straight from 3.8, in which case they read the 3.9
section underneath that too, but all of this is WAY easier than seeing
all the changes from 3.0 and trying to sort out what the hell is going
on.

seriously, i think 99% of the time my attitude is "to hell with the
users, lets do whats best for the devs since this is our project", but
as devs if we want to track things thru branches of development, we
can do this with tools like SVN... I think CHANGES.txt is for the
users.

If we decided to go your route, I would rather nuke CHANGES.txt
completely and create it from 'svn log'.

But as I said earlier, I don't think users care about the internal
details (such as svn branches and stuff) of how we produce our
artifacts. If they have 3.9 and they upgrade to 4.0 I think they just
want to know the differences: what are the new features, bugs fixed,
backwards breaks, how to upgrade, etc.

If I go and create my own branch from scratch tonight, code like a
madman and produce something i call 'lucene 3.4 release candidate' and
everyone votes +1 to release (not likely, but this is totally
possible), should its CHANGES.txt really contain all the differences
from 3.0? Or should it contain only the differences since the last
release (3.3)?

I don't think anyone cares how many branches I created or anything
like that, when they look at CHANGES.txt they just want to know what
changed since the last release.

---------------------------------------------------------------------

On Jun 30, 2011, at 9:00 PM, Robert Muir wrote:

> when they look at CHANGES.txt they just want to know what
> changed since the last release.
+1
- Mark Miller
lucidimagination.com

---------------------------------------------------------------------