You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@lucene.apache.org by Simon Willnauer <si...@gmail.com> on 2014/02/20 21:52:12 UTC

[VOTE] Lucene / Solr 4.7.0 RC3

Please vote for the third Release Candidate for Lucene/Solr 4.7.0

you can download it here:
http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC3-rev1570248/

or run the smoke tester directly with this commandline (don't forget
to set JAVA6_HOME etc.):

$ python3.2 -u dev-tools/scripts/smokeTestRelease.py
http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC3-rev1570248/
1570248 4.7.0 /tmp/smoke_test_4_7

Smoketester said: SUCCESS!

here is my +1

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Steve Rowe <sa...@gmail.com>.

+1, I like it :)

Probably should only check the changes in the first release section though - I know I don’t want to go back and fix up thousands of issues.

Steve

On Feb 21, 2014, at 10:05 AM, Robert Muir <rc...@gmail.com> wrote:

> 
> On Fri, Feb 21, 2014 at 6:31 AM, Martijn v Groningen <ma...@gmail.com> wrote:
> 
> Only spotted a small docs typo in the Lucene CHANGES.txt, the second issue under "Changes in Runtime Behavior" should be LUCENE-5399 instead of LUCENE-4399.
>  
> A crazy idea: The smoketester knows which release its testing, its theoretically possible that when validating CHANGES it could use the JIRA REST api to check that Fix-Version is consistent with that for each change.
> 
> This might catch problems like this automatically (e.g. it would complain that LUCENE-4399 has no Fix-Version 4.7).


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Robert Muir <rc...@gmail.com>.

On Fri, Feb 21, 2014 at 6:31 AM, Martijn v Groningen <
martijn.v.groningen@gmail.com> wrote:

>
> Only spotted a small docs typo in the Lucene CHANGES.txt, the second issue
> under "Changes in Runtime Behavior" should be LUCENE-5399 instead of
> LUCENE-4399.
>

A crazy idea: The smoketester knows which release its testing, its
theoretically possible that when validating CHANGES it could use the JIRA
REST api to check that Fix-Version is consistent with that for each change.

This might catch problems like this automatically (e.g. it would complain
that LUCENE-4399 has no Fix-Version 4.7).

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Robert Muir <rc...@gmail.com>.

just my thoughts:

On Fri, Feb 21, 2014 at 9:34 AM, Simon Willnauer
<si...@gmail.com>wrote:

> So the problem here is where to draw the line. I think in a setup like
> we have with lucene and solr in one codebase the chance to hit a bug
> within these 72h is huge.

I agree with this. The question is, which bugs should block a release and
which should not?

We should think of the impact they have on the users, but at the same time
we should think of the impact on users that *not* releasing has: there are
plenty of important bugfixes here. We should also keep in mind when the
bugs in question were introduced (are they new in this release, etc).

> This means the Release process is a huge
> pain each time.

I do agree its too hard on the release manager. If you want a quality
release, its still too hard. You basically have to be dedicated to just
that task for a potentially long time. We should think of ways to improve
this.

> Then we have bugs that justify a respin and some who
> don't. I looked at SOLR-5762 and it seems this one should cause a
> respin but the LUCENE-5461 doesn't. It's hard to draw that line since
> its pretty much up to the RM and then you get heat if you draw that
> line. IMO we should improve our release process and release a point
> release every week shortening the vote period for that to maybe 24h.
>

As far as releasing more often, no argument from me: except as mentioned
above, I don't think we are really setup for that right now yet.

On the other hand, I think the 72h window is fine. I think the motivation
behind it is good, it ensures everyone has a chance. Even if you shorten it
to 24h: give me 24h and the challenge to find a bug somewhere in this
codebase, I guarantee you I can do it. So I think the real issue is about
*which* bugs should block the release.

> That way we can get stuff out quickly and don't spend weeks on the
> release process.
>
> I will call this vote here as failed and build a new RC once SOLR-5762 is
> in.
>

Looks like this is a backwards compatibility break in this encoder/decoder.
Is it not possible to have a backwards compatibility test for this? It
could be similar to lucene's TestBackwardsCompatibility, just some
serialized stuff that gets deserialized by the test and checked. If such a
test existed, maybe this would not have come up during the release vote but
would have been caught during development.

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Simon Willnauer <si...@gmail.com>.

new build is running, thanks nobel.

On Sat, Feb 22, 2014 at 7:53 AM, Noble Paul നോബിള്‍  नोब्ळ्
<no...@gmail.com> wrote:
> Backward incompatibility is something that should be considered as a
> blocker.
>
> Anyway , I have fixed the issue in 4.7 branch. I have also fixed the
> SOLR-3854 omission
>
>
> You can respin a build
>
> On Sat, Feb 22, 2014 at 1:10 AM, Simon Willnauer <si...@gmail.com>
> wrote:
>>
>> Thanks nobel! can you please ping me here so I can kick off another RC.
>>
>> Regarding the bugs that should / should not block a release I think
>> it's hard to say which one should and that is my biggest problem here.
>> I think with more frequent releases and more point releases we can
>> make the intervals shorter and bugs get fixed quicker. I think it's
>> also the responsibility of the other committers to maybe go back a
>> step and ask themself if a bug should block a release and only if the
>> are absolutely +1 on respin mention it on the release thread? To me as
>> a RM it's really hard to draw the line. I also think we should not
>> push stuff into the release branch unless it's the cause of the
>> respin, we should work towards a stable branch an every change makes
>> it less stable again IMO.
>>
>> just my $0.05
>>
>> On Fri, Feb 21, 2014 at 6:35 PM, Noble Paul നോബിള്‍  नोब्ळ्
>> <no...@gmail.com> wrote:
>> > I'm working on a test case for 5762 I'll commit it tomorrow IST
>> >
>> > On 21 Feb 2014 20:05, "Simon Willnauer" <si...@gmail.com>
>> > wrote:
>> >>
>> >> So the problem here is where to draw the line. I think in a setup like
>> >> we have with lucene and solr in one codebase the chance to hit a bug
>> >> within these 72h is huge. This means the Release process is a huge
>> >> pain each time. Then we have bugs that justify a respin and some who
>> >> don't. I looked at SOLR-5762 and it seems this one should cause a
>> >> respin but the LUCENE-5461 doesn't. It's hard to draw that line since
>> >> its pretty much up to the RM and then you get heat if you draw that
>> >> line. IMO we should improve our release process and release a point
>> >> release every week shortening the vote period for that to maybe 24h.
>> >> That way we can get stuff out quickly and don't spend weeks on the
>> >> release process.
>> >>
>> >> I will call this vote here as failed and build a new RC once SOLR-5762
>> >> is
>> >> in.
>> >>
>> >> simon
>> >>
>> >> On Fri, Feb 21, 2014 at 3:23 PM, Steve Rowe <sa...@gmail.com> wrote:
>> >> > I volunteer to be 4.7.1 RM.
>> >> >
>> >> > I’d prefer to delay the 4.7.0 release to include all known bugfixes,
>> >> > though.
>> >> >
>> >> > Simon, if you’re okay with it, I could take over as 4.7.0 RM and
>> >> > handle
>> >> > any respins.  If not, it’s your prerogative to continue with the
>> >> > current RC
>> >> > vote; others can express their opinions by voting.  I’m sure it’ll be
>> >> > fine
>> >> > either way.
>> >> >
>> >> > Steve
>> >> >
>> >> > On Feb 21, 2014, at 8:19 AM, Simon Willnauer
>> >> > <si...@gmail.com>
>> >> > wrote:
>> >> >
>> >> >> Guys, I don't think we will ever get to the point where there is not
>> >> >> a
>> >> >> bug. But we have to draw a line here. If we respin I have to step
>> >> >> back
>> >> >> as the RM since I just can't spend more than 7 days on this. I think
>> >> >> there should be a 4.7.1 at some point where you can get your bugs
>> >> >> fixed as everybody else but we have to draw a line here. I think I
>> >> >> am
>> >> >> going to draw it here with the 3 +1 I am having.
>> >> >>
>> >> >> simon
>> >> >>
>> >> >> On Fri, Feb 21, 2014 at 2:12 PM, Tomás Fernández Löbbe
>> >> >> <to...@gmail.com> wrote:
>> >> >>> Question here. Shouldn't SOLR-5762 be fixed before 4.7? My
>> >> >>> understanding is
>> >> >>> that if not, Solr 4.7 won't be able to work with SolrJ from 4.6.1
>> >> >>> or
>> >> >>> earlier?
>> >> >>>
>> >> >>>
>> >> >>> On Fri, Feb 21, 2014 at 5:01 AM, Robert Muir <rc...@gmail.com>
>> >> >>> wrote:
>> >> >>>>
>> >> >>>>
>> >> >>>> And I think it should be under optimizations not changes in
>> >> >>>> behavior.
>> >> >>>>
>> >> >>>> On Fri, Feb 21, 2014 at 6:31 AM, Martijn v Groningen
>> >> >>>> <ma...@gmail.com> wrote:
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> Only spotted a small docs typo in the Lucene CHANGES.txt, the
>> >> >>>>> second
>> >> >>>>> issue under "Changes in Runtime Behavior" should be LUCENE-5399
>> >> >>>>> instead of
>> >> >>>>> LUCENE-4399.
>> >> >>>>>
>> >> >>>>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> 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
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
>
> --
> -----------------------------------------------------
> Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Noble Paul നോബിള്‍ नोब्ळ् <no...@gmail.com>.

