[Rivet] installation

[Andy Buckley]

On 27/01/14 17:20, Frank Siegert wrote:
> Hi Andy and David,
> 
>> As Frank S just made clear, the big problem seems to be for people who
>> want to install the development trunk in order to get new, _unreleased_
>> analyses. I didn't even know that people were doing that: the
>> experimenters I'm in touch with certainly aren't. It reopens (difficult)
>> questions about whether we can make analysis releases more timely, but I
>> think you need to appreciate that building an unreleased Rivet branch
>> from version control isn't something that we advise anyone to do,
> 
> But we used to be advising this and supported it in the bootstrap script.

I think it was in the script "for completeness", and for the developers
who wanted to use the script. Plus of course we had Rivet 2 in a state
without tarballs for a *long* time, and the 1.x branch also stagnated
during that time. Now that we have made the step of releasing v2 and are
in the process of deprecating v1 support, I think we should aim to treat
the release/dev separation strictly, at least just because building from
version control is more complex and we can't possibly provide widespread
support for users who insist on doing that.

>> nor
>> has any particular effort been spent on making it easy. It specifically
>> requires several non-trivial developer tools which aren't needed at all
>> for the releases, so for people who take the "standard route" to use
>> Rivet the issue never arises. Apologies for any "touch luck" subtext
>> that made it into my reply, but that's a bit like me checking out the
>> Sherpa 2 trunk a year ago and then complaining to you that your
>> development code is unstable and unprofessional!
> 
> No, that comparison is flawed, because Sherpa does not get
> contributions from the outside and has thus some responsibility of
> making them available in a timely manner.

I guess you mean that Rivet *has* that responsibility and Sherpa
doesn't. I agree, and getting releases out on time is one of the places
where our manpower shortage really hurts. By the way, we just today
announced a new postdoc job at Glasgow to make this situation better:

http://www22.i-grasp.com/fe/tpl_glasgow01.asp?s=4A515F4E5A565B1A&jobid=74829,2198478612&key=131575416&c=21873486874765&pagestamp=seqxvflngupnafmeqv

Given that you obviously really want to use analyses in the release-2-0
branch, I suggest that we make a 2.1.0 release as soon as possible,
missing the few analyses which require more complex AIDA-to-YODA
conversion. We could really do with help with these for 2.1.1. Sound ok?

> I still think that the development trunk usage is Ok (until we come up
> with a code/analyses separation, which I don't see as feasible). This
> comes with limited support of course, but at least it shouldn't be
> made harder than necessary.

Hmm, I'm not sure about ok, and very probably what I say here will be
contradicted by something I've said in the past! My impression, or at
least intention, has been to keep normal users on the tarball releases
only. In particular cases when someone has asked about an analysis or
feature which is only available in the trunk, and which is stable and
just about to be released, I've pointed them at the dev version. I hope
I'm not wrong about it, but I don't think we've ever operated a "the
trunk is stable and you're welcome to use it to get physics results"
policy. There was also maybe the hope that getting some people to use
the dev version would feed them into the developer team, but I don't
think that ever happened so let's forget it as an argument to work that way!

With the move to hg, Cython, etc. the dev build *is* harder than before
-- the tradeoff was to make life a bit harder for the three or four
developers who could handle it, and easier for the multitude of actual
or potential normal users. With the move to version 2, the trunk is
unsuitable for use by most "typical" users, and hasn't been encouraged
at all -- hence the removal of the dev options from the new bootstrap
scripts.

You all know how little manpower we've had (sorry for moaning on about
it), so if you need to use unreleased analyses then please let us all
know your desire for a new release asap, and we can plan it. The 2.1.0
release has been held up for the last 1+ months by my lack of time, but
if someone else was to offer to make the remaining changes then we could
have got it out. That's partially my fault for not dredging up some
activity, but I think the release plan and the slipping timescale were
pretty obvious...

> And the switch from rivet-bootstrap ->
> rivet-[12]-bootstrap must have made that impression on users.

I'm not sure what impression you mean. I'm with you on the need for a
version of the tarball bootstrap which doesn't depend on LCG packages
(although this *maybe* could be merged with the LCG version to avoid
wholesale duplication). But I explicitly didn't make a dev version of
the new bootstrap script, and on this list explained recently to Will
Bell some of the motivations for that.

Having an internal dev bootstrap script to help some developers get up
and running, in particular for framework development is fine, but I
don't think we should be making it public or encouraging people to work
with Rivet in that way, and if the problem is that analyses aren't going
public fast enough, then we should deal with that particular problem by
making more minor releases (which also requires more developers) rather
than tell people to use the dev branch which doesn't get us any closer
to a release and forces people to work with a more complex setup and
potentially unstable/unvalidated code.

Andy

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