Re: [rt-users] XLS export balks

2015-09-11 Thread Marc Chantreux
> you would better use a branch for upstream and one for your (or many if
> you have prod/staging/...).

i really would like but i don't know how to run RT from the sources
(it seems you need to install it somewhere and run it from this place).

> It's easier when you need to upgrade RT or compare your patches with
> upstream...

i patch the installed versions and maintain my own repos :( this is sad
and i would be really happy to change it.  

regards 

-- 
Marc Chantreux,
Mes coordonnées: http://annuaire.unistra.fr/chercher?n=chantreux
Direction Informatique, Université de Strasbourg (http://unistra.fr) 
"Don't believe everything you read on the Internet"
-- Abraham Lincoln


Re: [rt-users] XLS export balks

2015-09-11 Thread Emmanuel Lacour
Le 11/09/2015 15:45, Marc Chantreux a écrit :
>> you would better use a branch for upstream and one for your (or many if
>> you have prod/staging/...).
> 
> i really would like but i don't know how to run RT from the sources
> (it seems you need to install it somewhere and run it from this place).
> 
>> It's easier when you need to upgrade RT or compare your patches with
>> upstream...
> 
> i patch the installed versions and maintain my own repos :( this is sad
> and i would be really happy to change it.  
> 
> 


I ended up storing a configured version in my upstream branch for the
same problem.

So here is the process used here:

- I do a clean ./configure ... and make install of RT (no edition of
config files)
- I put this in git in a branch upstrean/4.2 and tag the release
- I checkout this in a branch "prod"
- I make my custom configuration/patches in prod
- when I need to install an extension, I first install it in upstream
branch and merge it in prod (thus I can patch it in prod if needed)


a new RT release comes:

- I run the same ./configure...make install as previously done
- I put the result in upstream branch and commit this as upgrade to RT 4.2.x
- I merge upstream in prod


you can do it with pure sources, but you won't be able to "easily"
deploy it on servers.



And FYI our developpement rules:

For html files
- uses callback and put them in local directory
- no callback, add the missing one in share/html (patch) (submit it to
upstream if it may be of any interest for anyone else) and add the
callback file in local directory
- need a new mason component: put it in local/html directory
- need to really patch an existing one: do it in place in share/html
(*never copy the file to local dir*, upgrades will be a pain!)


For lib files
- put new methods in local/lib/RT/xxx_Local.pm
- put new objects in local/lib/RT/...
- need to patch an existing method: try to do so by creating a
local/lib/RT/xxx_Local.pm with:

my $old_method = \

*Method = sub {
my $self = shift;
my %args = ( @_ );

  

$old_method->($self, @_);
  


- if you really need to patch the method, do it inplace in lib/RT/...,
*never copy a lib file/method to local dir* or upgrades will be a pain!



et voilà ;)


tip: I just discovered git "submodules" feature that may be used for RT
extensions ... maybe

-- 
Easter-eggs  Spécialiste GNU/Linux
44-46 rue de l'Ouest  -  75014 Paris  -  France -  Métro Gaité
Phone: +33 (0) 1 43 35 00 37-   Fax: +33 (0) 1 43 35 00 76
mailto:elac...@easter-eggs.com  -   http://www.easter-eggs.com