Hi Konstantin et al, On Thu, 18 Oct 2001 10:18:43 -0700 Konstantin Olchanski <olchansk@sam.triumf.ca> wrote concerning "Re: Old stuff in /afs/rhic/opt/brahms (Was Re: compiling brat/brop/brag in RH7.1 pii computers)": > On Thu, Oct 18, 2001 at 12:23:49PM +0200, Christian Holm Christensen wrote: > > > > Frankly, I'm concerned that people will start using non-standard, > > non-supported installations or various third-party software like ROOT, > > which you can easily imagine will lead to loads of odd problems. > > You do not want to open this can of worms. Too late! And, it's not the first time it's been opened by the way, and not always by me! > Who decides on what is standard and what is not? Well, since Kris, Flemming and I are basically the ones that maintains the installations, it's us, in concensous. Of course this is not the dictatorial-trio - we do try to make things as easy to use as possible, and we'll gladly listen to complaints, etc.. That said, users need to provide compeling arguments (or serious enough trouble) for us to change practise, since we've actually given it quite a lot of thought, and most of us do have past experience in setting up software. > How do you keep the standard up to date? Currently by hand. What I'd really like to happen is that we did nightly (or weekly) builds of BRAT/BROP/BREG/BRAG/CRASH/... in the "new" tree. Since I have little experience in writting CRON files, and also there's the issue of reading AFS passwords from a file which hasn't been resolved (that is, it's possible, but do want it?). Could you help out with this? Thanks. > How do you keep the standard from changing daily? Lazyness :-) No seriously; the "pro" and "old" trees only changes when a new minor version of BRAT/BROP/BREG/BRAG/CRASH/... is introduced, which does not happen that often (on average at .5 month^-1), while "new" tree in principel should change with each revision update - now, that's not feasible so it basically changes when someone (usually Ian :-) requests a new BRAT for use on the Farm, which depends a lot on the amount of development going on. And also, updates and upgrades are _always_ accompanied with a mail to brahms-soft-l so people will no exactly what's going on. > And, I do not think you can wiggle out of helping Kris (and others) with > their problems by defining their installation as "non-standard". I'm afraid you read my mail rather quickly. In fact, I pointed numerous solutions, and also that there in fact isn't really the problem that Kris anticipated. As to "defining their installation ...". I certainly did not mean to imply (and I don't think I did, but if I did - I'm sorry) that installations outside of /afs/rhic/opt/brahms are bad. It's just that the installations in /afs/rhic/opt/brahms are the ones that we use for reconstruction on CRS, and I believe also what is more or less used by people @ BNL (and other places in the US) not doing development. There's a good reason for calling that "standard" (hmm, maybe 'canonical' or something would have been better), since the version numbers are always well-known. Nothing gets installed in /afs/rhic/opt/brahms that doesn't carry a proper unique version number. Hence, it's easy to help people out if they use those installations, since you always know which version they refer to. The reason I object to having another ROOT installation, other then the 'standard' one, lying around on a shared disk, is that it may give people the impression that it's actually the 'standard' one (i.e., supported, and the one that BRAT/BROP/CRASH/... is compiled with). Thus, to minimize confusion, help us do support, and so on, I'd much prefer that users that want a 'special' ROOT installation keep such a one in thier ${HOME} directory. If the @sys thing of AFS is something one want's to exploit, we have AFS 'home' directories in /afs/rhic/brahms/user/<login name>. For example on my CERN account, which resides on AFS, I have a directory structure like ~/ |--.alpha_dux40 -> .alpha_osf20 |--.alpha_osf20 | `-- bin |--.alpha_osf32 -> .alpha_osf20 |--.alpha_osf32c -> .alpha_osf20 |--.hp700_ux100 -> .hp700_ux90 |--.hp700_ux101 -> .hp700_ux90 |--.hp700_ux90 | |-- bin | `-- lib |--.hp_ux102 -> .hp700_ux90 |--.i386_linux22 | |-- bin | `-- lib |--.i386_linux24 | |-- bin | `-- lib |--.i386_redhat51 -> .i386_linux22 |--.i386_redhat62 -> .i386_linux22 |--.i386_redhat71 -> .i386_linux24 |--.i386_nt40 | `-- bin |--.rs_aix32 | `-- bin |--.rs_aix41 -> .rs_aix32 |--.rs_aix42 -> .rs_aix32 |--.sgi_52 | `-- bin |--.sgi_64 -> .sgi_52 |--.sgi_65 -> .sgi_52 |--.sun4m_53 | `-- bin |--.sun4x_55 -> .sun4m_53 |--.sun4x_56 -> .sun4m_53 |--.sun4x_57 -> .sun4m_53 |-- bin -> .@sys/bin `-- lib -> .@sys/lib Now that's neat, since it means I needn't care about which architecture I'm using. I just build and install everything with prefix=${HOME} and the binaries are put in an architecture specific directory - much like when we update ROOT and BRAT, we just set prexix=/afs/rhic/opt/brahms/[old|pro|new]. So you see, I'm not wiggling out of anything. I'm just saying: "Help us help you, by using the 'standard' installations". That's really the essence. > > ... Well, it turns > > out, that the fella used something non-standard and therefore you do > > not find the problem immediately (spending even more time). > > But it is *your* fault, as a provider of the environment. The reason > the user is using something non-standard is always because the > "standard way" is not working for him. Well, then the user should request a change or help to do what she/he needs to do, which is exactly what I did. > You can't blame the user when something *you* provide does not work. I think if you go back and read my mail one more time, you'll see that I pointed out, that it does in fact work - not only in principle, but also proven by experience. > > 7. Release early. Release often. And listen to your customers. > > So do so. Fix your stuff so people do not have to use non-standard > things. You're contradicting yourself here. Well, never mind that. The important point is, that the last part of the maxim stated above, has been followed. Also, I don't care that people use thier own ROOT installations (though I think it's a waste of time and space unless they hack on ROOT) if they really want it (and realise that help is harder to get), but they should do so in the confienes of thier own ${HOME}, not flaunt thier tendencies in general public, thereby sending mixed signals. Do please read my previous email again. I think you've misunderstood a couple of things, since I truely find your critism at best, far from being to the point, and at worst nothing but a flame. Yours, Christian Holm Christensen ------------------------------------------- Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 DK-2200 Copenhagen N Cell: (+45) 28 82 16 23 Denmark Office: (+45) 353 25 305 Email: cholm@nbi.dk Web: www.nbi.dk/~cholm
This archive was generated by hypermail 2b30 : Fri Oct 19 2001 - 15:03:36 EDT