[TYPO3-dam-devel] Q-2-All-Devs - Testing patches Procedure (without shell-usage)

[Peter Kuehn [wmdb]]

Hi georg, hi yall,

 > Basically think of the TYPO3-Testsite from Kasper (ages ago), however
 > including all DAM related stuff.
I LOVE this idea! one thing im realy concerned about, is testing against 
large enough data stocks (i know you do as well).
so: how could such a testsite contain enough data and still be shipable? 
creating XX.000 clear.gif´s with random names?

 > I can highly recommend the usage of np_subversion
just gave it a try and like it. shouldnt DAM support it, if its 
installed? (didnt love i had to re-enable the old fileadmin to use it... ;))
im not sure, if i know bastian waidelich personaly but i hope we´ll see 
some of the network-publishing folks in laax. maybe we can huddle 
together there and make some plans.

gRTz
pekue

georg kuehnberger schrieb:
> Sorry only, half sent before, so here's the complete version:
> 
> Ahoi all,
> 
> As we all know, testing patches (as provided via the bugtracker) takes 
> quite some effort/time;
> Basic requirements like understanding the Issue and being able to 
> reproduce the issue/error and writing up some meaningful feedback so the 
> developers might act upon, can hardly be improoved, other than by eduction.
> 
> However I feel, two other requirements could easily improoved for tha 
> sake of all.
> 
> a) Do have a meaningful (=recent) TYPO3+DAM Setup, do have the most 
> important DAM-FE-Extensions installed, do have "enough" data and 
> configuration (pages, dam records & categories, be_groups & _users, 
> languages, filemounts, webmounts, workspaces & all the right 
> permission-settings - according to the documentation).
> Basically think of the TYPO3-Testsite from Kasper (ages ago), however 
> including all DAM related stuff.
> I guess this one could best be solved by providing a tarball (or 
> vmware-image or any other format you prefer);
> I feel capable of creating such an instance and even mantaining it, so 
> just let me know your thoughts on content & delivery-format.
> 
> 
> b) Easing the Testing of Patches
> Here is my (our) current procedure on Testing patches:
> - having a shell open on the specific testing-host
> - being in the right directory (extension dependent)
> - downloading the patch to the right location
> - applying the patch and verifying it applied fine
> - then re-testing the behaviour, eventually checking debug-logs AND
> - given the patch kinda is "bad" undoing the patch
> This procedure IS hard, and swiching OSes, shells, path & download 
> tools, in order to test on more than one OS, simply multiplies the effort.
> 
> Question-A is: Do you have scripts/methods/tools that could ease those 
> tasks?
> 
> Question-B is: Could you imaging and would you verify the meaningfulness 
>  (in terms of easing the process of testing patches) of a TYPO3 
> Backend-Extension where you would eg. (just some thoughts):
> - enter the extension-key
> - enter the Download-URL of the patch (eg. from bugs.typo3.org)
> The Extension would then:
> - apply the patch & take care of a backups
> - offern an Interface to un-do the patch;
> 
> I guess that we, thats me masi & wolfgang klinger [both core-devs}, cant 
> be the only ones in the need of such a streamlined process of testing 
> patches.
> 
> Thanks for your feedback upfront,
> regards georg
> PS: Aside the above (and as a prerequisite) I can highly recommend the 
> usage of np_subversion, as it allows (1 or) 2-click updates from the SVN.