As a followup to the thread "[DISCUSS] define what/when a 4.0-beta
should be" (http://find.searchhub.org/document/76862e33bce71ca7), we
have had 4.0-BETA out nearly a month now.

I think its time to look at the final release: this has taken forever :)

As a start I moved all JIRA issues not touched in over a month to 4.1.
If you don't like that, move it back/assign it/patch it/commit it,
please help get it fixed.

It would be nice to be able to use JIRA to assess what really needs to
be done: I feel like we are close but don't want to exclude any
important bugfixes or anything like that if we can make the release
solid. So please review the issues you still have slated for 4.0, and
if you aren't planning on working on them in like, the next few days,
or if its really not necessary and can work out nicely in a 4.1,
please push them out.

--
lucidworks.com

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

I've got a variety of very important fixes I have accumulated over the
past couple weeks in my quest to make SolrCloud fault tolerance
"rock-solid" before the 4 release. Things are starting to look pretty
great, and I hope to get these fixes in over the next couple days.

- Mark

On Mon, Sep 10, 2012 at 1:50 PM, Robert Muir <[EMAIL PROTECTED]> wrote:
> As a followup to the thread "[DISCUSS] define what/when a 4.0-beta
> should be" (http://find.searchhub.org/document/76862e33bce71ca7), we
> have had 4.0-BETA out nearly a month now.
>
> I think its time to look at the final release: this has taken forever :)
>
> As a start I moved all JIRA issues not touched in over a month to 4.1.
> If you don't like that, move it back/assign it/patch it/commit it,
> please help get it fixed.
>
> It would be nice to be able to use JIRA to assess what really needs to
> be done: I feel like we are close but don't want to exclude any
> important bugfixes or anything like that if we can make the release
> solid. So please review the issues you still have slated for 4.0, and
> if you aren't planning on working on them in like, the next few days,
> or if its really not necessary and can work out nicely in a 4.1,
> please push them out.
>
> --
> lucidworks.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

--
- Mark

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

sounds great.

maybe we can do something to mark these so they are clear? (add some
tag or priority=Critical or something?)

I was just thinking if we can somehow make jira less of a wasteland
for fixVersion=4.0, it would help us actually get this thing out and
feel good about it.

On Mon, Sep 10, 2012 at 5:53 PM, Mark Miller <[EMAIL PROTECTED]> wrote:
> I've got a variety of very important fixes I have accumulated over the
> past couple weeks in my quest to make SolrCloud fault tolerance
> "rock-solid" before the 4 release. Things are starting to look pretty
> great, and I hope to get these fixes in over the next couple days.
>
> - Mark
>
> On Mon, Sep 10, 2012 at 1:50 PM, Robert Muir <[EMAIL PROTECTED]> wrote:
>> As a followup to the thread "[DISCUSS] define what/when a 4.0-beta
>> should be" (http://find.searchhub.org/document/76862e33bce71ca7), we
>> have had 4.0-BETA out nearly a month now.
>>
>> I think its time to look at the final release: this has taken forever :)
>>
>> As a start I moved all JIRA issues not touched in over a month to 4.1.
>> If you don't like that, move it back/assign it/patch it/commit it,
>> please help get it fixed.
>>
>> It would be nice to be able to use JIRA to assess what really needs to
>> be done: I feel like we are close but don't want to exclude any
>> important bugfixes or anything like that if we can make the release
>> solid. So please review the issues you still have slated for 4.0, and
>> if you aren't planning on working on them in like, the next few days,
>> or if its really not necessary and can work out nicely in a 4.1,
>> please push them out.
>>
>> --
>> lucidworks.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
>
>
> --
> - Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

--
lucidworks.com

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

+1 to get 4.0 out soon.

Looks like there are still 49 Solr issues marked for 4.0:

    https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+SOLR+AND+resolution+%3D+Unresolved+AND+fixVersion+%3D+%224.0%22+ORDER+BY+priority+DESC

Three of which are blockers, but seem to be progressing.  I think we
should move the rest out to 4.1, and if there are objections, people
should move them back to 4.0 and mark them blocker?

And 7 Lucene issues:

  https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+Lucene+AND+resolution+%3D+Unresolved+AND+fixVersion+%3D+%224.0%22+ORDER+BY+priority+DESC

None of which are blockers.

There will be a 4.1 soon after 4.0 so we should not hold up 4.0 for
issues that can wait...

Mike McCandless

