Guys, stop this endless and pointless thread. You're both right.
or don't, if you think it helps keeping Lucene ecosystem healthy at the level
we are used to :)
From another perspective, strong emotions are only a signal to everybody that
someone cares, and that's good!
one side comment from
Hi all,
Since everyone seems to agree this is time for a release, I created a
lucene_solr_4_5 branch in our SVN repository. From now on, please
backport to this branch all changes that should go into a Lucene/Solr
4.5 release.
I'm going to work on updating the versions in the code base, JIRA
On Sep 12, 2013, at 12:41 AM, Shalin Shekhar Mangar shalinman...@gmail.com
wrote:
We might as well build a bot which cuts releases at
random times.
Right - if these guys start releasing right now at any point, I'd start doing
a proper release a week or two after them.
- Mark
Hi,
Versions have been updated in trunk and branch_4x. I started writing
release notes drafts[1][2] but I'm pretty sure they are terrible, feel
free to reword existing entries or add new ones for important changes.
[1] https://wiki.apache.org/lucene-java/ReleaseNote45
[2]
On Sep 12, 2013, at 12:46 AM, Shai Erera ser...@gmail.com wrote:
It's enough to handle them, and we don't need to risk more issues by allowing
last-minute features too.
It doesn't work like that. Committers are not bound by general statements and
rules like this. The reason I like the
On Sep 12, 2013, at 11:07 AM, Robert Muir rcm...@gmail.com wrote:
The give me several weeks to shove shit in and destabilize the
codebase is worse.
It's a false dichotomey for a start - it's also a wild exageration.
Its no exaggeration at all. This situation actually happened to me
several
On Thu, Sep 12, 2013 at 10:56 AM, Mark Miller markrmil...@gmail.com wrote:
The release right now idea is very rude and anti community.
The give me several weeks to shove shit in and destabilize the
codebase is worse.
-
To
On Sep 12, 2013, at 11:07 AM, Robert Muir rcm...@gmail.com wrote:
The give me several weeks to shove shit in and destabilize the
codebase is worse.
It's a false dichotomey for a start - it's also a wild exageration.
It's also a nasty judgment of your fellow committers - I see you have been
On Thu, Sep 12, 2013 at 10:56 AM, Mark Miller markrmil...@gmail.com wrote:
And random releases *create* last minute features when a dev did not intend
it
I don't understand that statement: if the dev did not intend on a
feature being released, why did that dev commit it to the 4.x (stable)
On Sep 12, 2013, at 12:18 PM, Shai Erera ser...@gmail.com wrote:
I never spoke about random immediate releases.
Yeah, sorry - I responded to you and then to the thread. Didn't mean to imply
that you argued for that - my reply to you was in terms of what can make it in.
All I said is that
On Sep 12, 2013, at 12:24 PM, Michael McCandless luc...@mikemccandless.com
wrote:
I don't understand that statement: if the dev did not intend on a
feature being released, why did that dev commit it to the 4.x (stable)
branch?
I don't develop that way, and I know a lot of others don't
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
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
On Sep 12, 2013, at 11:30 AM, Robert Muir rcm...@gmail.com wrote:
On Sep 12, 2013, at 11:07 AM, Robert Muir rcm...@gmail.com wrote:
The give me several weeks to shove shit in and destabilize the
codebase is worse.
It's a false dichotomey for a start - it's also a wild exageration.
Not sure what you are getting at here either. I'm not trying to make the
situation something other than it is. I don't think I even know what
situation you are talking about.
To me it's like this - you are obsessed with shoving stuff in. I don't care
about your opinion on that when it
!) guys need more frequent releases, just start
the process earlier.
-- Jack Krupansky
-Original Message-
From: Robert Muir
Sent: Thursday, September 12, 2013 11:30 AM
To: dev@lucene.apache.org
Subject: Re: Lucene/Solr 4.5
On Sep 12, 2013, at 11:07 AM, Robert Muir rcm...@gmail.com wrote
On Sep 12, 2013, at 11:45 AM, Robert Muir rcm...@gmail.com wrote:
I guess its ok that we disagree: fortunately you cannot veto releases,
so its up to the individual release manager.
I can throw up a RC right now and if 2 other people think its ok, its
out the door.
If i start to see the
I never spoke about random immediate releases. All I said is that we should
branch early, then give some time for people before the RC is cut.
Branching early, I think, puts less risk that something random will get in.
If you need to port something to the branch, you know it's the release
branch.
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
Subject: Re: Lucene/Solr 4.5
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
On 9/12/2013 12:57 PM, Robert Muir wrote:
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
: Guys, stop this endless and pointless thread. You're both right. You
: should not have unstable code in a stable branch, that should be on
: trunk. This said, you should not spring out RCs without warning. Some
: stuff may actually be in trunk ready to be merged if you give a heads
: up, or
Hi,
I was looking at the changelogs for Lucene and Solr and I think they
look pretty good. What would you think about realeasing Lucene/Solr
4.5, are there issues you would like to get in before the release?
--
Adrien
+1 to release 4.5.
Mike McCandless
http://blog.mikemccandless.com
On Wed, Sep 11, 2013 at 9:40 AM, Adrien Grand jpou...@gmail.com wrote:
Hi,
I was looking at the changelogs for Lucene and Solr and I think they
look pretty good. What would you think about realeasing Lucene/Solr
4.5
Krupansky
-Original Message- From: Adrien Grand
Sent: Wednesday, September 11, 2013 9:40 AM
To: dev@lucene.apache.org
Subject: Lucene/Solr 4.5
Hi,
I was looking at the changelogs for Lucene and Solr and I think they
look pretty good. What would you think about realeasing Lucene/Solr
4.5
- From: Adrien Grand
Sent: Wednesday, September 11, 2013 9:40 AM
To: dev@lucene.apache.org
Subject: Lucene/Solr 4.5
Hi,
I was looking at the changelogs for Lucene and Solr and I think they
look pretty good. What would you think about realeasing Lucene/Solr
4.5, are there issues you
, with the risk
of an RC1 a few days or a week later.
Otherwise, +1.
-- Jack Krupansky
-Original Message-
From: Adrien Grand
Sent: Wednesday, September 11, 2013 9:40 AM
To: dev@lucene.apache.org
Subject: Lucene/Solr 4.5
Hi,
I was looking at the changelogs for Lucene and Solr and I think
Unless someone else volunteers to do the release, I'll be busy until
~wednesday next week so there are still a few days to get fixes in
anyway. However I agree with Robert that our branch_4x should always
be stable and releasable.
@Jack, @Erick could you share more details about the issues that
I just want to mention that blockjoin update behaves unexpectedly sometime.
https://issues.apache.org/jira/browse/SOLR-5211
if parent with children is overwritten by parent without children orphan
children stick to the next parent _after_ merge.
I'm not sure about severity, just want to let you
@lucene.apache.org
Subject: Lucene/Solr 4.5
Hi,
I was looking at the changelogs for Lucene and Solr and I think they
look pretty good. What would you think about realeasing Lucene/Solr
4.5, are there issues you would like to get in before the release?
--
Adrien
I still believe, as I have voted before, that because we are a community of
developers spread across the world and work space, we should have some warning
for releases - we are collaborating here - people should have a bit of time to
tie up loose ends, investigate reports, weigh in about the
Grand
Sent: Wednesday, September 11, 2013 9:40 AM
To: dev@lucene.apache.org
Subject: Lucene/Solr 4.5
Hi,
I was looking at the changelogs for Lucene and Solr and I think they
look pretty good. What would you think about realeasing Lucene/Solr
4.5, are there issues you would like to get
.
-- Jack Krupansky
-Original Message- From: Adrien Grand
Sent: Wednesday, September 11, 2013 9:40 AM
To: dev@lucene.apache.org
Subject: Lucene/Solr 4.5
Hi,
I was looking at the changelogs for Lucene and Solr and I think they
look pretty good. What would you think about
+1, a week at minimum seems very reasonable.
-Yonik
http://lucidworks.com
On Wed, Sep 11, 2013 at 3:00 PM, Mark Miller markrmil...@gmail.com wrote:
I still believe, as I have voted before, that because we are a community of
developers spread across the world and work space, we should have
+1 for a week at a minimum.
I don't understand this trend of cutting releases *right now*. Whom
does that help? We might as well build a bot which cuts releases at
random times.
On Thu, Sep 12, 2013 at 12:30 AM, Mark Miller markrmil...@gmail.com wrote:
I still believe, as I have voted before,
Let's differentiate between feature-freeze and bug-fix freeze. IMO, we
should cut a branch_45 now, or as early as the RM intends to start
working on the release. At that point, no new features should go into 4.5
anymore. If an issue hasn't been committed until then, I see no reason for
it to get
36 matches
Mail list logo