Backward incompatibility is something that should be considered as a
blocker.

Anyway , I have fixed the issue in 4.7 branch. I have also fixed the
SOLR-3854 omission


You can respin a build

On Sat, Feb 22, 2014 at 1:10 AM, Simon Willnauer
<si...@gmail.com>wrote:

> Thanks nobel! can you please ping me here so I can kick off another RC.
>
> Regarding the bugs that should / should not block a release I think
> it's hard to say which one should and that is my biggest problem here.
> I think with more frequent releases and more point releases we can
> make the intervals shorter and bugs get fixed quicker. I think it's
> also the responsibility of the other committers to maybe go back a
> step and ask themself if a bug should block a release and only if the
> are absolutely +1 on respin mention it on the release thread? To me as
> a RM it's really hard to draw the line. I also think we should not
> push stuff into the release branch unless it's the cause of the
> respin, we should work towards a stable branch an every change makes
> it less stable again IMO.
>
> just my $0.05
>
> On Fri, Feb 21, 2014 at 6:35 PM, Noble Paul നോബിള്‍  नोब्ळ्
> <no...@gmail.com> wrote:
> > I'm working on a test case for 5762 I'll commit it tomorrow IST
> >
> > On 21 Feb 2014 20:05, "Simon Willnauer" <si...@gmail.com>
> wrote:
> >>
> >> So the problem here is where to draw the line. I think in a setup like
> >> we have with lucene and solr in one codebase the chance to hit a bug
> >> within these 72h is huge. This means the Release process is a huge
> >> pain each time. Then we have bugs that justify a respin and some who
> >> don't. I looked at SOLR-5762 and it seems this one should cause a
> >> respin but the LUCENE-5461 doesn't. It's hard to draw that line since
> >> its pretty much up to the RM and then you get heat if you draw that
> >> line. IMO we should improve our release process and release a point
> >> release every week shortening the vote period for that to maybe 24h.
> >> That way we can get stuff out quickly and don't spend weeks on the
> >> release process.
> >>
> >> I will call this vote here as failed and build a new RC once SOLR-5762
> is
> >> in.
> >>
> >> simon
> >>
> >> On Fri, Feb 21, 2014 at 3:23 PM, Steve Rowe <sa...@gmail.com> wrote:
> >> > I volunteer to be 4.7.1 RM.
> >> >
> >> > I’d prefer to delay the 4.7.0 release to include all known bugfixes,
> >> > though.
> >> >
> >> > Simon, if you’re okay with it, I could take over as 4.7.0 RM and
> handle
> >> > any respins.  If not, it’s your prerogative to continue with the
> current RC
> >> > vote; others can express their opinions by voting.  I’m sure it’ll be
> fine
> >> > either way.
> >> >
> >> > Steve
> >> >
> >> > On Feb 21, 2014, at 8:19 AM, Simon Willnauer <
> simon.willnauer@gmail.com>
> >> > wrote:
> >> >
> >> >> Guys, I don't think we will ever get to the point where there is not
> a
> >> >> bug. But we have to draw a line here. If we respin I have to step
> back
> >> >> as the RM since I just can't spend more than 7 days on this. I think
> >> >> there should be a 4.7.1 at some point where you can get your bugs
> >> >> fixed as everybody else but we have to draw a line here. I think I am
> >> >> going to draw it here with the 3 +1 I am having.
> >> >>
> >> >> simon
> >> >>
> >> >> On Fri, Feb 21, 2014 at 2:12 PM, Tomás Fernández Löbbe
> >> >> <to...@gmail.com> wrote:
> >> >>> Question here. Shouldn't SOLR-5762 be fixed before 4.7? My
> >> >>> understanding is
> >> >>> that if not, Solr 4.7 won't be able to work with SolrJ from 4.6.1 or
> >> >>> earlier?
> >> >>>
> >> >>>
> >> >>> On Fri, Feb 21, 2014 at 5:01 AM, Robert Muir <rc...@gmail.com>
> wrote:
> >> >>>>
> >> >>>>
> >> >>>> And I think it should be under optimizations not changes in
> behavior.
> >> >>>>
> >> >>>> On Fri, Feb 21, 2014 at 6:31 AM, Martijn v Groningen
> >> >>>> <ma...@gmail.com> wrote:
> >> >>>>>
> >> >>>>>
> >> >>>>> Only spotted a small docs typo in the Lucene CHANGES.txt, the
> second
> >> >>>>> issue under "Changes in Runtime Behavior" should be LUCENE-5399
> >> >>>>> instead of
> >> >>>>> LUCENE-4399.
> >> >>>>>
> >> >>>>>
> >> >>>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> 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
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>


-- 
-----------------------------------------------------
Noble Paul

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Simon Willnauer <si...@gmail.com>.

Thanks nobel! can you please ping me here so I can kick off another RC.

Regarding the bugs that should / should not block a release I think
it's hard to say which one should and that is my biggest problem here.
I think with more frequent releases and more point releases we can
make the intervals shorter and bugs get fixed quicker. I think it's
also the responsibility of the other committers to maybe go back a
step and ask themself if a bug should block a release and only if the
are absolutely +1 on respin mention it on the release thread? To me as
a RM it's really hard to draw the line. I also think we should not
push stuff into the release branch unless it's the cause of the
respin, we should work towards a stable branch an every change makes
it less stable again IMO.

just my $0.05

On Fri, Feb 21, 2014 at 6:35 PM, Noble Paul നോബിള്‍  नोब्ळ्
<no...@gmail.com> wrote:
> I'm working on a test case for 5762 I'll commit it tomorrow IST
>
> On 21 Feb 2014 20:05, "Simon Willnauer" <si...@gmail.com> wrote:
>>
>> So the problem here is where to draw the line. I think in a setup like
>> we have with lucene and solr in one codebase the chance to hit a bug
>> within these 72h is huge. This means the Release process is a huge
>> pain each time. Then we have bugs that justify a respin and some who
>> don't. I looked at SOLR-5762 and it seems this one should cause a
>> respin but the LUCENE-5461 doesn't. It's hard to draw that line since
>> its pretty much up to the RM and then you get heat if you draw that
>> line. IMO we should improve our release process and release a point
>> release every week shortening the vote period for that to maybe 24h.
>> That way we can get stuff out quickly and don't spend weeks on the
>> release process.
>>
>> I will call this vote here as failed and build a new RC once SOLR-5762 is
>> in.
>>
>> simon
>>
>> On Fri, Feb 21, 2014 at 3:23 PM, Steve Rowe <sa...@gmail.com> wrote:
>> > I volunteer to be 4.7.1 RM.
>> >
>> > I’d prefer to delay the 4.7.0 release to include all known bugfixes,
>> > though.
>> >
>> > Simon, if you’re okay with it, I could take over as 4.7.0 RM and handle
>> > any respins.  If not, it’s your prerogative to continue with the current RC
>> > vote; others can express their opinions by voting.  I’m sure it’ll be fine
>> > either way.
>> >
>> > Steve
>> >
>> > On Feb 21, 2014, at 8:19 AM, Simon Willnauer <si...@gmail.com>
>> > wrote:
>> >
>> >> Guys, I don't think we will ever get to the point where there is not a
>> >> bug. But we have to draw a line here. If we respin I have to step back
>> >> as the RM since I just can't spend more than 7 days on this. I think
>> >> there should be a 4.7.1 at some point where you can get your bugs
>> >> fixed as everybody else but we have to draw a line here. I think I am
>> >> going to draw it here with the 3 +1 I am having.
>> >>
>> >> simon
>> >>
>> >> On Fri, Feb 21, 2014 at 2:12 PM, Tomás Fernández Löbbe
>> >> <to...@gmail.com> wrote:
>> >>> Question here. Shouldn't SOLR-5762 be fixed before 4.7? My
>> >>> understanding is
>> >>> that if not, Solr 4.7 won't be able to work with SolrJ from 4.6.1 or
>> >>> earlier?
>> >>>
>> >>>
>> >>> On Fri, Feb 21, 2014 at 5:01 AM, Robert Muir <rc...@gmail.com> wrote:
>> >>>>
>> >>>>
>> >>>> And I think it should be under optimizations not changes in behavior.
>> >>>>
>> >>>> On Fri, Feb 21, 2014 at 6:31 AM, Martijn v Groningen
>> >>>> <ma...@gmail.com> wrote:
>> >>>>>
>> >>>>>
>> >>>>> Only spotted a small docs typo in the Lucene CHANGES.txt, the second
>> >>>>> issue under "Changes in Runtime Behavior" should be LUCENE-5399
>> >>>>> instead of
>> >>>>> LUCENE-4399.
>> >>>>>
>> >>>>>
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Noble Paul നോബിള്‍ नोब्ळ् <no...@gmail.com>.