http://blog.mikemccandless.com
On Mon, Sep 10, 2012 at 5:53 PM, Mark Miller <[EMAIL PROTECTED]> wrote:
> I've got a variety of very important fixes I have accumulated over the
> past couple weeks in my quest to make SolrCloud fault tolerance
> "rock-solid" before the 4 release. Things are starting to look pretty
> great, and I hope to get these fixes in over the next couple days.
>
> - Mark
>
> On Mon, Sep 10, 2012 at 1:50 PM, Robert Muir <[EMAIL PROTECTED]> wrote:
>> As a followup to the thread "[DISCUSS] define what/when a 4.0-beta
>> should be" (http://find.searchhub.org/document/76862e33bce71ca7), we
>> have had 4.0-BETA out nearly a month now.
>>
>> I think its time to look at the final release: this has taken forever :)
>>
>> As a start I moved all JIRA issues not touched in over a month to 4.1.
>> If you don't like that, move it back/assign it/patch it/commit it,
>> please help get it fixed.
>>
>> It would be nice to be able to use JIRA to assess what really needs to
>> be done: I feel like we are close but don't want to exclude any
>> important bugfixes or anything like that if we can make the release
>> solid. So please review the issues you still have slated for 4.0, and
>> if you aren't planning on working on them in like, the next few days,
>> or if its really not necessary and can work out nicely in a 4.1,
>> please push them out.
>>
>> --
>> lucidworks.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
>
>
> --
> - Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

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

On Fri, Sep 14, 2012 at 10:43 AM, Michael McCandless
<[EMAIL PROTECTED]> wrote:
> +1 to get 4.0 out soon.
>
> Looks like there are still 49 Solr issues marked for 4.0:
>
>     https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+SOLR+AND+resolution+%3D+Unresolved+AND+fixVersion+%3D+%224.0%22+ORDER+BY+priority+DESC
>
> Three of which are blockers, but seem to be progressing.  I think we
> should move the rest out to 4.1, and if there are objections, people
> should move them back to 4.0 and mark them blocker?

Well I know mark has some issues he has been working on that he would
like to get in (see previous notes on this thread). I think some are
marked critical but I'm not sure all.

We should at least move out all 6 of the _Unassigned_ issues as a
start. I think as far as other issues, mark them critical or blocker,
or get them committed or whatever.

>
> And 7 Lucene issues:
>
>   https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+Lucene+AND+resolution+%3D+Unresolved+AND+fixVersion+%3D+%224.0%22+ORDER+BY+priority+DESC
>
> None of which are blockers.
>

Same as the above: all but 2 are unassigned, though I know David is
working on at least one of the spatial issues.

For both projects, please Assign if you are planning on working on
stuff. If you aren't planning on working on it very soon now, unassign
yourself or move it to 4.1

I want to move the unassigned ones out at the end of the day.

--
lucidworks.com

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

2012/9/14 Robert Muir <[EMAIL PROTECTED]>

> On Fri, Sep 14, 2012 at 10:43 AM, Michael McCandless
> <[EMAIL PROTECTED]> wrote:
> > +1 to get 4.0 out soon.
> >
> > Looks like there are still 49 Solr issues marked for 4.0:
> >
> >
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+SOLR+AND+resolution+%3D+Unresolved+AND+fixVersion+%3D+%224.0%22+ORDER+BY+priority+DESC
> >
> > Three of which are blockers, but seem to be progressing.  I think we
> > should move the rest out to 4.1, and if there are objections, people
> > should move them back to 4.0 and mark them blocker?
>
> Well I know mark has some issues he has been working on that he would
> like to get in (see previous notes on this thread). I think some are
> marked critical but I'm not sure all.
>
> We should at least move out all 6 of the _Unassigned_ issues as a
> start. I think as far as other issues, mark them critical or blocker,
> or get them committed or whatever.
>

talking about SolrCloud (I don't know if this is already on Mark's list of
things to get in) I think we should try to let
https://issues.apache.org/jira/browse/SOLR-3488 in too.
>
> >
> > And 7 Lucene issues:
> >
> >
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+Lucene+AND+resolution+%3D+Unresolved+AND+fixVersion+%3D+%224.0%22+ORDER+BY+priority+DESC
> >
> > None of which are blockers.
> >
>
> Same as the above: all but 2 are unassigned, though I know David is
> working on at least one of the spatial issues.
>
>
>
> For both projects, please Assign if you are planning on working on
> stuff. If you aren't planning on working on it very soon now, unassign
> yourself or move it to 4.1
>
> I want to move the unassigned ones out at the end of the day.
>

+1

Tommaso
>
> --
> lucidworks.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Hi Rob.
I think it's fairly critical that at least some of the Solr spatial adapters
get committed SOLR-3304.  I've been working on it and related issues like
LUCENE-4208.
~ David

-----
 Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: http://lucene.472066.n3.nabble.com/4-0-planning-tp4006692p4007774.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

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

On Fri, Sep 14, 2012 at 11:13 AM, David Smiley (@MITRE.org)
<[EMAIL PROTECTED]> wrote:
> Hi Rob.
> I think it's fairly critical that at least some of the Solr spatial adapters
> get committed SOLR-3304.  I've been working on it and related issues like
> LUCENE-4208.
> ~ David
>

