Re: Release of SOLR 1.3
On 20-May-08, at 12:32 PM, Shalin Shekhar Mangar wrote: +1 for your suggestions Mike. I'd like to see a few of the smaller issues get committed in 1.3 such as SOLR-256 (JMX), SOLR-536 (binding for SolrJ), SOLR-430 (SpellChecker support in SolrJ) etc. Also, SOLR-561 (replication by Solr) would be really cool to have in the next release. Noble and I are working on it and plan to give a patch soon. Whether something makes it in to this release will depend mostly on getting the buy-in and time commitment from one of the committers familiar with that aspect of the project. There is so much in 1.3 as it is that I think our focus should be on getting it out sooner rather than adding things. But small things that significantly improve the release are good too. SOLR-561 seems like a rather large project to me (although I have never even used the existing collection distribution method). Mike -- you removed SOLR-563 (Contrib area for Solr) from 1.3 but it is a dependency for SOLR-469 (DataImportHandler) as it was decided to have DataImportHandler as a contrib project. It would also be good to have a rough release roadmaps to work against. Can fixed release cycle (say every 6 months) work for Solr? Twice-yearly releases would be nice to aim for, but I think we're too small a project to fix release dates in advance. -Mike
Re: Release of SOLR 1.3
Hey, 2008/5/21 Chris Hostetter [EMAIL PROTECTED]: : I'd tend to disagree: committing the patches to trunk allows widespread : testing and the chance for wider review of the code to see if it does : what it should. Only when the code is part of a release is there any : obligation to a proper lifecycle (ongoing support, deprecation, then : finally removal). True .. but once something is commited it's hard to extract if people decide they are unhappy with the API/implementation prior to a formal release. The general philosophy about committing in Solr is outlined on the wiki... http://wiki.apache.org/solr/CommitPolicy Sure, Commit-Then-Review vs. Review-Then-Commit ... but I don't actually think RTC is going to ensure significantly more widespread review since the time burden on other developers to find the issue in JIRA, download the patch, apply the patch, test, respond, then revert the change. Do people really have the time to do that? It's significantly more effort than that to svn update, look at code, and feed back. I prefer detailed discussion on the mailing list (which supports decent threading, quoting etc, unlike JIRA) followed by commit of a trial implementation which can then be refactored. Otherwise there might be a tendency to analysis paralysis. But I'm the new boy here, so I'll STFU and try to help out on the release instead of forcing y'all to rehash old discussions on how to run an open source project ;-) Maybe by the time 1.3 is out the door we'll all be using distributed SCM systems and the discussion will be moot anyway! Andrew. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] http://www.andrewsavory.com/
Re: Release of SOLR 1.3
On 22-May-08, at 12:13 AM, Andrew Savory wrote:
Sure, Commit-Then-Review vs. Review-Then-Commit ... but I don't
actually think RTC is going to ensure significantly more widespread
review since the time burden on other developers to find the issue in
JIRA, download the patch, apply the patch, test, respond, then revert
the change. Do people really have the time to do that? It's
significantly more effort than that to svn update, look at code, and
feed back. I prefer detailed discussion on the mailing list (which
supports decent threading, quoting etc, unlike JIRA) followed by
commit of a trial implementation which can then be refactored.
Otherwise there might be a tendency to analysis paralysis. But I'm the
new boy here, so I'll STFU and try to help out on the release instead
of forcing y'all to rehash old discussions on how to run an open
source project ;-) Maybe by the time 1.3 is out the door we'll all be
using distributed SCM systems and the discussion will be moot anyway!
I think we agree in principle--a patch does not have to be spotless to
be committed. I also agree that that mailinglist is a preferable
place to hash out design details. But it is necessary that the basic
approach is one we feel will stick with before getting committed. I
don't think this imposes much of a burden on people aiming to review a
patch.
It is true that using patches takes an extra minute or two to set up,
but the time to evaluate a contribution is _by far_ mostly contained
in understanding the contribution, its implications, and examining the
code. Plus, the patch is much easier to back out of a given
repository and makes it easier to see exactly what changes were made.
Since contributors can't commit to the repository anyway, I don't see
much disadvantage in working with patches.
(btw, if you want a one-line equivalent to svn up, try something like:
$ wget http://issues.apache.org/jira/secure/attachment/12381498/SOLR-563.patch
-O - | patch -p0
Reverting is also one line:
$ svn revert -R .
Although this leaves added files, which can be removed with
$ svn st | grep '?' | awk '{print $2}' | xargs rm
Another useful trick is to have multiple checkouts of trunk and
bounce an active changeset from one to another with
$ svn diff | (cd ../otherbranch; patch -p0)
)
-Mike
-Mike
Re: Release of SOLR 1.3
Hi Mike,
2008/5/22 Mike Klaas [EMAIL PROTECTED]:
(btw, if you want a one-line equivalent to svn up, try something like:
$ wget
http://issues.apache.org/jira/secure/attachment/12381498/SOLR-563.patch -O -
| patch -p0
Reverting is also one line:
$ svn revert -R .
Although this leaves added files, which can be removed with
$ svn st | grep '?' | awk '{print $2}' | xargs rm
Another useful trick is to have multiple checkouts of trunk and bounce an
active changeset from one to another with
$ svn diff | (cd ../otherbranch; patch -p0)
)
Useful indeed - thanks for those, Mike, I'm sure they'll come in handy!
Andrew.
--
[EMAIL PROTECTED] / [EMAIL PROTECTED]
http://www.andrewsavory.com/
Re: Release of SOLR 1.3
+1 The code has changed so radically between Solr1.2 and Solr1.3 .Because 1.3 is not released most of us have to stick to 1.2 . So anything that we build must work on 1.2 and if I wish to contribute back to Solr it has to be 1.3 compatible. SOLR-469 is a good example where I had to really hack my code hard to ensure that I contained the version specific dependencies to one file . This is a good starting point . Let us get the list of issues which can be easily fixed and apply the patches and push out a release . --Noble On Tue, May 20, 2008 at 2:23 PM, Andrew Savory [EMAIL PROTECTED] wrote: Hi, (discussion moved from -user to -dev) 2008/5/19 Chris Hostetter [EMAIL PROTECTED]: If people are particularly eager to see a 1.3 release, the best thing to do is subscribe to solr-dev and start a dialog there about what issues people thing are show stopers for 1.3 and what assistance the various people working on those issues can use. So, what are the show stoppers, how can we help, what can we reassign to a future release? Taking a look through the list there's quite a few issues with patches attached that aren't applied yet. Clearing these out would cut the open bug count by almost half: SOLR-515 SOLR-438 SOLR-351 (applied?) SOLR-281 (applied?) SOLR-424 SOLR-243 (stuck in review hell?) SOLR-433 SOLR-510 SOLR-139 SOLR-521 (applied, waiting to be closed) SOLR-284 SOLR-560 SOLR-469 SOLR-572 SOLR-565 It's a little weird to see patch 'development' going on in JIRA (sometimes for over a year), rather than getting the patches into svn and then working there... I'd worry that some valuable code history is getting lost along the way? Yes, it's a tough call between adding 'bad' code and waiting for the perfect patch, but bad code creates healthy communities and is better than no code :-) Andrew. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] http://www.andrewsavory.com/ -- --Noble Paul
Re: Release of SOLR 1.3
On 20-May-08, at 1:53 AM, Andrew Savory wrote: 2008/5/19 Chris Hostetter [EMAIL PROTECTED]: If people are particularly eager to see a 1.3 release, the best thing to do is subscribe to solr-dev and start a dialog there about what issues people thing are show stopers for 1.3 and what assistance the various people working on those issues can use. So, what are the show stoppers, how can we help, what can we reassign to a future release? I've gone and reassigned a bunch of issues that were labeled 1.3 by the original submitter, if the submitter is not a committer (perhaps this field shouldn't be editable by everyone). That still leaves many issues, several of which I don't think are critical for 1.3. I propose that we follow an ownership process for getting this release out the door: we give committers a week to fill in the assigned to field in JIRA for the 1.3 issues. Any issue that isn't assigned after one week gets moved to a future release. Then we can each evaluate the issues we are responsible for. Any non-1.3-marked issues should be added at this time too. Taking a look through the list there's quite a few issues with patches attached that aren't applied yet. Clearing these out would cut the open bug count by almost half: But then we'd have to open bug reports for each one that says make sure this actually works and that it is the correct direction for Solr :) It's a little weird to see patch 'development' going on in JIRA (sometimes for over a year), rather than getting the patches into svn and then working there... I'd worry that some valuable code history is getting lost along the way? Yes, it's a tough call between adding 'bad' code and waiting for the perfect patch, but bad code creates healthy communities and is better than no code :-) Committing the code to trunk creates a path dependence and responsibility for maintaining the code. There would also be a high probability of trunk never being in a releasable state, given the chance of there being a half-baked idea in trunk that we don't want to be bound to for the rest of Solr's lifetime. (incidentally, this is the same philosophy we apply at my company, except that development is usually done in branches rather than patches.) -Mike
Re: Release of SOLR 1.3
+1 for your suggestions Mike. I'd like to see a few of the smaller issues get committed in 1.3 such as SOLR-256 (JMX), SOLR-536 (binding for SolrJ), SOLR-430 (SpellChecker support in SolrJ) etc. Also, SOLR-561 (replication by Solr) would be really cool to have in the next release. Noble and I are working on it and plan to give a patch soon. Mike -- you removed SOLR-563 (Contrib area for Solr) from 1.3 but it is a dependency for SOLR-469 (DataImportHandler) as it was decided to have DataImportHandler as a contrib project. It would also be good to have a rough release roadmaps to work against. Can fixed release cycle (say every 6 months) work for Solr? On Wed, May 21, 2008 at 12:45 AM, Mike Klaas [EMAIL PROTECTED] wrote: On 20-May-08, at 1:53 AM, Andrew Savory wrote: 2008/5/19 Chris Hostetter [EMAIL PROTECTED]: If people are particularly eager to see a 1.3 release, the best thing to do is subscribe to solr-dev and start a dialog there about what issues people thing are show stopers for 1.3 and what assistance the various people working on those issues can use. So, what are the show stoppers, how can we help, what can we reassign to a future release? I've gone and reassigned a bunch of issues that were labeled 1.3 by the original submitter, if the submitter is not a committer (perhaps this field shouldn't be editable by everyone). That still leaves many issues, several of which I don't think are critical for 1.3. I propose that we follow an ownership process for getting this release out the door: we give committers a week to fill in the assigned to field in JIRA for the 1.3 issues. Any issue that isn't assigned after one week gets moved to a future release. Then we can each evaluate the issues we are responsible for. Any non-1.3-marked issues should be added at this time too. Taking a look through the list there's quite a few issues with patches attached that aren't applied yet. Clearing these out would cut the open bug count by almost half: But then we'd have to open bug reports for each one that says make sure this actually works and that it is the correct direction for Solr :) It's a little weird to see patch 'development' going on in JIRA (sometimes for over a year), rather than getting the patches into svn and then working there... I'd worry that some valuable code history is getting lost along the way? Yes, it's a tough call between adding 'bad' code and waiting for the perfect patch, but bad code creates healthy communities and is better than no code :-) Committing the code to trunk creates a path dependence and responsibility for maintaining the code. There would also be a high probability of trunk never being in a releasable state, given the chance of there being a half-baked idea in trunk that we don't want to be bound to for the rest of Solr's lifetime. (incidentally, this is the same philosophy we apply at my company, except that development is usually done in branches rather than patches.) -Mike -- Regards, Shalin Shekhar Mangar.
Re: Release of SOLR 1.3
Hi, Half-baked things getting into trunk probably won't happen. Lots of people use Solr nightlies (cause they are often stable enough). If we were a bunch paid to work on Solr, then we'd be more organized/structured and have more regular release cycles. Solr is also not likely to have a very short lifetime -- too many people use it, develop for it, and depend on it. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message From: Andrew Savory [EMAIL PROTECTED] To: solr-dev@lucene.apache.org Sent: Tuesday, May 20, 2008 3:51:50 PM Subject: Re: Release of SOLR 1.3 Hi Mike, On 20/05/2008, Mike Klaas wrote: I've gone and reassigned a bunch of issues that were labeled 1.3 by the original submitter, if the submitter is not a committer (perhaps this field shouldn't be editable by everyone). That still leaves many issues, several of which I don't think are critical for 1.3. Cool, thanks for that. Indeed, assigning issues to releases should only be possible by committers. Taking a look through the list there's quite a few issues with patches attached that aren't applied yet. Clearing these out would cut the open bug count by almost half: But then we'd have to open bug reports for each one that says make sure this actually works and that it is the correct direction for Solr :) Heh. Thankfully many of the patches look well-tested and extremely well discussed already, so I'd hope they wouldn't require too many followup issues! It's a little weird to see patch 'development' going on in JIRA (sometimes for over a year), rather than getting the patches into svn and then working there... I'd worry that some valuable code history is getting lost along the way? Yes, it's a tough call between adding 'bad' code and waiting for the perfect patch, but bad code creates healthy communities and is better than no code :-) Committing the code to trunk creates a path dependence and responsibility for maintaining the code. There would also be a high probability of trunk never being in a releasable state, given the chance of there being a half-baked idea in trunk that we don't want to be bound to for the rest of Solr's lifetime. I'd tend to disagree: committing the patches to trunk allows widespread testing and the chance for wider review of the code to see if it does what it should. Only when the code is part of a release is there any obligation to a proper lifecycle (ongoing support, deprecation, then finally removal). Of course, being concerned for the state of trunk is a good thing overall, but it seems from my casual observation that some contributions that are far from half-baked are not making it into trunk: this is even worse as it might lead to an unnaturally short lifetime for Solr. (incidentally, this is the same philosophy we apply at my company, except that development is usually done in branches rather than patches.) Sure, I'm currently working in a branch-per-feature environment, and it has some advantages for a corporate environment with no community concerns. But here we're talking about consensus-driven open development, for which a more open approach may be appropriate. True, it may seem chaotic and perhaps a bit risky - but with enough eyes on the code we can mitigate that risk. And hey, if some contributions are really controversial, there's always the option to do more branches (or even set up a scratchpad). Just my €0.02! Andrew. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] http://www.andrewsavory.com/
Re: Release of SOLR 1.3
I'll take the contrib/ issue if nobody else does. I would want to see that one in 1.3, so we can get DataImportHandler in. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message From: Shalin Shekhar Mangar [EMAIL PROTECTED] To: solr-dev@lucene.apache.org Sent: Tuesday, May 20, 2008 3:32:21 PM Subject: Re: Release of SOLR 1.3 +1 for your suggestions Mike. I'd like to see a few of the smaller issues get committed in 1.3 such as SOLR-256 (JMX), SOLR-536 (binding for SolrJ), SOLR-430 (SpellChecker support in SolrJ) etc. Also, SOLR-561 (replication by Solr) would be really cool to have in the next release. Noble and I are working on it and plan to give a patch soon. Mike -- you removed SOLR-563 (Contrib area for Solr) from 1.3 but it is a dependency for SOLR-469 (DataImportHandler) as it was decided to have DataImportHandler as a contrib project. It would also be good to have a rough release roadmaps to work against. Can fixed release cycle (say every 6 months) work for Solr? On Wed, May 21, 2008 at 12:45 AM, Mike Klaas wrote: On 20-May-08, at 1:53 AM, Andrew Savory wrote: 2008/5/19 Chris Hostetter : If people are particularly eager to see a 1.3 release, the best thing to do is subscribe to solr-dev and start a dialog there about what issues people thing are show stopers for 1.3 and what assistance the various people working on those issues can use. So, what are the show stoppers, how can we help, what can we reassign to a future release? I've gone and reassigned a bunch of issues that were labeled 1.3 by the original submitter, if the submitter is not a committer (perhaps this field shouldn't be editable by everyone). That still leaves many issues, several of which I don't think are critical for 1.3. I propose that we follow an ownership process for getting this release out the door: we give committers a week to fill in the assigned to field in JIRA for the 1.3 issues. Any issue that isn't assigned after one week gets moved to a future release. Then we can each evaluate the issues we are responsible for. Any non-1.3-marked issues should be added at this time too. Taking a look through the list there's quite a few issues with patches attached that aren't applied yet. Clearing these out would cut the open bug count by almost half: But then we'd have to open bug reports for each one that says make sure this actually works and that it is the correct direction for Solr :) It's a little weird to see patch 'development' going on in JIRA (sometimes for over a year), rather than getting the patches into svn and then working there... I'd worry that some valuable code history is getting lost along the way? Yes, it's a tough call between adding 'bad' code and waiting for the perfect patch, but bad code creates healthy communities and is better than no code :-) Committing the code to trunk creates a path dependence and responsibility for maintaining the code. There would also be a high probability of trunk never being in a releasable state, given the chance of there being a half-baked idea in trunk that we don't want to be bound to for the rest of Solr's lifetime. (incidentally, this is the same philosophy we apply at my company, except that development is usually done in branches rather than patches.) -Mike -- Regards, Shalin Shekhar Mangar.