I'm working on a test case for 5762 I'll commit it tomorrow IST
On 21 Feb 2014 20:05, "Simon Willnauer" <si...@gmail.com> wrote:

> So the problem here is where to draw the line. I think in a setup like
> we have with lucene and solr in one codebase the chance to hit a bug
> within these 72h is huge. This means the Release process is a huge
> pain each time. Then we have bugs that justify a respin and some who
> don't. I looked at SOLR-5762 and it seems this one should cause a
> respin but the LUCENE-5461 doesn't. It's hard to draw that line since
> its pretty much up to the RM and then you get heat if you draw that
> line. IMO we should improve our release process and release a point
> release every week shortening the vote period for that to maybe 24h.
> That way we can get stuff out quickly and don't spend weeks on the
> release process.
>
> I will call this vote here as failed and build a new RC once SOLR-5762 is
> in.
>
> simon
>
> On Fri, Feb 21, 2014 at 3:23 PM, Steve Rowe <sa...@gmail.com> wrote:
> > I volunteer to be 4.7.1 RM.
> >
> > I’d prefer to delay the 4.7.0 release to include all known bugfixes,
> though.
> >
> > Simon, if you’re okay with it, I could take over as 4.7.0 RM and handle
> any respins.  If not, it’s your prerogative to continue with the current RC
> vote; others can express their opinions by voting.  I’m sure it’ll be fine
> either way.
> >
> > Steve
> >
> > On Feb 21, 2014, at 8:19 AM, Simon Willnauer <si...@gmail.com>
> wrote:
> >
> >> Guys, I don't think we will ever get to the point where there is not a
> >> bug. But we have to draw a line here. If we respin I have to step back
> >> as the RM since I just can't spend more than 7 days on this. I think
> >> there should be a 4.7.1 at some point where you can get your bugs
> >> fixed as everybody else but we have to draw a line here. I think I am
> >> going to draw it here with the 3 +1 I am having.
> >>
> >> simon
> >>
> >> On Fri, Feb 21, 2014 at 2:12 PM, Tomás Fernández Löbbe
> >> <to...@gmail.com> wrote:
> >>> Question here. Shouldn't SOLR-5762 be fixed before 4.7? My
> understanding is
> >>> that if not, Solr 4.7 won't be able to work with SolrJ from 4.6.1 or
> >>> earlier?
> >>>
> >>>
> >>> On Fri, Feb 21, 2014 at 5:01 AM, Robert Muir <rc...@gmail.com> wrote:
> >>>>
> >>>>
> >>>> And I think it should be under optimizations not changes in behavior.
> >>>>
> >>>> On Fri, Feb 21, 2014 at 6:31 AM, Martijn v Groningen
> >>>> <ma...@gmail.com> wrote:
> >>>>>
> >>>>>
> >>>>> Only spotted a small docs typo in the Lucene CHANGES.txt, the second
> >>>>> issue under "Changes in Runtime Behavior" should be LUCENE-5399
> instead of
> >>>>> LUCENE-4399.
> >>>>>
> >>>>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Michael McCandless <lu...@mikemccandless.com>.

On Sat, Feb 22, 2014 at 11:39 AM, Mark Miller <ma...@gmail.com> wrote:
> I've been sick and am sick, so take it for what it's worth with my head swirling, but I wrote down a few of my thoughts on releases.

Hope you're better Mark :)

> We shouldn't discourage review and reporting back of problems with the release. That is the entire point of the review and vote. We learn which bugs are worth a respin with discussion and consensus.

+1

I actually find it encouraging how many re-spins we've had in recent
releases: I think this is a sign of increased attention / scrutiny.

We should encourage such scrutiny (and, more!), and as issues are
discovered, encourage people to raise them, even if after some
discussion we decide it's not a blocker.

> Potential RMs that don't want to respin may not be the best candidate RM's. Or they should be willing to hand off the reigns for another to respin. That doesn't mean you have to respin or can't argue against it. But it seems like you should be pretty open to the idea if their strong support for it.

+1

> A respin amounts to running a few cmds. It is mostly waiting. And it's easily passed off if your busy. Robert happily picked up the last bits of the 4.6.1 release for me when I had to go out of town for a few days. I would do the same for anyone here.

I think if an RM is becoming frustrated running those commands and
waiting then they should "cry uncle" and someone else can easily step
in.

We should try to make the release process as push-button as possible
so there's minimal effort on the RM's part.  We've come a long ways
(the smoke tester, buildAndPushRelease), but we could always improve
automation further.

> I don't think we should try and setup a system that tries to avoid discussion and consensus - I think you just need a fail safe to help ensure it doesn't go on to long.

+1, everyone should feel to raise release issues for discussion on the
vote thread.

Mike McCandless

http://blog.mikemccandless.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Simon Willnauer <si...@gmail.com>.

thanks uwe - I am ok with the respin all it takes it entering a screen
press the up arrow, enter a password and wait :) It the process not
the execution. I think I will  keep this RC out for longer if needed
just to gather feedback even if the vote fails.

simon