As far as new features like cloud management APIs or spatial features,
really i don't know how important it is.

I'm seriously not gonna push back on this stuff, I'm just going to
reiterate Mike's point about 4.1/4.2: we can drag out 4.0 to december
2014 for all I care adding feature after feature (and then dealing
with bugs that come from that), or we can get it out soon and work on
4.1, 4.2, 4.3, ...

--
lucidworks.com

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

2012/9/14 Robert Muir <[EMAIL PROTECTED]>

> On Fri, Sep 14, 2012 at 11:13 AM, David Smiley (@MITRE.org)
> <[EMAIL PROTECTED]> wrote:
> > Hi Rob.
> > I think it's fairly critical that at least some of the Solr spatial
> adapters
> > get committed SOLR-3304.  I've been working on it and related issues like
> > LUCENE-4208.
> > ~ David
> >
>
> As far as new features like cloud management APIs or spatial features,
> really i don't know how important it is.
>
> I'm seriously not gonna push back on this stuff, I'm just going to
> reiterate Mike's point about 4.1/4.2: we can drag out 4.0 to december
> 2014 for all I care adding feature after feature (and then dealing
> with bugs that come from that), or we can get it out soon and work on
> 4.1, 4.2, 4.3, ...
>

I see your point, second option sounds much better.
We could perhaps make a shortly due roadmap like:
- fix whatever you want by date x (2/3/4 weeks)
- code freeze for 1/2 weeks
- release
- celebrate :-)
Regards,
Tommaso
>
> --
> lucidworks.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

I say roll the RC for 4.0-GA on Monday (if not on the weekend or end of
today) with the promise of an early 4.1 for anything that can't be done by
Monday. As long as the remaining issues are not serious regressions from
3.6.1 or 4.0-BETA.

A max of 4 weeks "development" for 4.1 would be a good target after 4.0 to
assure that incomplete and untested features get addressed in a timely
manner for 4.0 early adopters.

As long as the 4.0 RC is clearly better than 3.6.1 and 4.0-BETA, what's to
lose?

-- Jack Krupansky

-----Original Message-----
From: Robert Muir
Sent: Friday, September 14, 2012 11:20 AM
To: [EMAIL PROTECTED]
Subject: Re: 4.0 planning

On Fri, Sep 14, 2012 at 11:13 AM, David Smiley (@MITRE.org)
<[EMAIL PROTECTED]> wrote:
> Hi Rob.
> I think it's fairly critical that at least some of the Solr spatial
> adapters
> get committed SOLR-3304.  I've been working on it and related issues like
> LUCENE-4208.
> ~ David
>

As far as new features like cloud management APIs or spatial features,
really i don't know how important it is.

I'm seriously not gonna push back on this stuff, I'm just going to
reiterate Mike's point about 4.1/4.2: we can drag out 4.0 to december
2014 for all I care adding feature after feature (and then dealing
with bugs that come from that), or we can get it out soon and work on
4.1, 4.2, 4.3, ...

--
lucidworks.com

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

On Fri, Sep 14, 2012 at 11:27 AM, Tommaso Teofili
<[EMAIL PROTECTED]> wrote:
>
> I see your point, second option sounds much better.
> We could perhaps make a shortly due roadmap like:
> - fix whatever you want by date x (2/3/4 weeks)
> - code freeze for 1/2 weeks
> - release
> - celebrate :-)

Personally I would prefer we don't do the first part. Adding some
arbitrary length of time like this to fix whatever you want invites a
"code-shoving" period where people are encouraged to rush things in to
get them by XYZ date.

This can basically cause a huge destabilization of the codebase, and
its totally unnecessary.

I would prefer we wind down now and do bugs, docs, tests, and
blockers. I don't like official code freezes either, I feel like we
can just work together on this and do what makes sense.

--
lucidworks.com

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

2012/9/14 Robert Muir <[EMAIL PROTECTED]>

> On Fri, Sep 14, 2012 at 11:27 AM, Tommaso Teofili
> <[EMAIL PROTECTED]> wrote:
> >
> > I see your point, second option sounds much better.
> > We could perhaps make a shortly due roadmap like:
> > - fix whatever you want by date x (2/3/4 weeks)
> > - code freeze for 1/2 weeks
> > - release
> > - celebrate :-)
>
> Personally I would prefer we don't do the first part. Adding some
> arbitrary length of time like this to fix whatever you want invites a
> "code-shoving" period where people are encouraged to rush things in to
> get them by XYZ date.
>
> This can basically cause a huge destabilization of the codebase, and
> its totally unnecessary.
>

good point.
>
> I would prefer we wind down now and do bugs, docs, tests, and
> blockers. I don't like official code freezes either, I feel like we
> can just work together on this and do what makes sense.
>

that's fine with me, let's do that ;)
Tommaso
>
> --
> lucidworks.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>