just my thoughts:
On Fri, Feb 21, 2014 at 9:34 AM, Simon Willnauer <simon.willna...@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.