On Sun, Feb 23, 2014 at 8:05 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
> Hi Simon,
>
> thanks for your writeup! I totally agree! FYI, If we have to respin again, I will do the next run, ok?
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
>> -----Original Message-----
>> From: Simon Willnauer [mailto:simon.willnauer@gmail.com]
>> Sent: Sunday, February 23, 2014 8:01 PM
>> To: dev@lucene.apache.org
>> Subject: Re: [VOTE] Lucene / Solr 4.7.0 RC3
>>
>> On Sat, Feb 22, 2014 at 5:39 PM, Mark Miller <ma...@gmail.com>
>> wrote:
>> > I’ve been sick and am sick, so take it for what it’s worth with my head
>> swirling, but I wrote down a few of my thoughts on releases.
>> >
>> > It’s all encompassed in a big “in my opinion”. It’s not necessarily to refute
>> anyone or argue with any existing points. It’s just the thoughts I had when
>> thinking about the topic.
>>
>> Hey mark,
>>
>> get well though hope it's not too bad!
>> >
>> > Releases
>> >
>> > I think we have to balance the utility of getting code into users hands faster
>> with the utility of solid and stable releases. Balance the needs of new users
>> and existing users.
>>
>> I agree in general but IMO we need to make a difference between feature
>> releases and bugfix releases but I will come back to this laster further down
>> the email.
>>
>> >
>> > We shouldn't discourage review and reporting back of problems with the
>> release. That is the entire point of the review and vote. We learn which bugs
>> are worth a respin with discussion and consensus.
>> >
>> > We should be lenient on the first couple RCs and more strict over time.
>> Let's aim for quality.
>>
>> I have done some releases here in lucene land but this time something was
>> fundamentally different which made me worry a much more about the job
>> and the responsibility of the RM. The last couple of releases I ran the release
>> script always with a -smoke but this time I didn't and stuff was failing all over
>> me with the solr tests as I mentioned in another email. Yet, I haven't realised
>> until then that -smoke disables running the tests and we are essentially build
>> a release candidate without passing tests. Mark said he is watching every test
>> failure and there is nothing to worry about. (I will need to reply to that which
>> I had no time yet but I think this is very very concerning but yet another
>> story). For me as a RM I have only once choice and trust mark here since if I
>> wouldn't I had to -1 every RC since the tests fail.
>> That far the quality discussion but we need to have a sep. discussion about
>> this.
>>
>> >
>> > We should discuss issues and not try and move at light speed. We are a
>> large group of diverse developers - it's okay for things to move at a pace of
>> days. It's actually the Apache Way IMO.
>>
>> I could not agree more. Here are my problems on how things work today...
>> The last couple of release we always had the discussion about when to cut
>> the Release Branch and this time I tried to not step on people toes and
>> announce it a couple of days earlier which was good.
>> Then on wed. we build an RC and suddenly one bug per RC shows up. This is
>> the annoying part that really bugs me since we are wasting a ton of time on
>> rebuilding the RCs etc. and that is the part that annoys me because it seems
>> folks rush stuff in to get the next RC out. I admit now that I took a step back
>> that this is also the fault of the RM (me in this case since I wanted to move
>> fast rather than towards a stable release). The changes that go it don't get a
>> lot of CI runs, they don't get run in tests during Release. This doesn't really
>> give me much confidence neither for the change nor for the release.
>> That said I think what brings up these bugs is that folks actually installing the
>> RC in their environment and runs smoke tests with their apps which is what
>> we want and should encourage people to do. Now bugs come in and we
>> respin and respin and respin which makes those windows smaller and smaller
>> between change and RC. That just doesn't make much sense to me. What
>> would make more sense to me is a process where we can draw a clear line
>> between respin-worthy and not-respin-worthy. I thought about this today
>> and I don't think we can draw a clear line here but I though about a potential
>> improvement of the process that would address at least my concerns and
>> would allow folks to test and report back changes. Here is what I have in
>> mind for a feature release
>>
>> - We cut a release branch with 3 or 4 days of notice and from that point on
>> there are no features backported to this branch anymore.
>> - We start CI builds for this branch and have a close eye on it for the solr part
>> if there are failures (mark I rely on you and the guys around you)
>> - We build an RC that is out there for a couple of days without a vote for folks
>> to test and for us to gather feedback. During that period we only commit
>> bugfixes / changes cleanups etc. essentially things that seem to be wrong
>> with that unvoted RC.
>> - Once we had that out there for a couple of days maybe a week and
>> gathered feedback, ported bugfixes to that branch and hardened stuff out
>> we can build an RC, sign it and vote.
>>
>> It would make things for the RM much more straight forward since there
>> would not be respin after respin and the responsibility on the RM would be
>> reduced with RC and time at least that would make me feel much better.
>>
>> >
>> > Potential RMs that don't want to respin may not be the best candidate
>> RM's. Or they should be willing to hand off the reigns for another to respin.
>> That doesn’t mean you have to respin or can’t argue against it. But it seems
>> like you should be pretty open to the idea if their strong support for it.
>>
>> I think there are a bunch of different camps along those lines. For what it's
>> worth I think not every bug should cause a respin but the critical ones for
>> sure like the BW compat. My frustration came more from the things I
>> mentioned above rather than running that script again which doesn't cost me
>> much. The process is still sucks. I don't think its a question of "want" but
>> rather what makes sense from a process point of view and that is why we
>> have the discussion to improve.
>>
>> Simon
>>
>> >
>> > Releasing often should be a goal. Making releases easy to do should be a
>> goal. Releasing fast is not necessarily a good goal. We should strive for
>> quality. People choose a release and are often stuck on it for a very long
>> time. A respin amounts to running a few cmds. It is mostly waiting. And it’s
>> easily passed off if your busy. Robert happily picked up the last bits of the
>> 4.6.1 release for me when I had to go out of town for a few days. I would do
>> the same for anyone here.
>> >
>> > I can't think of a reason for delaying a release a few days or even a week if
>> we can make it higher quality in a way discussion and consensus has deemed
>> important. Company deadlines seem like the only reason we wouldn't do this
>> and they shouldn't play a role in our releases. I don’t think we should try and
>> setup a system that tries to avoid discussion and consensus - I think you just
>> need a fail safe to help ensure it doesn’t go on to long. I think discussion and
>> consensus with the community of developers we have put together is a good
>> failsafe. In general, we all seem pretty good at coming to consensus in most
>> cases. I can’t be the only one to notice how we seem to end up working
>> almost everything out pretty nicely in the end.
>> >
>> > Common sense has always worked for us in the past - the community
>> would not delay a release for weeks just to fix a few superficial bugs.
>> >
>> > Looking critically at our last half dozen releases, I think things went pretty
>> well and at a great pace.
>> >
>> > - Mark
>> >
>> > http://about.me/markrmiller
>> >
>> >
>> >
>> >
>> > On Feb 21, 2014, at 10:27 AM, Robert Muir <rc...@gmail.com> wrote:
>> >
>> >>
>> >>
>> >>
>> >> On Fri, Feb 21, 2014 at 10:23 AM, Uwe Schindler <uw...@thetaphi.de>
>> wrote:
>> >>
>> >> A similar thing was already discussed on the board. I think we have to stick
>> with the 72 hours (for now?). We can do releases once per week; we can also
>> do them "automatically" - the problem here is the GPG signature: It has to be
>> done by a real person (the RM). A machine as RM is therefore not possible.
>> >>
>> >> I agree a machine cannot be the complete RM, but it could take over
>> more. For example, a machine could prepare-release-no-sign and verify it
>> (actually this is what 'ant nightly-smoke' does!), and if it succeeds, someone
>> could take those artifacts, sign them, and call a vote.
>> >
>> >
>> > ---------------------------------------------------------------------
>> > 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
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

RE: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Uwe Schindler <uw...@thetaphi.de>.

Hi Simon,

thanks for your writeup! I totally agree! FYI, If we have to respin again, I will do the next run, ok?

Uwe

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de


