Re: [RT] working with patches vs. branches?
Whoops, hit send too fast ... : : branch work should be included in the trunk. So we don't need to be : : zealous about branches / no branches (and I don't think anyone here : : is). ...i was going to add that i personally don't feel like a branch would be neccessary for most of the currently existing Jira issues ... but i would certianly think it might be a good idea if/when someone is ready to tackle "Make use of [WWW] HiveMind or Spring" or maybe even "FederatedSearch" ... it all depends on how expansive the changes need to and how long of a development process is anticipated. -Hoss
Re: [RT] working with patches vs. branches?
: for sure. Even so, I only think they're worth the maintenance and : merging hassle for really major things. Of course "really major" is ... : That said, if a developer has a major piece of work he/she wants to : work on, and feels uneasy about doing it on trunk, he/she is more than : welcome to create and maintain a branch for this purpose. The onus is ... : branch work should be included in the trunk. So we don't need to be : zealous about branches / no branches (and I don't think anyone here : is). +1, +1, +1 -Hoss
Re: [RT] working with patches vs. branches?
Hi, I mostly agree with Hoss and Yonik. Use patches, it's easy, trunk doesn't have to be stable, retain the Review Then Commit (RTC) style of development. Keep development fluid, don't gate it with more process than necessary (e.g. major branch merging). Branches are significantly easier with SVN than they were with CVS, for sure. Even so, I only think they're worth the maintenance and merging hassle for really major things. Of course "really major" is subjectives, so here are some examples. In Tomcat we traditionally made a branch only for major versions of the server (3.x, 4.x, 5.x, 6.x) that implement new versions of the Servlet and JSP specifications. Work is done only on the trunk for many months at a time. In log4j we've never really had concurrent development on multiple branches, work is done in the trunk, just like Lucene. The other incubating projects I'm currently involved with (OFBiz, lokahi, XAP) are the same way as Hoss and Yonik described for Solr. That said, if a developer has a major piece of work he/she wants to work on, and feels uneasy about doing it on trunk, he/she is more than welcome to create and maintain a branch for this purpose. The onus is on him/her to properly merge the work back once there's consensus the branch work should be included in the trunk. So we don't need to be zealous about branches / no branches (and I don't think anyone here is). Yoav On 11/17/06, Yonik Seeley <[EMAIL PROTECTED]> wrote: On 11/17/06, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > : IIUC the agreed way of working is to do all important changes as > : patches in Jira, discuss them and only commit once we agree on them? > > I would rephrase as: "attach to jira, see if any one has > comments/objections and commit once they've had a little time to soak." For changes that a committer feels are obvious or non-contentious (and not likely to be improved by review), I think they should just commit them. We have a review-after-commit policy too. For example, Mike's recent fix of field boosts was an important fix, but simply committing it w/o a JIRA issue was fine IMO. Changes of any nature that are copyrightable (have originality, etc) and come from non-committers should go through JIRA I think (for IP documentation purposes). People should be able to count on the fact that commits without JIRA issues originate from committers only. As far as branches go, I've not used them (because Lucene really hasn't), so I don't have much to go by. I would be concerned about the ability to easily "see" what a patch consists of from a simple link in the JIRA bug though. -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server
[jira] Commented: (SOLR-71) New support for "Date Math" when adding/quering date fields
[ http://issues.apache.org/jira/browse/SOLR-71?page=comments#action_12450981 ] Bertrand Delacretaz commented on SOLR-71: - This looks like a very useful feature! > New support for "Date Math" when adding/quering date fields > --- > > Key: SOLR-71 > URL: http://issues.apache.org/jira/browse/SOLR-71 > Project: Solr > Issue Type: New Feature > Components: search, update >Reporter: Hoss Man > Assigned To: Hoss Man > Attachments: DateMath.patch > > > New utility class and changes to DateField to support syntax like the > following... > startDate:[* TO NOW] > startDate:[* TO NOW/DAY+1DAY] > expirationDate:[NOW/DAY TO *] > reviewDate:[NOW/DAY-1YEAR TO NOW/DAY] > validDate:[NOW/MONTH TO NOW/MONTH+1MONTH-1MILLISECOND] > ...where + and - mean what you think, and "/UNIT" rounds down to the nearest > UNIT. The motivation for this being that date range queries like these are > usefull for filters, but being date sensitve can't currently be "baked in" to > a config as default params. > a nice side effect of the implimentation, is that "timestamp" fields can be > done with a document is added by using... >NOW > ...and Solr will compute the value when adding the document ... if we add > default values to the schema.xml even that won't be neccessary. > Comments? > (I'd be particularly gratefull if smarter people then I would sanity check my > use of ThreadLocal for managing the DateFormat in DateField ... i've never > used ThreadLocal before. Any general comments on the syntax would also be > appreciated: This left-to-right syntax seemed more intuative to write (and > easier to parse) then some of the other syntaxes I'd considered) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
