Re:[BLAST_ANAWARE] BlastLib policy

From: Tancredi Botto (tancredi@mitlns.mit.edu)
Date: Tue Nov 26 2002 - 20:19:00 EST


Chi, your work is important (as everybody's else ) and of course you are
encouraged to update the library. I don't understand why people don't compile
and test their code first, on the other hand we are a small group and chances
that two people are changing the same class at the same time seem slim. But ok,

let me be very simple

_ the online code works, I don't want you or anybody to change it. I have
  to be responsible for that not you (infact people bug me first).

_ if you re-read my email, it says conspirators "should" check/compile
  before checking in. I understand it does not always happen. But I have to make
  sure that there is a good library and we are linked to that only (online,
  but also for people that just want to do work w/o having to wonder about who
  is doing what)

so it's not too complicated. I was going to suggest that I write protect what
should be always working (including the link to libblast), which clearly is not
everything in commis/phase2. We will always be free to copy a version of existing
code (it will then have blast permissions) and load (explicitly) any library you wish.

We all agreed to this once and we have meetings just for this.
Happy turkey!

-- t
________________________________________________________________________________
Tancredi Botto, phone: +1-617-253-9204 mobile: +1-978-490-4124
research scientist MIT/Bates, 21 Manning Av Middleton MA, 01949
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

On Tue, 26 Nov 2002, Chi Zhang wrote:

>
> Hi:
>
> first of all, I think we had a resolution: we tagged all the libraries in lib/spud right? change logs are automatically available from CVS, just use:
>
> cvs log -rv2_5 TBLDetRecon.cc
>
> the log message and a brief version history will be printed. Maybe we should tag the scripts too. so v2_5 in ~/commic/phase2 will work with ~lib/spud/libBlast.so.2.5.
>
> Since I am the "conspirator" of the most of the changes in BlastLib2, I can handle the tag stuff.
>
> To answer some of your policies:
>
> >> b) Nobody can modify current macros. PERIOD. But you can negotiate w/ me
> (basically, I'll let you do the work but I'll make sure you test it...)
>
> This being the policy, we will not have adaptable macros. v2_5 was motivated by the comment in ntuple.C complaining the loops for testing coincedence in NC's are boring. In v2_5, DetRecon reads the NC hits, parses them and you get clean things out. I do not understand why adc>pedestal should be a problem as the pedestal is 0 anyway. (maybe I made a mistake, as a lot of cut and paste were involved). I believe I ran ntuple.C with c2_5, and see neutron counter cuts in eep.
>
> I do not want to be a trouble maker, and I understand it is a fundamental pain to debug codes written by someone else. I will stop changing the macros unless changes are really called for.
>
> >>a) Anybody can modify, add NEW classes to the library
>
> >> c) Nobody should check in new library versions if they are not tested
> Unfortunately it happens but is now a lesser problem
>
> I am the only one checking in new libraries, adding big blocks of codes frequently. Because, my part is not done.
>
> Chamber fitting and Newton fitting had been in good shape long before commissioning started. They are fully tested with monte carlo data, and the basic interfaces are stablized.
>
> However, outer detector/particle ID did not received a lot attention before Augest and major construction did not start till Sept.. The interface are not yet stablized, since new requirements show up from day to day. However, people need some of the functionalities already.
>
> I definitely do not want to stop the construction since I, as a student, wish that a more complete software package could by us a little time in analysis, and I wish to present a usable PID, and a complete TBLEvent class so the reconstruction loop can be closed and we can start putting up physics analysis at least from some MonteCarlo. It seems now highly impossible though.
>
> if I made changes, do not check in, some one updated his blastlib, make more changes, check in, compile on spud, link to spud libBlast.so. it has the same result. If I make changes, I do not check in, everyone will have to mannually resolve conflicts in the future.
>
> So if anybody can modify the lib, then it s hard to prevent anyone from checking in new libraries. if the first one changed the code did not compile the lib, some one will eventually, and I think it is better that the problems menifest themselves right away instead of looking for a needle in a haystack two weeks later.
>
>
>
>
>
>
>
> ---------------------------------
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now



This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:28 EST