> -----Original Message-----
> From: Simon Willnauer [mailto:simon.willnauer@gmail.com]
> Sent: Sunday, February 23, 2014 8:01 PM
> To: dev@lucene.apache.org
> Subject: Re: [VOTE] Lucene / Solr 4.7.0 RC3
> 
> On Sat, Feb 22, 2014 at 5:39 PM, Mark Miller <ma...@gmail.com>
> wrote:
> > I’ve been sick and am sick, so take it for what it’s worth with my head
> swirling, but I wrote down a few of my thoughts on releases.
> >
> > It’s all encompassed in a big “in my opinion”. It’s not necessarily to refute
> anyone or argue with any existing points. It’s just the thoughts I had when
> thinking about the topic.
> 
> Hey mark,
> 
> get well though hope it's not too bad!
> >
> > Releases
> >
> > I think we have to balance the utility of getting code into users hands faster
> with the utility of solid and stable releases. Balance the needs of new users
> and existing users.
> 
> I agree in general but IMO we need to make a difference between feature
> releases and bugfix releases but I will come back to this laster further down
> the email.
> 
> >
> > We shouldn't discourage review and reporting back of problems with the
> release. That is the entire point of the review and vote. We learn which bugs
> are worth a respin with discussion and consensus.
> >
> > We should be lenient on the first couple RCs and more strict over time.
> Let's aim for quality.
> 
> I have done some releases here in lucene land but this time something was
> fundamentally different which made me worry a much more about the job
> and the responsibility of the RM. The last couple of releases I ran the release
> script always with a -smoke but this time I didn't and stuff was failing all over
> me with the solr tests as I mentioned in another email. Yet, I haven't realised
> until then that -smoke disables running the tests and we are essentially build
> a release candidate without passing tests. Mark said he is watching every test
> failure and there is nothing to worry about. (I will need to reply to that which
> I had no time yet but I think this is very very concerning but yet another
> story). For me as a RM I have only once choice and trust mark here since if I
> wouldn't I had to -1 every RC since the tests fail.
> That far the quality discussion but we need to have a sep. discussion about
> this.
> 
> >
> > We should discuss issues and not try and move at light speed. We are a
> large group of diverse developers - it's okay for things to move at a pace of
> days. It's actually the Apache Way IMO.
> 
> I could not agree more. Here are my problems on how things work today...
> The last couple of release we always had the discussion about when to cut
> the Release Branch and this time I tried to not step on people toes and
> announce it a couple of days earlier which was good.
> Then on wed. we build an RC and suddenly one bug per RC shows up. This is
> the annoying part that really bugs me since we are wasting a ton of time on
> rebuilding the RCs etc. and that is the part that annoys me because it seems
> folks rush stuff in to get the next RC out. I admit now that I took a step back
> that this is also the fault of the RM (me in this case since I wanted to move
> fast rather than towards a stable release). The changes that go it don't get a
> lot of CI runs, they don't get run in tests during Release. This doesn't really
> give me much confidence neither for the change nor for the release.
> That said I think what brings up these bugs is that folks actually installing the
> RC in their environment and runs smoke tests with their apps which is what
> we want and should encourage people to do. Now bugs come in and we
> respin and respin and respin which makes those windows smaller and smaller
> between change and RC. That just doesn't make much sense to me. What
> would make more sense to me is a process where we can draw a clear line
> between respin-worthy and not-respin-worthy. I thought about this today
> and I don't think we can draw a clear line here but I though about a potential
> improvement of the process that would address at least my concerns and
> would allow folks to test and report back changes. Here is what I have in
> mind for a feature release
> 
> - We cut a release branch with 3 or 4 days of notice and from that point on
> there are no features backported to this branch anymore.
> - We start CI builds for this branch and have a close eye on it for the solr part
> if there are failures (mark I rely on you and the guys around you)
> - We build an RC that is out there for a couple of days without a vote for folks
> to test and for us to gather feedback. During that period we only commit
> bugfixes / changes cleanups etc. essentially things that seem to be wrong
> with that unvoted RC.
> - Once we had that out there for a couple of days maybe a week and
> gathered feedback, ported bugfixes to that branch and hardened stuff out
> we can build an RC, sign it and vote.
> 
> It would make things for the RM much more straight forward since there
> would not be respin after respin and the responsibility on the RM would be
> reduced with RC and time at least that would make me feel much better.
> 
> >
> > Potential RMs that don't want to respin may not be the best candidate
> RM's. Or they should be willing to hand off the reigns for another to respin.
> That doesn’t mean you have to respin or can’t argue against it. But it seems
> like you should be pretty open to the idea if their strong support for it.
> 
> I think there are a bunch of different camps along those lines. For what it's
> worth I think not every bug should cause a respin but the critical ones for
> sure like the BW compat. My frustration came more from the things I
> mentioned above rather than running that script again which doesn't cost me
> much. The process is still sucks. I don't think its a question of "want" but
> rather what makes sense from a process point of view and that is why we
> have the discussion to improve.
> 
> Simon
> 
> >
> > Releasing often should be a goal. Making releases easy to do should be a
> goal. Releasing fast is not necessarily a good goal. We should strive for
> quality. People choose a release and are often stuck on it for a very long
> time. A respin amounts to running a few cmds. It is mostly waiting. And it’s
> easily passed off if your busy. Robert happily picked up the last bits of the
> 4.6.1 release for me when I had to go out of town for a few days. I would do
> the same for anyone here.
> >
> > I can't think of a reason for delaying a release a few days or even a week if
> we can make it higher quality in a way discussion and consensus has deemed
> important. Company deadlines seem like the only reason we wouldn't do this
> and they shouldn't play a role in our releases. I don’t think we should try and
> setup a system that tries to avoid discussion and consensus - I think you just
> need a fail safe to help ensure it doesn’t go on to long. I think discussion and
> consensus with the community of developers we have put together is a good
> failsafe. In general, we all seem pretty good at coming to consensus in most
> cases. I can’t be the only one to notice how we seem to end up working
> almost everything out pretty nicely in the end.
> >
> > Common sense has always worked for us in the past - the community
> would not delay a release for weeks just to fix a few superficial bugs.
> >
> > Looking critically at our last half dozen releases, I think things went pretty
> well and at a great pace.
> >
> > - Mark
> >
> > http://about.me/markrmiller
> >
> >
> >
> >
> > On Feb 21, 2014, at 10:27 AM, Robert Muir <rc...@gmail.com> wrote:
> >
> >>
> >>
> >>
> >> On Fri, Feb 21, 2014 at 10:23 AM, Uwe Schindler <uw...@thetaphi.de>
> wrote:
> >>
> >> A similar thing was already discussed on the board. I think we have to stick
> with the 72 hours (for now?). We can do releases once per week; we can also
> do them "automatically" - the problem here is the GPG signature: It has to be
> done by a real person (the RM). A machine as RM is therefore not possible.
> >>
> >> I agree a machine cannot be the complete RM, but it could take over
> more. For example, a machine could prepare-release-no-sign and verify it
> (actually this is what 'ant nightly-smoke' does!), and if it succeeds, someone
> could take those artifacts, sign them, and call a vote.
> >
> >
> > ---------------------------------------------------------------------
> > 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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Simon Willnauer <si...@gmail.com>.

On Sat, Feb 22, 2014 at 5:39 PM, Mark Miller <ma...@gmail.com> wrote:
> I’ve been sick and am sick, so take it for what it’s worth with my head swirling, but I wrote down a few of my thoughts on releases.
>
> It’s all encompassed in a big “in my opinion”. It’s not necessarily to refute anyone or argue with any existing points. It’s just the thoughts I had when thinking about the topic.

Hey mark,

get well though hope it's not too bad!
>
> Releases
>
> I think we have to balance the utility of getting code into users hands faster with the utility of solid and stable releases. Balance the needs of new users and existing users.

I agree in general but IMO we need to make a difference between
feature releases and bugfix releases but I will come back to this
laster further down the email.

>
> We shouldn't discourage review and reporting back of problems with the release. That is the entire point of the review and vote. We learn which bugs are worth a respin with discussion and consensus.
>
> We should be lenient on the first couple RCs and more strict over time. Let's aim for quality.

I have done some releases here in lucene land but this time something
was fundamentally different which made me worry a much more about the
job and the responsibility of the RM. The last couple of releases I
ran the release script always with a -smoke but this time I didn't and
stuff was failing all over me with the solr tests as I mentioned in
another email. Yet, I haven't realised until then that -smoke disables
running the tests and we are essentially build a release candidate
without passing tests. Mark said he is watching every test failure and
there is nothing to worry about. (I will need to reply to that which I
had no time yet but I think this is very very concerning but yet
another story). For me as a RM I have only once choice and trust mark
here since if I wouldn't I had to -1 every RC since the tests fail.
That far the quality discussion but we need to have a sep. discussion
about this.

>
> We should discuss issues and not try and move at light speed. We are a large group of diverse developers - it's okay for things to move at a pace of days. It's actually the Apache Way IMO.

I could not agree more. Here are my problems on how things work
today... The last couple of release we always had the discussion about
when to cut the Release Branch and this time I tried to not step on
people toes and announce it a couple of days earlier which was good.
Then on wed. we build an RC and suddenly one bug per RC shows up. This
is the annoying part that really bugs me since we are wasting a ton of
time on rebuilding the RCs etc. and that is the part that annoys me
because it seems folks rush stuff in to get the next RC out. I admit
now that I took a step back that this is also the fault of the RM (me
in this case since I wanted to move fast rather than towards a stable
release). The changes that go it don't get a lot of CI runs, they
don't get run in tests during Release. This doesn't really give me
much confidence neither for the change nor for the release.
That said I think what brings up these bugs is that folks actually
installing the RC in their environment and runs smoke tests with their
apps which is what we want and should encourage people to do. Now bugs
come in and we respin and respin and respin which makes those windows
smaller and smaller between change and RC. That just doesn't make much
sense to me. What would make more sense to me is a process where we
can draw a clear line between respin-worthy and not-respin-worthy. I
thought about this today and I don't think we can draw a clear line
here but I though about a potential improvement of the process that
would address at least my concerns and would allow folks to test and
report back changes. Here is what I have in mind for a feature release

- We cut a release branch with 3 or 4 days of notice and from that
point on there are no features backported to this branch anymore.
- We start CI builds for this branch and have a close eye on it for
the solr part if there are failures (mark I rely on you and the guys
around you)
- We build an RC that is out there for a couple of days without a vote
for folks to test and for us to gather feedback. During that period we
only commit bugfixes / changes cleanups etc. essentially things that
seem to be wrong with that unvoted RC.
- Once we had that out there for a couple of days maybe a week and
gathered feedback, ported bugfixes to that branch and hardened stuff
out we can build an RC, sign it and vote.

It would make things for the RM much more straight forward since there
would not be respin after respin and the responsibility on the RM
would be reduced with RC and time at least that would make me feel
much better.

>
> Potential RMs that don't want to respin may not be the best candidate RM's. Or they should be willing to hand off the reigns for another to respin. That doesn’t mean you have to respin or can’t argue against it. But it seems like you should be pretty open to the idea if their strong support for it.

I think there are a bunch of different camps along those lines. For
what it's worth I think not every bug should cause a respin but the
critical ones for sure like the BW compat. My frustration came more
from the things I mentioned above rather than running that script
again which doesn't cost me much. The process is still sucks. I don't
think its a question of "want" but rather what makes sense from a
process point of view and that is why we have the discussion to
improve.

Simon

