I don't disagree with the stability goal. The difficulty is that stability
is rather subjective. One person's "just a few bugs to fix or partial
features to flesh out over a few weeks" is another person's "major stability
problems."
Yes, we should try to encourage better testing before that initial commit.
But... a lot of people prefer an incremental, agile process with frequent
commits. Maybe the real issue here is that a truly agile process would
insist on better tests early in the process. Then, the code really would be
releasable at any time - it just wouldn't have as many features.
The main point for this discussion is that after a "initial feature freeze"
date, any sort of "big", "major", "invasive", "incomplete" sort of commits
would be essentially absolutely "forbidden". There may be disagreement about
ever doing a stable branch commit of that sort, but I'm not sure that will
be resolved in the near future. At least with this "initial feature freeze"
date we move a step closer to a larger degree of stability on the stable
branch.
And the other purpose for "initial feature freeze" date and advance notice
is simply to recognize that complex software just takes more time to bake.
Especially at a time like now, when summer vacations, back to school, etc.,
make it more difficult for people to focus on the same level of quality in
very short spans of time.
I superficially agree that trunk is a better place to do larger and
potentially less stable changes, but I think the problem is that it seems
that trunk is too far away from the stable branch and it just seems more
productive to "iterate" on both in parallel rather than do a lot of
iterating on trunk and then have to recreate a long iteration sequence on
the stable branch. The faster code gets into the stable branch, the faster
and more thoroughly people will test it out.
-- Jack Krupansky
-----Original Message-----
From: Robert Muir
Sent: Thursday, September 12, 2013 12:05 PM
To: dev@lucene.apache.org
Subject: Re: Lucene/Solr 4.5
On Thu, Sep 12, 2013 at 11:59 AM, Jack Krupansky
<j...@basetechnology.com> wrote:
I don't think anyone in Solr land is objecting to more frequent releases,
just with a little more notice.
I wouldn't object to a release every two months... or even every month.
Just
give a clear notice of three freeze dates:
1. Initial Feature Freeze. Initial commit of a big new change that may
take
more than two weeks to stabilize, or any significant change in progress
that
is having stability issues or is significantly incomplete as of its latest
commit.
If some change is having stability issues, dont put it in the stable branch.
don't commit half-baked shit to the stable branch, it defeats the purpose.
iterate and do that crap in trunk, thats what its for.
keep the stable branch stable so we can release quickly from it
without a long-drawn out process waiting for solr to fix itself.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
