[Rivet] boost.m4 BOOST_FIND_LIB

[Andy Buckley]

As I said before, I really want to keep any new developments out of the
current default branch until 2.0.0 is out.

The b-tag feature is nice, but definitely not complete: it would be good
to be able to tag via c hadrons too... and I wonder if it would be
useful to "tau tag" for identification/removal of jets from hadronic tau
decays. I would also like to tie this in with an overhaul of the whole
jets system to more tightly integrate with FastJet's machinery: it seems
most natural to me that we should be able to ask a Jet about its tag
status, and probably *which* b's/c's/taus are matched to that jet (for a
particular definition). This might be the point at which we decide to
only support FastJet3, and would certainly be a new 2nd-digit Rivet
version: I'm thinking of this and the Cuts system as targetted for Rivet
2.1.

Anyway, the general point is that we should review changes to the API
carefully rather than just dropping them in -- we have a lot of users
now, so should avoid flip-flopping the interface design in-between every
release. And I also need to learn a bit more about how best to work with
feature development branches in hg/git!

Andy


On 16/07/13 15:01, James Monk wrote:
> Hi David,
> 
> Sorry about that.  Why can't we use named branches for feature developments - it seems like that would be the ideal use for them.  Creating a clone of the repository each time I want to add a feature seems quite inefficient, and if it is in private, is it even available to anyone except me?  Having gzip is quite useful, and I don't see that it needs to be kept private, it's just not in the main release because of potential build issues.
> 
> The jet tagging feature *shouldn't* cause a problem - it just adds a (hopefully useful!) new member function to the FastJets projection.  It has to run an UnstableFinalState projection and keep a record of which particles to tag when it applies the jet projection, so from that point of view the most conservative thing would be to roll back the changes, but there really shouldn't be any difference in the results compared to the older version.  The main issue is that the feature is not yet fully developed.  Does hg really have a problem in rolling back the changes?
> 
> cheers,
> 
> James
> 
> On 16 Jul 2013, at 14:00, David Grellscheid wrote:
> 
>> Hi all,
>>
>>> There's a new branch called "gzip" with the iostreams dependency.  I
>>> don't understand why, but it's also put the jet tagging stuff into
>>> the default branch rather than on its own branch as it was on my
>>> repository
>>
>> On your own repository, it was in "default", therefore it stays in
>> default.  We've got a mess now, where the jet tagging stuff cannot
>> easily be untangled again. To push only the branch where you currently
>> are, you need to say 'hg push -r .'.
>>
>> To create a new feature, clone _trunk_ into its own directory in
>> hg-private. DO NOT USE NAMED BRANCHES for feature developments.
>>
>>> - I merged the trunk onto the jet-tagging, but I guess
>>> this meant there was only a single tip?  Will this fix itself the
>>> next time someone pushes into the repo?
>>
>> No. Not if they follow the usual workflow. You have basically published
>> jet-tagging now. If that is a problem, and we need to develop rivet
>> without jet-tagging, work will need to be based off Frank Siegert's
>> checkin 18a418573dff.
>>
>> I have marked the failed merge as closed, so most users who are unaware
>> should see the right behaviour. But please let me know before pushing
>> stuff to the public repo.
>>
>> Thanks,
>>
>>   David
>> _______________________________________________
>> Rivet mailing list
>> Rivet at projects.hepforge.org
>> http://www.hepforge.org/lists/listinfo/rivet
> 
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> http://www.hepforge.org/lists/listinfo/rivet
> 


-- 
Dr Andy Buckley, Royal Society University Research Fellow
Particle Physics Expt Group, University of Edinburgh / PH Dept, CERN