>
> Releasing often should be a goal. Making releases easy to do should be a goal. Releasing fast is not necessarily a good goal. We should strive for quality. People choose a release and are often stuck on it for a very long time. A respin amounts to running a few cmds. It is mostly waiting. And it’s easily passed off if your busy. Robert happily picked up the last bits of the 4.6.1 release for me when I had to go out of town for a few days. I would do the same for anyone here.
>
> I can't think of a reason for delaying a release a few days or even a week if we can make it higher quality in a way discussion and consensus has deemed important. Company deadlines seem like the only reason we wouldn't do this and they shouldn't play a role in our releases. I don’t think we should try and setup a system that tries to avoid discussion and consensus - I think you just need a fail safe to help ensure it doesn’t go on to long. I think discussion and consensus with the community of developers we have put together is a good failsafe. In general, we all seem pretty good at coming to consensus in most cases. I can’t be the only one to notice how we seem to end up working almost everything out pretty nicely in the end.
>
> Common sense has always worked for us in the past - the community would not delay a release for weeks just to fix a few superficial bugs.
>
> Looking critically at our last half dozen releases, I think things went pretty well and at a great pace.
>
> - Mark
>
> http://about.me/markrmiller
>
>
>
>
> On Feb 21, 2014, at 10:27 AM, Robert Muir <rc...@gmail.com> wrote:
>
>>
>>
>>
>> On Fri, Feb 21, 2014 at 10:23 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
>>
>> A similar thing was already discussed on the board. I think we have to stick with the 72 hours (for now?). We can do releases once per week; we can also do them "automatically" - the problem here is the GPG signature: It has to be done by a real person (the RM). A machine as RM is therefore not possible.
>>
>> I agree a machine cannot be the complete RM, but it could take over more. For example, a machine could prepare-release-no-sign and verify it (actually this is what 'ant nightly-smoke' does!), and if it succeeds, someone could take those artifacts, sign them, and call a vote.
>
>
> ---------------------------------------------------------------------
> 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

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Mark Miller <ma...@gmail.com>.

I’ve been sick and am sick, so take it for what it’s worth with my head swirling, but I wrote down a few of my thoughts on releases.

It’s all encompassed in a big “in my opinion”. It’s not necessarily to refute anyone or argue with any existing points. It’s just the thoughts I had when thinking about the topic.

Releases

I think we have to balance the utility of getting code into users hands faster with the utility of solid and stable releases. Balance the needs of new users and existing users. 

We shouldn't discourage review and reporting back of problems with the release. That is the entire point of the review and vote. We learn which bugs are worth a respin with discussion and consensus. 

We should be lenient on the first couple RCs and more strict over time. Let's aim for quality. 

We should discuss issues and not try and move at light speed. We are a large group of diverse developers - it's okay for things to move at a pace of days. It's actually the Apache Way IMO. 

Potential RMs that don't want to respin may not be the best candidate RM's. Or they should be willing to hand off the reigns for another to respin. That doesn’t mean you have to respin or can’t argue against it. But it seems like you should be pretty open to the idea if their strong support for it.

Releasing often should be a goal. Making releases easy to do should be a goal. Releasing fast is not necessarily a good goal. We should strive for quality. People choose a release and are often stuck on it for a very long time. A respin amounts to running a few cmds. It is mostly waiting. And it’s easily passed off if your busy. Robert happily picked up the last bits of the 4.6.1 release for me when I had to go out of town for a few days. I would do the same for anyone here.

I can't think of a reason for delaying a release a few days or even a week if we can make it higher quality in a way discussion and consensus has deemed important. Company deadlines seem like the only reason we wouldn't do this and they shouldn't play a role in our releases. I don’t think we should try and setup a system that tries to avoid discussion and consensus - I think you just need a fail safe to help ensure it doesn’t go on to long. I think discussion and consensus with the community of developers we have put together is a good failsafe. In general, we all seem pretty good at coming to consensus in most cases. I can’t be the only one to notice how we seem to end up working almost everything out pretty nicely in the end.

Common sense has always worked for us in the past - the community would not delay a release for weeks just to fix a few superficial bugs. 

Looking critically at our last half dozen releases, I think things went pretty well and at a great pace. 

- Mark

http://about.me/markrmiller

On Feb 21, 2014, at 10:27 AM, Robert Muir <rc...@gmail.com> wrote:

> 
> 
> 
> On Fri, Feb 21, 2014 at 10:23 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> 
> A similar thing was already discussed on the board. I think we have to stick with the 72 hours (for now?). We can do releases once per week; we can also do them "automatically" - the problem here is the GPG signature: It has to be done by a real person (the RM). A machine as RM is therefore not possible.
>  
> I agree a machine cannot be the complete RM, but it could take over more. For example, a machine could prepare-release-no-sign and verify it (actually this is what 'ant nightly-smoke' does!), and if it succeeds, someone could take those artifacts, sign them, and call a vote.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Robert Muir <rc...@gmail.com>.

On Fri, Feb 21, 2014 at 10:23 AM, Uwe Schindler <uw...@thetaphi.de> wrote:

>
> A similar thing was already discussed on the board. I think we have to
> stick with the 72 hours (for now?). We can do releases once per week; we
> can also do them "automatically" - the problem here is the GPG signature:
> It has to be done by a real person (the RM). A machine as RM is therefore
> not possible.
>

I agree a machine cannot be the complete RM, but it could take over more.
For example, a machine could prepare-release-no-sign and verify it
(actually this is what 'ant nightly-smoke' does!), and if it succeeds,
someone could take those artifacts, sign them, and call a vote.

RE: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Uwe Schindler <uw...@thetaphi.de>.

Hi,

> So the problem here is where to draw the line. I think in a setup like we have
> with lucene and solr in one codebase the chance to hit a bug within these 72h
> is huge. This means the Release process is a huge pain each time. Then we
> have bugs that justify a respin and some who don't. I looked at SOLR-5762
> and it seems this one should cause a respin but the LUCENE-5461 doesn't. It's
> hard to draw that line since its pretty much up to the RM and then you get
> heat if you draw that line. IMO we should improve our release process and
> release a point release every week shortening the vote period for that to
> maybe 24h.
> That way we can get stuff out quickly and don't spend weeks on the release
> process.

A similar thing was already discussed on the board. I think we have to stick with the 72 hours (for now?). We can do releases once per week; we can also do them "automatically" - the problem here is the GPG signature: It has to be done by a real person (the RM). A machine as RM is therefore not possible.

One important thing is that the voting PMC members have to check the signatures. If they are not correct/trusted, the release fails. Everything else is open to the community. A failing test is not a problem for a release. We could theoretically release Lucene with all tests failing, as long as the signatures are OK :-)

Uwe


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Simon Willnauer <si...@gmail.com>.

So the problem here is where to draw the line. I think in a setup like
we have with lucene and solr in one codebase the chance to hit a bug
within these 72h is huge. This means the Release process is a huge
pain each time. Then we have bugs that justify a respin and some who
don't. I looked at SOLR-5762 and it seems this one should cause a
respin but the LUCENE-5461 doesn't. It's hard to draw that line since
its pretty much up to the RM and then you get heat if you draw that
line. IMO we should improve our release process and release a point
release every week shortening the vote period for that to maybe 24h.
That way we can get stuff out quickly and don't spend weeks on the
release process.

I will call this vote here as failed and build a new RC once SOLR-5762 is in.

simon

On Fri, Feb 21, 2014 at 3:23 PM, Steve Rowe <sa...@gmail.com> wrote:
> I volunteer to be 4.7.1 RM.
>
> I’d prefer to delay the 4.7.0 release to include all known bugfixes, though.
>
> Simon, if you’re okay with it, I could take over as 4.7.0 RM and handle any respins.  If not, it’s your prerogative to continue with the current RC vote; others can express their opinions by voting.  I’m sure it’ll be fine either way.
>
> Steve
>
> On Feb 21, 2014, at 8:19 AM, Simon Willnauer <si...@gmail.com> wrote:
>
>> Guys, I don't think we will ever get to the point where there is not a
>> bug. But we have to draw a line here. If we respin I have to step back
>> as the RM since I just can't spend more than 7 days on this. I think
>> there should be a 4.7.1 at some point where you can get your bugs
>> fixed as everybody else but we have to draw a line here. I think I am
>> going to draw it here with the 3 +1 I am having.
>>
>> simon
>>
>> On Fri, Feb 21, 2014 at 2:12 PM, Tomás Fernández Löbbe
>> <to...@gmail.com> wrote:
>>> Question here. Shouldn't SOLR-5762 be fixed before 4.7? My understanding is
>>> that if not, Solr 4.7 won't be able to work with SolrJ from 4.6.1 or
>>> earlier?
>>>
>>>
>>> On Fri, Feb 21, 2014 at 5:01 AM, Robert Muir <rc...@gmail.com> wrote:
>>>>
>>>>
>>>> And I think it should be under optimizations not changes in behavior.
>>>>
>>>> On Fri, Feb 21, 2014 at 6:31 AM, Martijn v Groningen
>>>> <ma...@gmail.com> wrote:
>>>>>
>>>>>
>>>>> Only spotted a small docs typo in the Lucene CHANGES.txt, the second
>>>>> issue under "Changes in Runtime Behavior" should be LUCENE-5399 instead of
>>>>> LUCENE-4399.
>>>>>
>>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Steve Rowe <sa...@gmail.com>.

I volunteer to be 4.7.1 RM.

I’d prefer to delay the 4.7.0 release to include all known bugfixes, though.  

Simon, if you’re okay with it, I could take over as 4.7.0 RM and handle any respins.  If not, it’s your prerogative to continue with the current RC vote; others can express their opinions by voting.  I’m sure it’ll be fine either way.

Steve

On Feb 21, 2014, at 8:19 AM, Simon Willnauer <si...@gmail.com> wrote:

> Guys, I don't think we will ever get to the point where there is not a
> bug. But we have to draw a line here. If we respin I have to step back
> as the RM since I just can't spend more than 7 days on this. I think
> there should be a 4.7.1 at some point where you can get your bugs
> fixed as everybody else but we have to draw a line here. I think I am
> going to draw it here with the 3 +1 I am having.
> 
> simon
> 
> On Fri, Feb 21, 2014 at 2:12 PM, Tomás Fernández Löbbe
> <to...@gmail.com> wrote:
>> Question here. Shouldn't SOLR-5762 be fixed before 4.7? My understanding is
>> that if not, Solr 4.7 won't be able to work with SolrJ from 4.6.1 or
>> earlier?
>> 
>> 
>> On Fri, Feb 21, 2014 at 5:01 AM, Robert Muir <rc...@gmail.com> wrote:
>>> 
>>> 
>>> And I think it should be under optimizations not changes in behavior.
>>> 
>>> On Fri, Feb 21, 2014 at 6:31 AM, Martijn v Groningen
>>> <ma...@gmail.com> wrote:
>>>> 
>>>> 
>>>> Only spotted a small docs typo in the Lucene CHANGES.txt, the second
>>>> issue under "Changes in Runtime Behavior" should be LUCENE-5399 instead of
>>>> LUCENE-4399.
>>>> 
>>>> 
>> 
> 
> ---------------------------------------------------------------------
> 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

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Simon Willnauer <si...@gmail.com>.

Guys, I don't think we will ever get to the point where there is not a
bug. But we have to draw a line here. If we respin I have to step back
as the RM since I just can't spend more than 7 days on this. I think
there should be a 4.7.1 at some point where you can get your bugs
fixed as everybody else but we have to draw a line here. I think I am
going to draw it here with the 3 +1 I am having.

simon

On Fri, Feb 21, 2014 at 2:12 PM, Tomás Fernández Löbbe
<to...@gmail.com> wrote:
> Question here. Shouldn't SOLR-5762 be fixed before 4.7? My understanding is
> that if not, Solr 4.7 won't be able to work with SolrJ from 4.6.1 or
> earlier?
>
>
> On Fri, Feb 21, 2014 at 5:01 AM, Robert Muir <rc...@gmail.com> wrote:
>>
>>
>> And I think it should be under optimizations not changes in behavior.
>>
>> On Fri, Feb 21, 2014 at 6:31 AM, Martijn v Groningen
>> <ma...@gmail.com> wrote:
>>>
>>>
>>> Only spotted a small docs typo in the Lucene CHANGES.txt, the second
>>> issue under "Changes in Runtime Behavior" should be LUCENE-5399 instead of
>>> LUCENE-4399.
>>>
>>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Tomás Fernández Löbbe <to...@gmail.com>.

Question here. Shouldn't SOLR-5762 be fixed before 4.7? My understanding is
that if not, Solr 4.7 won't be able to work with SolrJ from 4.6.1 or
earlier?

On Fri, Feb 21, 2014 at 5:01 AM, Robert Muir <rc...@gmail.com> wrote:

>
> And I think it should be under optimizations not changes in behavior.
>
> On Fri, Feb 21, 2014 at 6:31 AM, Martijn v Groningen <
> martijn.v.groningen@gmail.com> wrote:
>
>>
>> Only spotted a small docs typo in the Lucene CHANGES.txt, the second
>> issue under "Changes in Runtime Behavior" should be LUCENE-5399 instead
>> of LUCENE-4399.
>>
>>
>>

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Robert Muir <rc...@gmail.com>.

And I think it should be under optimizations not changes in behavior.

On Fri, Feb 21, 2014 at 6:31 AM, Martijn v Groningen <
martijn.v.groningen@gmail.com> wrote:

>
> Only spotted a small docs typo in the Lucene CHANGES.txt, the second issue
> under "Changes in Runtime Behavior" should be LUCENE-5399 instead of
> LUCENE-4399.
>
>
>

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Adrien Grand <jp...@gmail.com>.

+1 SUCCESS! [1:05:13.864799]

-- 
Adrien

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Michael McCandless <lu...@mikemccandless.com>.

OK I ported the fix for LUCENE-5461 to 4.7.x branch in case we re-spin.

I think we should re-spin (sorry!), but I'll leave that decision up to
Simon as the RM...

It's a bad bug, but ControlledRealTimeReopenThread really isn't THAT
commonly used...

Mike McCandless

http://blog.mikemccandless.com


On Fri, Feb 21, 2014 at 7:30 AM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> If we will respin, I'd like to fold in LUCENE-5461.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Fri, Feb 21, 2014 at 6:44 AM, Simon Willnauer
> <si...@gmail.com> wrote:
>> Martjin can you fix that in 4x and master and also in 47 in the case we respin?
>>
>> On Fri, Feb 21, 2014 at 12:31 PM, Martijn v Groningen
>> <ma...@gmail.com> wrote:
>>> +1
>>>
>>> SUCCESS! [1:52:31.345809]
>>>
>>> Only spotted a small docs typo in the Lucene CHANGES.txt, the second issue
>>> under "Changes in Runtime Behavior" should be LUCENE-5399 instead of
>>> LUCENE-4399.
>>>
>>>
>>> On 21 February 2014 02:50, Mark Miller <ma...@gmail.com> wrote:
>>>>
>>>> +1
>>>>
>>>> SUCCESS! [1:05:52.694842]
>>>>
>>>> - Mark
>>>>
>>>> http://about.me/markrmiller
>>>>
>>>> On Feb 20, 2014, at 3:52 PM, Simon Willnauer <si...@gmail.com>
>>>> wrote:
>>>>
>>>> > Please vote for the third Release Candidate for Lucene/Solr 4.7.0
>>>> >
>>>> > you can download it here:
>>>> >
>>>> > http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC3-rev1570248/
>>>> >
>>>> > or run the smoke tester directly with this commandline (don't forget
>>>> > to set JAVA6_HOME etc.):
>>>> >
>>>> > $ python3.2 -u dev-tools/scripts/smokeTestRelease.py
>>>> >
>>>> > http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC3-rev1570248/
>>>> > 1570248 4.7.0 /tmp/smoke_test_4_7
>>>> >
>>>> > Smoketester said: SUCCESS!
>>>> >
>>>> > here is my +1
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > 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
>>>>
>>>
>>>
>>>
>>> --
>>> Met vriendelijke groet,
>>>
>>> Martijn van Groningen
>>
>> ---------------------------------------------------------------------
>> 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

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Michael McCandless <lu...@mikemccandless.com>.

If we will respin, I'd like to fold in LUCENE-5461.

Mike McCandless

http://blog.mikemccandless.com


On Fri, Feb 21, 2014 at 6:44 AM, Simon Willnauer
<si...@gmail.com> wrote:
> Martjin can you fix that in 4x and master and also in 47 in the case we respin?
>
> On Fri, Feb 21, 2014 at 12:31 PM, Martijn v Groningen
> <ma...@gmail.com> wrote:
>> +1
>>
>> SUCCESS! [1:52:31.345809]
>>
>> Only spotted a small docs typo in the Lucene CHANGES.txt, the second issue
>> under "Changes in Runtime Behavior" should be LUCENE-5399 instead of
>> LUCENE-4399.
>>
>>
>> On 21 February 2014 02:50, Mark Miller <ma...@gmail.com> wrote:
>>>
>>> +1
>>>
>>> SUCCESS! [1:05:52.694842]
>>>
>>> - Mark
>>>
>>> http://about.me/markrmiller
>>>
>>> On Feb 20, 2014, at 3:52 PM, Simon Willnauer <si...@gmail.com>
>>> wrote:
>>>
>>> > Please vote for the third Release Candidate for Lucene/Solr 4.7.0
>>> >
>>> > you can download it here:
>>> >
>>> > http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC3-rev1570248/
>>> >
>>> > or run the smoke tester directly with this commandline (don't forget
>>> > to set JAVA6_HOME etc.):
>>> >
>>> > $ python3.2 -u dev-tools/scripts/smokeTestRelease.py
>>> >
>>> > http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC3-rev1570248/
>>> > 1570248 4.7.0 /tmp/smoke_test_4_7
>>> >
>>> > Smoketester said: SUCCESS!
>>> >
>>> > here is my +1
>>> >
>>> > ---------------------------------------------------------------------
>>> > 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
>>>
>>
>>
>>
>> --
>> Met vriendelijke groet,
>>
>> Martijn van Groningen
>
> ---------------------------------------------------------------------
> 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

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Simon Willnauer <si...@gmail.com>.

Martjin can you fix that in 4x and master and also in 47 in the case we respin?

On Fri, Feb 21, 2014 at 12:31 PM, Martijn v Groningen
<ma...@gmail.com> wrote:
> +1
>
> SUCCESS! [1:52:31.345809]
>
> Only spotted a small docs typo in the Lucene CHANGES.txt, the second issue
> under "Changes in Runtime Behavior" should be LUCENE-5399 instead of
> LUCENE-4399.
>
>
> On 21 February 2014 02:50, Mark Miller <ma...@gmail.com> wrote:
>>
>> +1
>>
>> SUCCESS! [1:05:52.694842]
>>
>> - Mark
>>
>> http://about.me/markrmiller
>>
>> On Feb 20, 2014, at 3:52 PM, Simon Willnauer <si...@gmail.com>
>> wrote:
>>
>> > Please vote for the third Release Candidate for Lucene/Solr 4.7.0
>> >
>> > you can download it here:
>> >
>> > http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC3-rev1570248/
>> >
>> > or run the smoke tester directly with this commandline (don't forget
>> > to set JAVA6_HOME etc.):
>> >
>> > $ python3.2 -u dev-tools/scripts/smokeTestRelease.py
>> >
>> > http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC3-rev1570248/
>> > 1570248 4.7.0 /tmp/smoke_test_4_7
>> >
>> > Smoketester said: SUCCESS!
>> >
>> > here is my +1
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>
>
>
> --
> Met vriendelijke groet,
>
> Martijn van Groningen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Martijn v Groningen <ma...@gmail.com>.

+1

SUCCESS! [1:52:31.345809]

Only spotted a small docs typo in the Lucene CHANGES.txt, the second issue
under "Changes in Runtime Behavior" should be LUCENE-5399 instead of
LUCENE-4399.


On 21 February 2014 02:50, Mark Miller <ma...@gmail.com> wrote:

> +1
>
> SUCCESS! [1:05:52.694842]
>
> - Mark
>
> http://about.me/markrmiller
>
> On Feb 20, 2014, at 3:52 PM, Simon Willnauer <si...@gmail.com>
> wrote:
>
> > Please vote for the third Release Candidate for Lucene/Solr 4.7.0
> >
> > you can download it here:
> >
> http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC3-rev1570248/
> >
> > or run the smoke tester directly with this commandline (don't forget
> > to set JAVA6_HOME etc.):
> >
> > $ python3.2 -u dev-tools/scripts/smokeTestRelease.py
> >
> http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC3-rev1570248/
> > 1570248 4.7.0 /tmp/smoke_test_4_7
> >
> > Smoketester said: SUCCESS!
> >
> > here is my +1
> >
> > ---------------------------------------------------------------------
> > 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
>
>


-- 
Met vriendelijke groet,

Martijn van Groningen

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Mark Miller <ma...@gmail.com>.

+1

SUCCESS! [1:05:52.694842]

- Mark

http://about.me/markrmiller

On Feb 20, 2014, at 3:52 PM, Simon Willnauer <si...@gmail.com> wrote:

> Please vote for the third Release Candidate for Lucene/Solr 4.7.0
> 
> you can download it here:
> http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC3-rev1570248/
> 
> or run the smoke tester directly with this commandline (don't forget
> to set JAVA6_HOME etc.):
> 
> $ python3.2 -u dev-tools/scripts/smokeTestRelease.py
> http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC3-rev1570248/
> 1570248 4.7.0 /tmp/smoke_test_4_7
> 
> Smoketester said: SUCCESS!
> 
> here is my +1
> 
> ---------------------------------------------------------------------
> 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

Re: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Martijn v Groningen <ma...@gmail.com>.

Simon, I'll fix the typo in CHANGES.txt and also move the issue under
optimisations as Robert suggested.


On 21 February 2014 14:24, Uwe Schindler <uw...@thetaphi.de> wrote:

> SUCCESS! [2:00:24.392734]
>
> One thing we should fix in the future: The MANIFEST.MF of almost all JAR
> files contains the following line:
>
>         Main-Class: ${main.class}
>
> This happens because the ANT property "main.class" is undefined for most
> modules. Maybe this was added for one of the modules (I assume that the
> Solr-Morphline JARs use this attribute?). We should add some if/then/else
> structure to the <jarify/> task that only sets this property, if it is
> actually defined. Otherwise remove it (I think ANT does this automatically
> if its empty, means string-empty, have to try out)
>
> This leads to an error if the file is double-clicked or started via "java
> -jar":
>
> C:\Users\Uwe Schindler\Desktop>java -jar lucene-core-4.7.0.jar
> Fehler: Hauptklasse ${main.class} konnte nicht gefunden oder geladen werden
>
> Uwe
>
> This is not terrible so it should hold the release, but if we respin, we
> should fix it. I will open an issue.
>
> Nevertheless, +1 to release!
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
> > -----Original Message-----
> > From: Simon Willnauer [mailto:simon.willnauer@gmail.com]
> > Sent: Thursday, February 20, 2014 9:52 PM
> > To: dev@lucene.apache.org
> > Subject: [VOTE] Lucene / Solr 4.7.0 RC3
> >
> > Please vote for the third Release Candidate for Lucene/Solr 4.7.0
> >
> > you can download it here:
> > http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC3-
> > rev1570248/
> >
> > or run the smoke tester directly with this commandline (don't forget to
> set
> > JAVA6_HOME etc.):
> >
> > $ python3.2 -u dev-tools/scripts/smokeTestRelease.py
> > http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC3-
> > rev1570248/
> > 1570248 4.7.0 /tmp/smoke_test_4_7
> >
> > Smoketester said: SUCCESS!
> >
> > here is my +1
> >
> > ---------------------------------------------------------------------
> > 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
>
>


-- 
Met vriendelijke groet,

Martijn van Groningen

RE: [VOTE] Lucene / Solr 4.7.0 RC3

Posted by Uwe Schindler <uw...@thetaphi.de>.

SUCCESS! [2:00:24.392734]

One thing we should fix in the future: The MANIFEST.MF of almost all JAR files contains the following line:

	Main-Class: ${main.class}

This happens because the ANT property "main.class" is undefined for most modules. Maybe this was added for one of the modules (I assume that the Solr-Morphline JARs use this attribute?). We should add some if/then/else structure to the <jarify/> task that only sets this property, if it is actually defined. Otherwise remove it (I think ANT does this automatically if its empty, means string-empty, have to try out)

This leads to an error if the file is double-clicked or started via "java -jar":

C:\Users\Uwe Schindler\Desktop>java -jar lucene-core-4.7.0.jar
Fehler: Hauptklasse ${main.class} konnte nicht gefunden oder geladen werden

Uwe

This is not terrible so it should hold the release, but if we respin, we should fix it. I will open an issue.

Nevertheless, +1 to release!

Uwe

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de


> -----Original Message-----
> From: Simon Willnauer [mailto:simon.willnauer@gmail.com]
> Sent: Thursday, February 20, 2014 9:52 PM
> To: dev@lucene.apache.org
> Subject: [VOTE] Lucene / Solr 4.7.0 RC3
> 
> Please vote for the third Release Candidate for Lucene/Solr 4.7.0
> 
> you can download it here:
> http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC3-
> rev1570248/
> 
> or run the smoke tester directly with this commandline (don't forget to set
> JAVA6_HOME etc.):
> 
> $ python3.2 -u dev-tools/scripts/smokeTestRelease.py
> http://people.apache.org/~simonw/staging_area/lucene-solr-4.7.0-RC3-
> rev1570248/
> 1570248 4.7.0 /tmp/smoke_test_4_7
> 
> Smoketester said: SUCCESS!
> 
> here is my +1
> 
> ---------------------------------------------------------------------
> 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