From Julian.Tenney at nottingham.ac.uk Thu Sep 5 12:17:57 2013 From: Julian.Tenney at nottingham.ac.uk (Julian Tenney) Date: Thu, 5 Sep 2013 12:17:57 +0100 Subject: [Xerte-dev] Seeing Stars Message-ID: <12C67A1EEC419342AF5E59DA31562C3F0C80D19296@EXCHANGE1.ad.nottingham.ac.uk> Hi, I thought I'd share a couple of pictures I took of the stars whilst on holiday. We were staying in the south of France, about 35km SW of Carcassonne, and the sky was very dark at night in the second week after the moon had disappeared from the night sky. The images were made by taking a series of about 20 photographs (Nikon 7000D, 18mm lens, 20 seconds, F3.5, ISO 6400) and then running the entire set through a piece of software called Deep Sky Stacker. What this does is uses the information in each image to identify, and remove, the noise, resulting in a very clear image, which it spits out as a 32bit TIF, about 250MB. Then a little Photoshop to increase the contrast a little and stretch the histogram, and that's pretty much it. If anyone is nifty with Photoshop and wants to have a crack at some post-processing on the TIFs let me know and I'll put them somewhere you can get them (I don't have them with me today), be interesting to see what others can do with them! These are from the same TIFF, the top one has a bit more Photoshop going on, I have another TIFF where the stars are sharper, because a) I focused the camera properly (!) and b) I took more images, and used dark frames as well as light frames in the stacker. [cid:image001.jpg at 01CEAA30.F9B11FD0] [cid:image002.jpg at 01CEAA30.F9B11FD0] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 100660 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 73207 bytes Desc: image002.jpg URL: From Julian.Tenney at nottingham.ac.uk Thu Sep 5 14:39:52 2013 From: Julian.Tenney at nottingham.ac.uk (Julian Tenney) Date: Thu, 5 Sep 2013 14:39:52 +0100 Subject: [Xerte-dev] GitHub and Workflows Message-ID: <12C67A1EEC419342AF5E59DA31562C3F0C80D193A9@EXCHANGE1.ad.nottingham.ac.uk> Hi, I think we've got the SVN migrated over to Git Hub with all the history, branches etc, which is great. We need to have some discussion about workflow, and I want to suggest gitflow as a good workflow to adopt. Information can be found here http://nvie.com/posts/a-successful-git-branching-model/ and elsewhere (here: https://www.atlassian.com/git/workflows for example). I like it for several reasons: - The 'master' branch is always production quality released code - Small developments (trivial) can be undertaken directly in 'develop' - Larger developments can be undertaken in braches taken from 'develop', and then merged back into develop once complete... - ...testing of develop can then be undertaken before we make a new release number. See the information for more details. Does this seem sensible and agreeable to everyone? There are two other things I'd like us to work towards, again subject to some discussion between us: Using Tickets for Issues and New Features: - Using some ticketing system to record bugs to be fixed, new features to be developed, because we keep losing these; - Using those tickets as a way of grouping work into sprints towards a new release; - Could be trac, could be github, open to suggestions; A better means of testing the software rather than the hit and hope method we currently employ: - Open to suggestions here? - Probably starts with a list of manual tests to work through? - Possibly includes automation (Selenium?) - UnitTesting probably a very long term goal, might not even be possible? So my vision would be that we log tickets, we use that list of tickets as a big to-do list; we create a smaller current to-do list from it for the next release; we do the development a la gitflow; changes get pushed to develop and tested; new version released. It sounds good in theory at any rate, it will require a bit more discipline amongst us, but I think the benefits are worth it. I'd very much appreciate your views... Thanks, Julian -------------- next part -------------- An HTML attachment was scrubbed... URL: From J.J.Smith at gcu.ac.uk Thu Sep 5 14:55:31 2013 From: J.J.Smith at gcu.ac.uk (Smith, John) Date: Thu, 5 Sep 2013 14:55:31 +0100 Subject: [Xerte-dev] Re: GitHub and Workflows In-Reply-To: <12C67A1EEC419342AF5E59DA31562C3F0C80D193A9@EXCHANGE1.ad.nottingham.ac.uk> References: <12C67A1EEC419342AF5E59DA31562C3F0C80D193A9@EXCHANGE1.ad.nottingham.ac.uk> Message-ID: Sounds all good to me... Regards, John Smith Learning Technologist School of Health & Life Sciences Glasgow Caledonian University From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Julian Tenney Sent: Thursday, September 05, 2013 2:40 PM To: For Xerte technical developers (xerte-dev at lists.nottingham.ac.uk) Subject: [Xerte-dev] GitHub and Workflows Hi, I think we've got the SVN migrated over to Git Hub with all the history, branches etc, which is great. We need to have some discussion about workflow, and I want to suggest gitflow as a good workflow to adopt. Information can be found here http://nvie.com/posts/a-successful-git-branching-model/ and elsewhere (here: https://www.atlassian.com/git/workflows for example). I like it for several reasons: - The 'master' branch is always production quality released code - Small developments (trivial) can be undertaken directly in 'develop' - Larger developments can be undertaken in braches taken from 'develop', and then merged back into develop once complete... - ...testing of develop can then be undertaken before we make a new release number. See the information for more details. Does this seem sensible and agreeable to everyone? There are two other things I'd like us to work towards, again subject to some discussion between us: Using Tickets for Issues and New Features: - Using some ticketing system to record bugs to be fixed, new features to be developed, because we keep losing these; - Using those tickets as a way of grouping work into sprints towards a new release; - Could be trac, could be github, open to suggestions; A better means of testing the software rather than the hit and hope method we currently employ: - Open to suggestions here? - Probably starts with a list of manual tests to work through? - Possibly includes automation (Selenium?) - UnitTesting probably a very long term goal, might not even be possible? So my vision would be that we log tickets, we use that list of tickets as a big to-do list; we create a smaller current to-do list from it for the next release; we do the development a la gitflow; changes get pushed to develop and tested; new version released. It sounds good in theory at any rate, it will require a bit more discipline amongst us, but I think the benefits are worth it. I'd very much appreciate your views... Thanks, Julian This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. Glasgow Caledonian University is a registered Scottish charity, number SC021474 Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en.html Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,15691,en.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From mberthelemy at wyversolutions.co.uk Thu Sep 5 15:33:11 2013 From: mberthelemy at wyversolutions.co.uk (Mark Berthelemy) Date: Thu, 5 Sep 2013 15:33:11 +0100 Subject: [Xerte-dev] Re: GitHub and Workflows In-Reply-To: <12C67A1EEC419342AF5E59DA31562C3F0C80D193A9@EXCHANGE1.ad.nottingham.ac.uk> References: <12C67A1EEC419342AF5E59DA31562C3F0C80D193A9@EXCHANGE1.ad.nottingham.ac.uk> Message-ID: Hi Julian, Re. Testing I can recommend TestLink for managing the process. It integrates with some ticket systems and with Selenium too I believe. Mark On Sep 5, 2013 2:40 PM, "Julian Tenney" wrote: > Hi,**** > > ** ** > > I think we?ve got the SVN migrated over to Git Hub with all the history, > branches etc, which is great. We need to have some discussion about > workflow, and I want to suggest gitflow as a good workflow to adopt. > Information can be found here > http://nvie.com/posts/a-successful-git-branching-model/ and elsewhere > (here: https://www.atlassian.com/git/workflows for example).**** > > ** ** > > I like it for several reasons:**** > > ** ** > > **- **The ?master? branch is always production quality released > code**** > > **- **Small developments (trivial) can be undertaken directly in > ?develop?**** > > **- **Larger developments can be undertaken in braches taken > from ?develop?, and then merged back into develop once complete?**** > > **- **?testing of develop can then be undertaken before we make > a new release number.**** > > ** ** > > See the information for more details. Does this seem sensible and > agreeable to everyone?**** > > ** ** > > There are two other things I?d like us to work towards, again subject to > some discussion between us:**** > > ** ** > > Using Tickets for Issues and New Features:**** > > **- **Using some ticketing system to record bugs to be fixed, > new features to be developed, because we keep losing these;**** > > **- **Using those tickets as a way of grouping work into sprints > towards a new release;**** > > **- **Could be trac, could be github, open to suggestions;**** > > ** ** > > A better means of testing the software rather than the hit and hope method > we currently employ:**** > > **- **Open to suggestions here?**** > > **- **Probably starts with a list of manual tests to work > through?**** > > **- **Possibly includes automation (Selenium?)**** > > **- **UnitTesting probably a very long term goal, might not even > be possible?**** > > ** ** > > So my vision would be that we log tickets, we use that list of tickets as > a big to-do list; we create a smaller current to-do list from it for the > next release; we do the development a la gitflow; changes get pushed to > develop and tested; new version released. It sounds good in theory at any > rate, it will require a bit more discipline amongst us, but I think the > benefits are worth it. I?d very much appreciate your views?**** > > ** ** > > Thanks,**** > > ** ** > > Julian**** > > ** ** > > ** ** > > ** ** > > This message and any attachment are intended solely for the addressee and > may contain confidential information. If you have received this message in > error, please send it back to me, and immediately delete it. Please do > not use, copy or disclose the information contained in this message or in > any attachment. Any views or opinions expressed by the author of this > email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Julian.Tenney at nottingham.ac.uk Thu Sep 5 15:34:01 2013 From: Julian.Tenney at nottingham.ac.uk (Julian Tenney) Date: Thu, 5 Sep 2013 15:34:01 +0100 Subject: [Xerte-dev] Re: GitHub and Workflows In-Reply-To: References: <12C67A1EEC419342AF5E59DA31562C3F0C80D193A9@EXCHANGE1.ad.nottingham.ac.uk> Message-ID: <12C67A1EEC419342AF5E59DA31562C3F0C80D19434@EXCHANGE1.ad.nottingham.ac.uk> Cheers, From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Mark Berthelemy Sent: 05 September 2013 15:33 To: For Xerte technical developers Subject: [Xerte-dev] Re: GitHub and Workflows Hi Julian, Re. Testing I can recommend TestLink for managing the process. It integrates with some ticket systems and with Selenium too I believe. Mark On Sep 5, 2013 2:40 PM, "Julian Tenney" > wrote: Hi, I think we've got the SVN migrated over to Git Hub with all the history, branches etc, which is great. We need to have some discussion about workflow, and I want to suggest gitflow as a good workflow to adopt. Information can be found here http://nvie.com/posts/a-successful-git-branching-model/ and elsewhere (here: https://www.atlassian.com/git/workflows for example). I like it for several reasons: - The 'master' branch is always production quality released code - Small developments (trivial) can be undertaken directly in 'develop' - Larger developments can be undertaken in braches taken from 'develop', and then merged back into develop once complete... - ...testing of develop can then be undertaken before we make a new release number. See the information for more details. Does this seem sensible and agreeable to everyone? There are two other things I'd like us to work towards, again subject to some discussion between us: Using Tickets for Issues and New Features: - Using some ticketing system to record bugs to be fixed, new features to be developed, because we keep losing these; - Using those tickets as a way of grouping work into sprints towards a new release; - Could be trac, could be github, open to suggestions; A better means of testing the software rather than the hit and hope method we currently employ: - Open to suggestions here? - Probably starts with a list of manual tests to work through? - Possibly includes automation (Selenium?) - UnitTesting probably a very long term goal, might not even be possible? So my vision would be that we log tickets, we use that list of tickets as a big to-do list; we create a smaller current to-do list from it for the next release; we do the development a la gitflow; changes get pushed to develop and tested; new version released. It sounds good in theory at any rate, it will require a bit more discipline amongst us, but I think the benefits are worth it. I'd very much appreciate your views... Thanks, Julian This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronm at mitchellmedia.co.uk Fri Sep 6 09:43:57 2013 From: ronm at mitchellmedia.co.uk (Ron Mitchell) Date: Fri, 6 Sep 2013 09:43:57 +0100 Subject: [Xerte-dev] Re: Seeing Stars In-Reply-To: <12C67A1EEC419342AF5E59DA31562C3F0C80D19296@EXCHANGE1.ad.nottingham.ac.uk> References: <12C67A1EEC419342AF5E59DA31562C3F0C80D19296@EXCHANGE1.ad.nottingham.ac.uk> Message-ID: <010801ceaadd$3b514800$b1f3d800$@co.uk> Nice pics and thanks for the tip about Deep Sky Stacker. No substitute for being there at the time though eh! Dropbox is obviously quite good for sharing pics e.g. a few of mine from Luosto earlier this year https://www.dropbox.com/sh/miplecp5ksyuxpr/3Lx___8EQg what they don't show is the dancing that happened at the time - people as well as the stars! ;-) Ron From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Julian Tenney Sent: 05 September 2013 12:18 To: For Xerte technical developers (xerte-dev at lists.nottingham.ac.uk) Subject: [Xerte-dev] Seeing Stars Hi, I thought I'd share a couple of pictures I took of the stars whilst on holiday. We were staying in the south of France, about 35km SW of Carcassonne, and the sky was very dark at night in the second week after the moon had disappeared from the night sky. The images were made by taking a series of about 20 photographs (Nikon 7000D, 18mm lens, 20 seconds, F3.5, ISO 6400) and then running the entire set through a piece of software called Deep Sky Stacker. What this does is uses the information in each image to identify, and remove, the noise, resulting in a very clear image, which it spits out as a 32bit TIF, about 250MB. Then a little Photoshop to increase the contrast a little and stretch the histogram, and that's pretty much it. If anyone is nifty with Photoshop and wants to have a crack at some post-processing on the TIFs let me know and I'll put them somewhere you can get them (I don't have them with me today), be interesting to see what others can do with them! These are from the same TIFF, the top one has a bit more Photoshop going on, I have another TIFF where the stars are sharper, because a) I focused the camera properly (!) and b) I took more images, and used dark frames as well as light frames in the stacker. cid:part1.02090906.06020203 at tor.nl cid:part2.04030404.02030400 at tor.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 100660 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 73207 bytes Desc: not available URL: From ronm at mitchellmedia.co.uk Fri Sep 6 13:36:07 2013 From: ronm at mitchellmedia.co.uk (Ron Mitchell) Date: Fri, 6 Sep 2013 13:36:07 +0100 Subject: [Xerte-dev] Re: problem with trunk and added slashes? In-Reply-To: <015f01cea584$eb14ad30$c13e0790$@co.uk> References: <9ygmpwb9vyjod3784kulb1ul.1377862923609@email.android.com> <013301cea578$ae3090c0$0a91b240$@co.uk> <014601cea582$37721d00$a6565700$@co.uk> <52209AF7.60401@tor.nl> <015f01cea584$eb14ad30$c13e0790$@co.uk> Message-ID: <013e01ceaafd$a9dcf100$fd96d300$@co.uk> Hi all John/Tom have you done any further testing of the change to save.php with the check for magic_quotes moved above the 2 require lines? >From what I've been able to test so far that fixes the issue when a moodle config is included and doesn't seem to introduce any knock on effects as far as I can tell. I'd prefer wider testing but as we think this is unlikely to cause any issues should this change now be published? I know there's a separate thread about git workflow but I don't have time to digest all that right now and without that I'm not sure where I would commit the changed save.php? Cheers Ron From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Ron Mitchell Sent: 30 August 2013 14:29 To: 'For Xerte technical developers' Subject: [Xerte-dev] Re: problem with trunk and added slashes? Hi Tom yeah that all adds to the variation doesn't it. :-( On most of the servers to which I have access and certainly on the Techdis server magic_quotes is off. As I think you said Gayan's fix of turning it on wasn't really the right solution especially as the option doesn't even exist in 5.4+ Cheers Ron From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders Sent: 30 August 2013 14:16 To: For Xerte technical developers Subject: [Xerte-dev] Re: problem with trunk and added slashes? The issue with the magic_quotes is also caused by the fact that it used to be switched on by default, and thereafter deprecated in 5.3 (and I think even in 5.2) and not implemented any more in 5.4. Op 30-8-2013 15:09, Ron Mitchell schreef: Hi John My most recent tests are with a download from xerte.org.uk with unstable (svn r1086). To be honest I've lost track of what change caused what under what circumstances but as it was since Tom's check for magic quotes the Techdis installation I've been using for testing (which uses Moodle for authentication) was adding slashes throughout the xml and effectively breaking whole LO's. So far I've avoided upgrading the other installations on the same server which is just as well. I'll upgrade those other installations after I've found time to test thoroughly but that's unlikely to be for a week or so. Cheers Ron From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Smith, John Sent: 30 August 2013 13:30 To: For Xerte technical developers Subject: [Xerte-dev] Re: problem with trunk and added slashes? Hi Ron, What revision do you have which is definitely working? Is it possible that it only worked with Moodle integration because we were already stripping the slashes always and that no-one had reported issues with a normal Auth version? It seems to me that we need more than just a binary if statement... we have at least 3 different scenarios to take care of... The timeline as I see it (correct me if I'm wrong) appears to be:  Moodle was adding slashes and we were stripping them by default so everything was OK...  We then had a report of Latex/MathJax slashes being removed (on a non-Moodle system), which would happen if we were always removing them...  So Tom added a check for magic quotes and only stripped slashes when they were on which fixed the reported problem but broke Moodle... We can test for Moodle integration however the problem (as Ron has demonstrated) is that if Moodle Integration is ON but the endpoint is wrong then the slashes are NOT ADDED... only when the endpoint points at the correct Moodle file does everything work correctly (and break the slashes!!) I suspect that simply getting the data BEFORE config inclusion is fine - config is mainly there for authentication purposes anyway and we can authenticate the user after getting the data without any ill effects... Definitely worth testing though... Regards, John Smith Learning Technologist School of Health & Life Sciences Glasgow Caledonian University -----Original Message----- From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Ron Mitchell Sent: Friday, August 30, 2013 1:02 PM To: 'For Xerte technical developers' Subject: [Xerte-dev] Re: problem with trunk and added slashes? Hi all I can't say this for sure but my hunch is this is only a conflict with the call to stripslashes or the check for magic quotes. There wasn't a problem previously with Moodle integration and without the re-ordering of that code e.g. the check for magic_quotes and call to stripslashes the problem happens and the problem happens regardless of the authentication method chosen if a valid path to moodle config is set as integration_path. e.g. whatever is set in integration path is included regardless of the authentication method set in auth_config.php. Chaning the order of that code to before the includes certainly seems to resolve the issue but I haven't had time to check for any other consequences. As John says I'm not sure there would be any but it would be good to confirm that 100%. HTH Ron -----Original Message----- From: xerte-dev-bounces at lists.nottingham.ac.uk [ mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Smith, John Sent: 30 August 2013 12:42 To: xerte-dev at lists.nottingham.ac.uk Subject: [Xerte-dev] Re: problem with trunk and added slashes? Hi Pat If moodle integration is on and any page includes config.php and subsequently the moodle config page (for dealing with the cookies) then it seems that moodle potentially plays around with the GET and POST data, especially regarding its own implementation of magic quote behaviour... Regards John Smith Learning Technologist School of Health and Life Sciences Sent from Samsung Galaxy SII "Pat @ Pgogy" < xerte at pgogywebstuff.com> wrote: The original moodle auth was single sign on - where are we using data that's been through moodle? Not really followed this thread, been swamped On 30 Aug 2013, at 12:12, "Smith, John" < J.J.Smith at gcu.ac.uk> wrote: > Thanks Ron, > > I think that confirms that Moodle is somehow messing around with the POST data (although the comment says it should only be the GET data being affected). > > I doubt moving the code before the config includes will break anything else, however it is possible I suppose that we have other code that is working around other things that Moodle changes. Pat/Tom do you know of anything else that was necessary when Moodle integration was created? > > I will move the code section once Github is up and running and then perhaps we can test it with some LOs containing slashes etc to see if it works as expected. > > Regards, > > John Smith | Learning Technologist > Room A251, Govan Mbeki Building | School of Health & Life Sciences | > Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA > ________________________________________ > From: xerte-dev-bounces at lists.nottingham.ac.uk > [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Ron Mitchell > [ronm at mitchellmedia.co.uk] > Sent: 27 August 2013 16:01 > To: 'For Xerte technical developers' > Subject: [Xerte-dev] Re: problem with trunk and added slashes? > > Hi John/Tom > sorry that I haven't had time or opportunity to test this until now but I've just done so as John suggested and at least on the Techdis server changing /modules/xerte/engine/save.php so that it's now as follows: > > $unescaped_data = $_POST['filedata']; > if (function_exists('get_magic_quotes_gpc') && get_magic_quotes_gpc()) > { > $unescaped_data = stripslashes($_POST['filedata']); } > > require_once("../../../config.php"); > require_once("../../../plugins.php"); > > means that it works ok with Moodle authentication and a Moodle integration path included which it hasn't done since the addition of that previous change. Has this cropped up much elsewhere on the forums? I'm surprised it hasn't! > > I have no idea if that change of order would affect anything else? > > Cheers > Ron > > > -----Original Message----- > From: xerte-dev-bounces at lists.nottingham.ac.uk > [ mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Ron > Mitchell > Sent: 26 August 2013 13:50 > To: For Xerte technical developers > Subject: [Xerte-dev] Re: problem with trunk and added slashes? > > Hi John > Sorry out for the day until late evening so unlikely to be able to test further until tomorrow. > Cheers > Ron > > Sent from my iPhone > > On 26 Aug 2013, at 06:42, "Smith, John" < J.J.Smith at gcu.ac.uk> wrote: > >> Thanks Ron, >> >> That is a big help, at least now we know where to look... and I think I've found the problem... >> >> Tom, I have found this function in \lib\typo3\class.t3lib_div.php in >> moodle code (note the comment about get_magic_quotes_gpc()) >> >> function GPvar($var,$strip=0) { >> if(empty($var)) return; >> $value = isset($_POST[$var]) ? $_POST[$var] : $_GET[$var]; >> if (isset($value) && is_string($value)) { $value = stripslashes($value); } // Originally check '&& get_magic_quotes_gpc() ' but the values of $_GET are always slashed regardless of get_magic_quotes_gpc() because HTTP_POST/GET_VARS are run through addSlashesOnArray in the very beginning of index_ts.php eg. >> if ($strip && isset($value) && is_array($value)) { t3lib_div::stripSlashesOnArray($value); } >> return $value; >> } >> >> So if Moodle ALWAYS adds slashes, is it a simple method of also checking whether moodle integration is set? But even if it is, unless it is set to the correct path, it will possibly have stripslashes used incorrectly. The recent change relies on the use of get_magic_quotes_gpc() as a condition to strip the slashes but Moodle ignores this very setting and adds them anyway. >> >> My thoughts are, can we just move this code (and access to any other $_GET/$_POST data) to the VERY TOP of save.php, BEFORE the inclusion of config, so before Moodle has a chance to play with the data? >> >> >> $unescaped_data = $_POST['filedata']; if >> (function_exists(get_magic_quotes_gpc) && get_magic_quotes_gpc()) { >> $unescaped_data = stripslashes($_POST['filedata']); } >> >> Can anyone give that a try with their test setups? I'm not setup to test just now and will be busy at least until the afternoon but can test then if no-one else can... Only possible issue I see is - if moodle adds them anyway and they are then also being added by the server could they be there twice in situations where get_magic_quotes_gpc() is on?? >> >> Regards, >> >> John Smith | Learning Technologist >> Room A251, Govan Mbeki Building | School of Health & Life Sciences | >> Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA >> ________________________________________ >> From: xerte-dev-bounces at lists.nottingham.ac.uk >> [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Ron Mitchell >> [ronm at mitchellmedia.co.uk] >> Sent: 26 August 2013 00:29 >> To: 'For Xerte technical developers' >> Subject: [Xerte-dev] Re: problem with trunk and added slashes? >> >> Hi John >> shutting down now but quickly tested this and with integration path pointing to functions.php instead of a moodle file all is fine. It must be a conflict with Moodle code but it obviously wasn't a problem previously and on the server I'm testing with Moodle code hasn't changed only xot code. >> Cheers >> Ron >> >> -----Original Message----- >> From: xerte-dev-bounces at lists.nottingham.ac.uk >> [ mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Smith, >> John >> Sent: 25 August 2013 23:21 >> To: xerte-dev at lists.nottingham.ac.uk >> Subject: [Xerte-dev] Re: problem with trunk and added slashes? >> >> Hi Ron >> >> What would be interesting to know is whether setting a non-moodle integration path causes a problem or whether Moodle changes it... >> >> Can you try setting the integration path to point to /functions.php >> >> This is already included in config with a require once so should have absolutely no effect. >> >> If all is well then the problem is in the moodle file and we need some way of mitigating the effects. If not then there must be some xerte code causing it. >> >> Regards >> >> John Smith >> Learning Technologist >> School of Health and Life Sciences >> >> Sent from Samsung Galaxy SII >> >> >> >> Ron Mitchell < ronm at mitchellmedia.co.uk> wrote: >> >> >> Hi Tom >> yes I thought the same - turning magic_quotes on isn't really the answer and for instance on the Techdis server magic_quotes has always been off and this hasn't been a problem until whatever the code change was when this started. I've actually been testing a bit after Gayan's recent message and with the latest unstable download from xerte.org.uk the following applies: >> >> Same server, same code with guest auth enabled and crucially no moodle itegration path set all is fine. >> >> Same server, same code even with guest auth rather than moodle auth set the problem happens if a moodle integration path is set. >> >> Could there be a duplicate function name or variable name causing this? Or is there a way of checking if an integration path is set and if so skipping the relevant code? >> >> HTH >> Ron >> >> From: xerte-dev-bounces at lists.nottingham.ac.uk >> [ mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom >> Reijnders >> Sent: 25 August 2013 20:37 >> To: For Xerte technical developers >> Subject: [Xerte-dev] Re: problem with trunk and added slashes? >> >> Ron, >> >> Gayan's problem is now solved, but not really the solution I wanted. magic_quotes is obsolete, so I want to find where the slashes came from in the first place. >> >> Tom >> Op 22-8-2013 11:23, Ron Mitchell schreef: >> Hi Tom >> prompted by the latest message on the Xerte list from RGN Meegama (Gayan) attached I did a quick search for our previous discussion about strip slashes below. I haven't had time to investigate this but I wonder if the message from Gayan indicates why this hasn't been a problem for everyone e.g. only materialises when Moodle integration is used and even then perhaps only with a particular stripslashes setting? I've avoided upgrading any installations until I can find time to investigate and test this properly and I still don't have time to investigate now but I wonder if this helps to point you to the cause/solution? I know this is going to raise the old issue about compatibility with 3rd party applications but as I'm sure you also appreciate the fact remains in my experience next to ldap, Moodle is the next most popular solution for xot account management. >> Cheers >> Ron >> >> From: >> xerte-dev-bounces at lists.nottingham.ac.uk> t s.nottingham.ac.uk> >> [ mailto:xerte-dev-bounces at lists.nottingham.ac.uk] >> On Behalf Of Tom Reijnders >> Sent: 20 June 2013 23:04 >> To: For Xerte technical developers >> Subject: [Xerte-dev] Re: problem with trunk and added slashes? >> >> The fact that not all people have control over this was the reason for the fix. The old code called stripslashes regardless of the settings resulting in backslashes being removed from prior escapes and LaTeX expressions. >> >> But given your settings, I don't understand where the slashes as coming from. >> >> Tom >> Ron Mitchell < ronm at mitchellmedia.co.uk> schreef: >> Hi Tom >> sorry for the delayed response been at an event all day and only just on the train home. Magic quotes settins are as follows: >> magic_quotes_gpc Off Off >> magic_quotes_runtime Off Off >> magic_quotes_sybase Off Off >> >> >> But this has been the case previously too when this wasn't a problem. >> I have full control over this server which has 3 separate xot >> installations so I could change the magic quotes settings but lots of >> people obviously won't have control over that e.g. on share d hosting >> etc >> >> >> HTH >> Ron >> >> >> From: >> xerte-dev-bounces at lists.nottingham.ac.uk> t s.nottingham.ac.uk> >> [ mailto:xerte-dev-bounces at lists.nottingham.ac.uk] >> On Behalf Of Tom Reijnders >> Sent: 20 June 2013 07:52 >> To: For Xerte technical developers >> Subject: [Xerte-dev] Re: problem with trunk and added slashes? >> >> >> It has probable caused by r958 (2.0) and r956(trunk). What are your magic_quote settings in php.ini? >> >> Tom >> Op 19-6-2013 18:40, Ron Mitchell schreef: >> Hi all >> I just replied to a message from John where I've already mentioned >> this but thought I should start a new thread too as this may be >> unrelated to the main focus of that other thread. >> >> I updated a test install with the latest code from trunk and notice >> that as soon as I edited and published an LO it was adding extra >> slashes and thefore breaking preview/play. Here's some sample xml >> showing the slashes that got added to both preview.xml and data.xml >> >> >> > Object Title\" navigation=\"Linear\" textSize=\"12\" >> displayMode=\"default\"> >> >> > size=\"30\"><![CDATA[Enter title here]]> >> >> > name=\"Enter Page Title\" align=\"Left\" imagesize=\"full screen\" >> url=\"FileLocation + \'media/800_x_516.jpg\'\" tip=\"Enter a Tooltip\" >> transcriptbuttonlabel=\"Transcript\">> here]]> >> >> > Title\" align=\"Left\" imagesize=\"full screen\" url=\"FileLocation + >> \'media/xpert_logo.gif\'\" tip=\"Enter a Tooltip\" >> transcriptbuttonlabel=\"Transcript\">> here]]> >> >> >> >> I updated an install that was already version 2 but still quite a few revisions applied so not sure what revision is causing this but I reverted the code fixed the xml from my test project and all was fine. Re-applied the code and problem returned. >> >> Any ideas? >> >> HTH >> Cheers >> Ron >> >> >> >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> >> >> >> _______________________________________________ >> >> Xerte-dev mailing list >> >> Xerte-dev at lists.nottingham.ac.uk> uk> >> >> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> >> >> -- >> >> -- >> >> >> >> Tom Reijnders >> >> TOR Informatica >> >> Chopinlaan 27 >> >> 5242HM Rosmalen >> >> Tel: 073 5226191 >> >> Fax: 073 5226196 >> >> >> >> >> >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> >> >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> ________________________________ >> >> >> >> Xerte-dev mailing list >> >> Xerte-dev at lists.nottingham.ac.uk> uk> >> >> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> >> -- >> Verzonden van mijn Android telefoon met K-9 Mail. >> >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> >> >> >> _______________________________________________ >> >> Xerte-dev mailing list >> >> Xerte-dev at lists.nottingham.ac.uk> uk> >> >> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> >> >> >> -- >> >> -- >> >> >> >> Tom Reijnders >> >> TOR Informatica >> >> Chopinlaan 27 >> >> 5242HM Rosmalen >> >> Tel: 073 5226191 >> >> Fax: 073 5226196 >> >> >> >> >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> Glasgow Caledonian University is a registered Scottish charity, >> number >> SC021474 >> >> Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. >> http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name, >> 6 >> 219,en.html >> >> Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. >> http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name, >> 1 5691,en.html _______________________________________________ >> Xerte-dev mailing list >> Xerte-dev at lists.nottingham.ac.uk >> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> >> >> _______________________________________________ >> Xerte-dev mailing list >> Xerte-dev at lists.nottingham.ac.uk >> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> >> Glasgow Caledonian University is a registered Scottish charity, >> number >> SC021474 >> >> Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. >> http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name, >> 6 >> 219,en.html >> >> Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. >> http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name, >> 1 >> 5691,en.html >> >> _______________________________________________ >> Xerte-dev mailing list >> Xerte-dev at lists.nottingham.ac.uk >> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an >> attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > > Glasgow Caledonian University is a registered Scottish charity, number > SC021474 > > Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. > http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6 > 219,en.html > > Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. > http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,1 > 5691,en.html > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > > > _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev Glasgow Caledonian University is a registered Scottish charity, number SC021474 Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en .html Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,15691,e n.html _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev Glasgow Caledonian University is a registered Scottish charity, number SC021474 Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en .html Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,15691,e n.html This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev -- -- Tom Reijnders TOR Informatica Chopinlaan 27 5242HM Rosmalen Tel: 073 5226191 Fax: 073 5226196 This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From reijnders at tor.nl Fri Sep 6 14:14:14 2013 From: reijnders at tor.nl (Tom Reijnders) Date: Fri, 06 Sep 2013 15:14:14 +0200 Subject: [Xerte-dev] Re: GitHub and Workflows In-Reply-To: <12C67A1EEC419342AF5E59DA31562C3F0C80D193A9@EXCHANGE1.ad.nottingham.ac.uk> References: <12C67A1EEC419342AF5E59DA31562C3F0C80D193A9@EXCHANGE1.ad.nottingham.ac.uk> Message-ID: <5229D526.1070208@tor.nl> Hi, I am in the process of modifying the build scripts to use github in stead of svn. And I noticed that Nicodem committed to master yesterday, so I've got a question given the workflow mentioned below: 1. Will we do hotfixes on released branches, i.e. on master and 2.0? 2. What shall we put up on the community website? What is the equivalent to the svn trunk. master or develop, i.e. what is the basis for 'unstable'? Regards, Tom Op 5-9-2013 15:39, Julian Tenney schreef: > > Hi, > > I think we've got the SVN migrated over to Git Hub with all the > history, branches etc, which is great. We need to have some discussion > about workflow, and I want to suggest gitflow as a good workflow to > adopt. Information can be found here > http://nvie.com/posts/a-successful-git-branching-model/ and elsewhere > (here: https://www.atlassian.com/git/workflows for example). > > I like it for several reasons: > > -The 'master' branch is always production quality released code > > -Small developments (trivial) can be undertaken directly in 'develop' > > -Larger developments can be undertaken in braches taken from > 'develop', and then merged back into develop once complete... > > -...testing of develop can then be undertaken before we make a new > release number. > > See the information for more details. Does this seem sensible and > agreeable to everyone? > > There are two other things I'd like us to work towards, again subject > to some discussion between us: > > Using Tickets for Issues and New Features: > > -Using some ticketing system to record bugs to be fixed, new features > to be developed, because we keep losing these; > > -Using those tickets as a way of grouping work into sprints towards a > new release; > > -Could be trac, could be github, open to suggestions; > > A better means of testing the software rather than the hit and hope > method we currently employ: > > -Open to suggestions here? > > -Probably starts with a list of manual tests to work through? > > -Possibly includes automation (Selenium?) > > -UnitTesting probably a very long term goal, might not even be possible? > > So my vision would be that we log tickets, we use that list of tickets > as a big to-do list; we create a smaller current to-do list from it > for the next release; we do the development a la gitflow; changes get > pushed to develop and tested; new version released. It sounds good in > theory at any rate, it will require a bit more discipline amongst us, > but I think the benefits are worth it. I'd very much appreciate your > views... > > Thanks, > > Julian > > > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this > message in error, please send it back to me, and immediately delete > it. Please do not use, copy or disclose the information contained in > this message or in any attachment. Any views or opinions expressed by > the author of this email do not necessarily reflect the views of the > University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > > > > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev -- -- Tom Reijnders TOR Informatica Chopinlaan 27 5242HM Rosmalen Tel: 073 5226191 Fax: 073 5226196 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Julian.Tenney at nottingham.ac.uk Fri Sep 6 14:37:55 2013 From: Julian.Tenney at nottingham.ac.uk (Julian Tenney) Date: Fri, 6 Sep 2013 14:37:55 +0100 Subject: [Xerte-dev] Re: GitHub and Workflows In-Reply-To: <5229D526.1070208@tor.nl> References: <12C67A1EEC419342AF5E59DA31562C3F0C80D193A9@EXCHANGE1.ad.nottingham.ac.uk>, <5229D526.1070208@tor.nl> Message-ID: <12C67A1EEC419342AF5E59DA31562C3F0C80CE5DD3@EXCHANGE1.ad.nottingham.ac.uk> An HTML attachment was scrubbed... URL: From Julian.Tenney at nottingham.ac.uk Fri Sep 6 14:39:30 2013 From: Julian.Tenney at nottingham.ac.uk (Julian Tenney) Date: Fri, 6 Sep 2013 14:39:30 +0100 Subject: [Xerte-dev] Re: problem with trunk and added slashes? In-Reply-To: <013e01ceaafd$a9dcf100$fd96d300$@co.uk> References: <9ygmpwb9vyjod3784kulb1ul.1377862923609@email.android.com> <013301cea578$ae3090c0$0a91b240$@co.uk> <014601cea582$37721d00$a6565700$@co.uk> <52209AF7.60401@tor.nl> <015f01cea584$eb14ad30$c13e0790$@co.uk>, <013e01ceaafd$a9dcf100$fd96d300$@co.uk> Message-ID: <12C67A1EEC419342AF5E59DA31562C3F0C80CE5DD4@EXCHANGE1.ad.nottingham.ac.uk> An HTML attachment was scrubbed... URL: From ronm at mitchellmedia.co.uk Fri Sep 6 17:03:10 2013 From: ronm at mitchellmedia.co.uk (Ron Mitchell) Date: Fri, 6 Sep 2013 17:03:10 +0100 Subject: [Xerte-dev] Re: problem with trunk and added slashes? In-Reply-To: <12C67A1EEC419342AF5E59DA31562C3F0C80CE5DD4@EXCHANGE1.ad.nottingham.ac.uk> References: <9ygmpwb9vyjod3784kulb1ul.1377862923609@email.android.com> <013301cea578$ae3090c0$0a91b240$@co.uk> <014601cea582$37721d00$a6565700$@co.uk> <52209AF7.60401@tor.nl> <015f01cea584$eb14ad30$c13e0790$@co.uk>, <013e01ceaafd$a9dcf100$fd96d300$@co.uk> <12C67A1EEC419342AF5E59DA31562C3F0C80CE5DD4@EXCHANGE1.ad.nottingham.ac.uk> Message-ID: <000001ceab1a$96860cf0$c39226d0$@co.uk> So does hotfixes start as a complete copy of develop or for instance would the hotfix for save.php just contain save,php? From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Julian Tenney Sent: 06 September 2013 14:40 To: For Xerte technical developers Subject: [Xerte-dev] Re: problem with trunk and added slashes? >I know there's a separate thread about git workflow but I don't have time to digest all that right now and without that I'm not sure where I would commit the changed save.php This is where we need ongoing discussion and discipline, because it would be easy to say 'oh, stuff it, it's only small, commit to master' and then the workflow goes up in smoke. http://nvie.com/posts/a-successful-git-branching-model/ suggests a 'hotfixes' branch which is then merged into develop, and then that gets merged into master. _____ From: xerte-dev-bounces at lists.nottingham.ac.uk [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Ron Mitchell [ronm at mitchellmedia.co.uk] Sent: 06 September 2013 13:36 To: 'For Xerte technical developers' Subject: [Xerte-dev] Re: problem with trunk and added slashes? Hi all John/Tom have you done any further testing of the change to save.php with the check for magic_quotes moved above the 2 require lines? >From what I've been able to test so far that fixes the issue when a moodle config is included and doesn't seem to introduce any knock on effects as far as I can tell. I'd prefer wider testing but as we think this is unlikely to cause any issues should this change now be published? I know there's a separate thread about git workflow but I don't have time to digest all that right now and without that I'm not sure where I would commit the changed save.php? Cheers Ron From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Ron Mitchell Sent: 30 August 2013 14:29 To: 'For Xerte technical developers' Subject: [Xerte-dev] Re: problem with trunk and added slashes? Hi Tom yeah that all adds to the variation doesn't it. :-( On most of the servers to which I have access and certainly on the Techdis server magic_quotes is off. As I think you said Gayan's fix of turning it on wasn't really the right solution especially as the option doesn't even exist in 5.4+ Cheers Ron From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders Sent: 30 August 2013 14:16 To: For Xerte technical developers Subject: [Xerte-dev] Re: problem with trunk and added slashes? The issue with the magic_quotes is also caused by the fact that it used to be switched on by default, and thereafter deprecated in 5.3 (and I think even in 5.2) and not implemented any more in 5.4. Op 30-8-2013 15:09, Ron Mitchell schreef: Hi John My most recent tests are with a download from xerte.org.uk with unstable (svn r1086). To be honest I've lost track of what change caused what under what circumstances but as it was since Tom's check for magic quotes the Techdis installation I've been using for testing (which uses Moodle for authentication) was adding slashes throughout the xml and effectively breaking whole LO's. So far I've avoided upgrading the other installations on the same server which is just as well. I'll upgrade those other installations after I've found time to test thoroughly but that's unlikely to be for a week or so. Cheers Ron From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Smith, John Sent: 30 August 2013 13:30 To: For Xerte technical developers Subject: [Xerte-dev] Re: problem with trunk and added slashes? Hi Ron, What revision do you have which is definitely working? Is it possible that it only worked with Moodle integration because we were already stripping the slashes always and that no-one had reported issues with a normal Auth version? It seems to me that we need more than just a binary if statement... we have at least 3 different scenarios to take care of... The timeline as I see it (correct me if I'm wrong) appears to be:  Moodle was adding slashes and we were stripping them by default so everything was OK...  We then had a report of Latex/MathJax slashes being removed (on a non-Moodle system), which would happen if we were always removing them...  So Tom added a check for magic quotes and only stripped slashes when they were on which fixed the reported problem but broke Moodle... We can test for Moodle integration however the problem (as Ron has demonstrated) is that if Moodle Integration is ON but the endpoint is wrong then the slashes are NOT ADDED... only when the endpoint points at the correct Moodle file does everything work correctly (and break the slashes!!) I suspect that simply getting the data BEFORE config inclusion is fine - config is mainly there for authentication purposes anyway and we can authenticate the user after getting the data without any ill effects... Definitely worth testing though... Regards, John Smith Learning Technologist School of Health & Life Sciences Glasgow Caledonian University -----Original Message----- From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Ron Mitchell Sent: Friday, August 30, 2013 1:02 PM To: 'For Xerte technical developers' Subject: [Xerte-dev] Re: problem with trunk and added slashes? Hi all I can't say this for sure but my hunch is this is only a conflict with the call to stripslashes or the check for magic quotes. There wasn't a problem previously with Moodle integration and without the re-ordering of that code e.g. the check for magic_quotes and call to stripslashes the problem happens and the problem happens regardless of the authentication method chosen if a valid path to moodle config is set as integration_path. e.g. whatever is set in integration path is included regardless of the authentication method set in auth_config.php. Chaning the order of that code to before the includes certainly seems to resolve the issue but I haven't had time to check for any other consequences. As John says I'm not sure there would be any but it would be good to confirm that 100%. HTH Ron -----Original Message----- From: xerte-dev-bounces at lists.nottingham.ac.uk [ mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Smith, John Sent: 30 August 2013 12:42 To: xerte-dev at lists.nottingham.ac.uk Subject: [Xerte-dev] Re: problem with trunk and added slashes? Hi Pat If moodle integration is on and any page includes config.php and subsequently the moodle config page (for dealing with the cookies) then it seems that moodle potentially plays around with the GET and POST data, especially regarding its own implementation of magic quote behaviour... Regards John Smith Learning Technologist School of Health and Life Sciences Sent from Samsung Galaxy SII "Pat @ Pgogy" < xerte at pgogywebstuff.com> wrote: The original moodle auth was single sign on - where are we using data that's been through moodle? Not really followed this thread, been swamped On 30 Aug 2013, at 12:12, "Smith, John" < J.J.Smith at gcu.ac.uk> wrote: > Thanks Ron, > > I think that confirms that Moodle is somehow messing around with the POST data (although the comment says it should only be the GET data being affected). > > I doubt moving the code before the config includes will break anything else, however it is possible I suppose that we have other code that is working around other things that Moodle changes. Pat/Tom do you know of anything else that was necessary when Moodle integration was created? > > I will move the code section once Github is up and running and then perhaps we can test it with some LOs containing slashes etc to see if it works as expected. > > Regards, > > John Smith | Learning Technologist > Room A251, Govan Mbeki Building | School of Health & Life Sciences | > Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA > ________________________________________ > From: xerte-dev-bounces at lists.nottingham.ac.uk > [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Ron Mitchell > [ronm at mitchellmedia.co.uk] > Sent: 27 August 2013 16:01 > To: 'For Xerte technical developers' > Subject: [Xerte-dev] Re: problem with trunk and added slashes? > > Hi John/Tom > sorry that I haven't had time or opportunity to test this until now but I've just done so as John suggested and at least on the Techdis server changing /modules/xerte/engine/save.php so that it's now as follows: > > $unescaped_data = $_POST['filedata']; > if (function_exists('get_magic_quotes_gpc') && get_magic_quotes_gpc()) > { > $unescaped_data = stripslashes($_POST['filedata']); } > > require_once("../../../config.php"); > require_once("../../../plugins.php"); > > means that it works ok with Moodle authentication and a Moodle integration path included which it hasn't done since the addition of that previous change. Has this cropped up much elsewhere on the forums? I'm surprised it hasn't! > > I have no idea if that change of order would affect anything else? > > Cheers > Ron > > > -----Original Message----- > From: xerte-dev-bounces at lists.nottingham.ac.uk > [ mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Ron > Mitchell > Sent: 26 August 2013 13:50 > To: For Xerte technical developers > Subject: [Xerte-dev] Re: problem with trunk and added slashes? > > Hi John > Sorry out for the day until late evening so unlikely to be able to test further until tomorrow. > Cheers > Ron > > Sent from my iPhone > > On 26 Aug 2013, at 06:42, "Smith, John" < J.J.Smith at gcu.ac.uk> wrote: > >> Thanks Ron, >> >> That is a big help, at least now we know where to look... and I think I've found the problem... >> >> Tom, I have found this function in \lib\typo3\class.t3lib_div.php in >> moodle code (note the comment about get_magic_quotes_gpc()) >> >> function GPvar($var,$strip=0) { >> if(empty($var)) return; >> $value = isset($_POST[$var]) ? $_POST[$var] : $_GET[$var]; >> if (isset($value) && is_string($value)) { $value = stripslashes($value); } // Originally check '&& get_magic_quotes_gpc() ' but the values of $_GET are always slashed regardless of get_magic_quotes_gpc() because HTTP_POST/GET_VARS are run through addSlashesOnArray in the very beginning of index_ts.php eg. >> if ($strip && isset($value) && is_array($value)) { t3lib_div::stripSlashesOnArray($value); } >> return $value; >> } >> >> So if Moodle ALWAYS adds slashes, is it a simple method of also checking whether moodle integration is set? But even if it is, unless it is set to the correct path, it will possibly have stripslashes used incorrectly. The recent change relies on the use of get_magic_quotes_gpc() as a condition to strip the slashes but Moodle ignores this very setting and adds them anyway. >> >> My thoughts are, can we just move this code (and access to any other $_GET/$_POST data) to the VERY TOP of save.php, BEFORE the inclusion of config, so before Moodle has a chance to play with the data? >> >> >> $unescaped_data = $_POST['filedata']; if >> (function_exists(get_magic_quotes_gpc) && get_magic_quotes_gpc()) { >> $unescaped_data = stripslashes($_POST['filedata']); } >> >> Can anyone give that a try with their test setups? I'm not setup to test just now and will be busy at least until the afternoon but can test then if no-one else can... Only possible issue I see is - if moodle adds them anyway and they are then also being added by the server could they be there twice in situations where get_magic_quotes_gpc() is on?? >> >> Regards, >> >> John Smith | Learning Technologist >> Room A251, Govan Mbeki Building | School of Health & Life Sciences | >> Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA >> ________________________________________ >> From: xerte-dev-bounces at lists.nottingham.ac.uk >> [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Ron Mitchell >> [ronm at mitchellmedia.co.uk] >> Sent: 26 August 2013 00:29 >> To: 'For Xerte technical developers' >> Subject: [Xerte-dev] Re: problem with trunk and added slashes? >> >> Hi John >> shutting down now but quickly tested this and with integration path pointing to functions.php instead of a moodle file all is fine. It must be a conflict with Moodle code but it obviously wasn't a problem previously and on the server I'm testing with Moodle code hasn't changed only xot code. >> Cheers >> Ron >> >> -----Original Message----- >> From: xerte-dev-bounces at lists.nottingham.ac.uk >> [ mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Smith, >> John >> Sent: 25 August 2013 23:21 >> To: xerte-dev at lists.nottingham.ac.uk >> Subject: [Xerte-dev] Re: problem with trunk and added slashes? >> >> Hi Ron >> >> What would be interesting to know is whether setting a non-moodle integration path causes a problem or whether Moodle changes it... >> >> Can you try setting the integration path to point to /functions.php >> >> This is already included in config with a require once so should have absolutely no effect. >> >> If all is well then the problem is in the moodle file and we need some way of mitigating the effects. If not then there must be some xerte code causing it. >> >> Regards >> >> John Smith >> Learning Technologist >> School of Health and Life Sciences >> >> Sent from Samsung Galaxy SII >> >> >> >> Ron Mitchell < ronm at mitchellmedia.co.uk> wrote: >> >> >> Hi Tom >> yes I thought the same - turning magic_quotes on isn't really the answer and for instance on the Techdis server magic_quotes has always been off and this hasn't been a problem until whatever the code change was when this started. I've actually been testing a bit after Gayan's recent message and with the latest unstable download from xerte.org.uk the following applies: >> >> Same server, same code with guest auth enabled and crucially no moodle itegration path set all is fine. >> >> Same server, same code even with guest auth rather than moodle auth set the problem happens if a moodle integration path is set. >> >> Could there be a duplicate function name or variable name causing this? Or is there a way of checking if an integration path is set and if so skipping the relevant code? >> >> HTH >> Ron >> >> From: xerte-dev-bounces at lists.nottingham.ac.uk >> [ mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom >> Reijnders >> Sent: 25 August 2013 20:37 >> To: For Xerte technical developers >> Subject: [Xerte-dev] Re: problem with trunk and added slashes? >> >> Ron, >> >> Gayan's problem is now solved, but not really the solution I wanted. magic_quotes is obsolete, so I want to find where the slashes came from in the first place. >> >> Tom >> Op 22-8-2013 11:23, Ron Mitchell schreef: >> Hi Tom >> prompted by the latest message on the Xerte list from RGN Meegama (Gayan) attached I did a quick search for our previous discussion about strip slashes below. I haven't had time to investigate this but I wonder if the message from Gayan indicates why this hasn't been a problem for everyone e.g. only materialises when Moodle integration is used and even then perhaps only with a particular stripslashes setting? I've avoided upgrading any installations until I can find time to investigate and test this properly and I still don't have time to investigate now but I wonder if this helps to point you to the cause/solution? I know this is going to raise the old issue about compatibility with 3rd party applications but as I'm sure you also appreciate the fact remains in my experience next to ldap, Moodle is the next most popular solution for xot account management. >> Cheers >> Ron >> >> From: >> xerte-dev-bounces at lists.nottingham.ac.uk> t s.nottingham.ac.uk> >> [ mailto:xerte-dev-bounces at lists.nottingham.ac.uk] >> On Behalf Of Tom Reijnders >> Sent: 20 June 2013 23:04 >> To: For Xerte technical developers >> Subject: [Xerte-dev] Re: problem with trunk and added slashes? >> >> The fact that not all people have control over this was the reason for the fix. The old code called stripslashes regardless of the settings resulting in backslashes being removed from prior escapes and LaTeX expressions. >> >> But given your settings, I don't understand where the slashes as coming from. >> >> Tom >> Ron Mitchell < ronm at mitchellmedia.co.uk> schreef: >> Hi Tom >> sorry for the delayed response been at an event all day and only just on the train home. Magic quotes settins are as follows: >> magic_quotes_gpc Off Off >> magic_quotes_runtime Off Off >> magic_quotes_sybase Off Off >> >> >> But this has been the case previously too when this wasn't a problem. >> I have full control over this server which has 3 separate xot >> installations so I could change the magic quotes settings but lots of >> people obviously won't have control over that e.g. on share d hosting >> etc >> >> >> HTH >> Ron >> >> >> From: >> xerte-dev-bounces at lists.nottingham.ac.uk> t s.nottingham.ac.uk> >> [ mailto:xerte-dev-bounces at lists.nottingham.ac.uk] >> On Behalf Of Tom Reijnders >> Sent: 20 June 2013 07:52 >> To: For Xerte technical developers >> Subject: [Xerte-dev] Re: problem with trunk and added slashes? >> >> >> It has probable caused by r958 (2.0) and r956(trunk). What are your magic_quote settings in php.ini? >> >> Tom >> Op 19-6-2013 18:40, Ron Mitchell schreef: >> Hi all >> I just replied to a message from John where I've already mentioned >> this but thought I should start a new thread too as this may be >> unrelated to the main focus of that other thread. >> >> I updated a test install with the latest code from trunk and notice >> that as soon as I edited and published an LO it was adding extra >> slashes and thefore breaking preview/play. Here's some sample xml >> showing the slashes that got added to both preview.xml and data.xml >> >> >> > Object Title\" navigation=\"Linear\" textSize=\"12\" >> displayMode=\"default\"> >> >> > size=\"30\"><![CDATA[Enter title here]]> >> >> > name=\"Enter Page Title\" align=\"Left\" imagesize=\"full screen\" >> url=\"FileLocation + \'media/800_x_516.jpg\'\" tip=\"Enter a Tooltip\" >> transcriptbuttonlabel=\"Transcript\">> here]]> >> >> > Title\" align=\"Left\" imagesize=\"full screen\" url=\"FileLocation + >> \'media/xpert_logo.gif\'\" tip=\"Enter a Tooltip\" >> transcriptbuttonlabel=\"Transcript\">> here]]> >> >> >> >> I updated an install that was already version 2 but still quite a few revisions applied so not sure what revision is causing this but I reverted the code fixed the xml from my test project and all was fine. Re-applied the code and problem returned. >> >> Any ideas? >> >> HTH >> Cheers >> Ron >> >> >> >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> >> >> >> _______________________________________________ >> >> Xerte-dev mailing list >> >> Xerte-dev at lists.nottingham.ac.uk> uk> >> >> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> >> >> -- >> >> -- >> >> >> >> Tom Reijnders >> >> TOR Informatica >> >> Chopinlaan 27 >> >> 5242HM Rosmalen >> >> Tel: 073 5226191 >> >> Fax: 073 5226196 >> >> >> >> >> >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> >> >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> ________________________________ >> >> >> >> Xerte-dev mailing list >> >> Xerte-dev at lists.nottingham.ac.uk> uk> >> >> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> >> -- >> Verzonden van mijn Android telefoon met K-9 Mail. >> >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> >> >> >> _______________________________________________ >> >> Xerte-dev mailing list >> >> Xerte-dev at lists.nottingham.ac.uk> uk> >> >> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> >> >> >> -- >> >> -- >> >> >> >> Tom Reijnders >> >> TOR Informatica >> >> Chopinlaan 27 >> >> 5242HM Rosmalen >> >> Tel: 073 5226191 >> >> Fax: 073 5226196 >> >> >> >> >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> Glasgow Caledonian University is a registered Scottish charity, >> number >> SC021474 >> >> Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. >> http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name, >> 6 >> 219,en.html >> >> Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. >> http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name, >> 1 5691,en.html _______________________________________________ >> Xerte-dev mailing list >> Xerte-dev at lists.nottingham.ac.uk >> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> >> >> _______________________________________________ >> Xerte-dev mailing list >> Xerte-dev at lists.nottingham.ac.uk >> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> >> Glasgow Caledonian University is a registered Scottish charity, >> number >> SC021474 >> >> Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. >> http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name, >> 6 >> 219,en.html >> >> Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. >> http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name, >> 1 >> 5691,en.html >> >> _______________________________________________ >> Xerte-dev mailing list >> Xerte-dev at lists.nottingham.ac.uk >> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an >> attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > > Glasgow Caledonian University is a registered Scottish charity, number > SC021474 > > Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. > http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6 > 219,en.html > > Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. > http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,1 > 5691,en.html > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > > > _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev Glasgow Caledonian University is a registered Scottish charity, number SC021474 Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en .html Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,15691,e n.html _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev Glasgow Caledonian University is a registered Scottish charity, number SC021474 Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en .html Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,15691,e n.html This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev -- -- Tom Reijnders TOR Informatica Chopinlaan 27 5242HM Rosmalen Tel: 073 5226191 Fax: 073 5226196 This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From J.J.Smith at gcu.ac.uk Sat Sep 7 09:02:33 2013 From: J.J.Smith at gcu.ac.uk (Smith, John) Date: Sat, 7 Sep 2013 09:02:33 +0100 Subject: [Xerte-dev] Re: GitHub and Workflows In-Reply-To: <12C67A1EEC419342AF5E59DA31562C3F0C80CE5DD3@EXCHANGE1.ad.nottingham.ac.uk> References: <12C67A1EEC419342AF5E59DA31562C3F0C80D193A9@EXCHANGE1.ad.nottingham.ac.uk>, <5229D526.1070208@tor.nl>, <12C67A1EEC419342AF5E59DA31562C3F0C80CE5DD3@EXCHANGE1.ad.nottingham.ac.uk> Message-ID: Morning all, The way that I see it we should be doing everyday development in the develop branch; I've merged Nikodems changes to Master back into develop (SourceTree wouldn't let me commit to develop while Master was 2 ahead!!). As Julian said in an earlier email, I will either do this directly for a single change or a gitflow branch off of develop for larger changes... Not really sure how the releases and hotfixes should work though... I think the thing we have to take most care with (which we didn't always do on Google) was the copying of files between branches/releases. Develop files will often have 'new features' with code that might be unstable. on Google SVN there were a few situations where bugfix changes were being made to the latest revision and then the latest revision file(s) in question were just copied straight over to the v2 branch, introducing any new features into an old release. This is the thing that worries me most, especially if we are having 'Stable' zips built straight from these branches... not really sure yet though how we mitigate this although you can mark chunks in SourceTree and only push those over... Regards, John Smith | Learning Technologist Room A251, Govan Mbeki Building | School of Health & Life Sciences | Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA ________________________________________ From: xerte-dev-bounces at lists.nottingham.ac.uk [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Julian Tenney [Julian.Tenney at nottingham.ac.uk] Sent: 06 September 2013 14:37 To: For Xerte technical developers Subject: [Xerte-dev] Re: GitHub and Workflows I asked him to commit to 'develop'. I also wondered about where the unstable build should come from. It's not master, as that would be stable, so it must be develop...? ________________________________ From: xerte-dev-bounces at lists.nottingham.ac.uk [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders [reijnders at tor.nl] Sent: 06 September 2013 14:14 To: For Xerte technical developers Subject: [Xerte-dev] Re: GitHub and Workflows Hi, I am in the process of modifying the build scripts to use github in stead of svn. And I noticed that Nicodem committed to master yesterday, so I've got a question given the workflow mentioned below: 1. Will we do hotfixes on released branches, i.e. on master and 2.0? 2. What shall we put up on the community website? What is the equivalent to the svn trunk. master or develop, i.e. what is the basis for 'unstable'? Regards, Tom Op 5-9-2013 15:39, Julian Tenney schreef: Hi, I think we?ve got the SVN migrated over to Git Hub with all the history, branches etc, which is great. We need to have some discussion about workflow, and I want to suggest gitflow as a good workflow to adopt. Information can be found here http://nvie.com/posts/a-successful-git-branching-model/ and elsewhere (here: https://www.atlassian.com/git/workflows for example). I like it for several reasons: - The ?master? branch is always production quality released code - Small developments (trivial) can be undertaken directly in ?develop? - Larger developments can be undertaken in braches taken from ?develop?, and then merged back into develop once complete? - ?testing of develop can then be undertaken before we make a new release number. See the information for more details. Does this seem sensible and agreeable to everyone? There are two other things I?d like us to work towards, again subject to some discussion between us: Using Tickets for Issues and New Features: - Using some ticketing system to record bugs to be fixed, new features to be developed, because we keep losing these; - Using those tickets as a way of grouping work into sprints towards a new release; - Could be trac, could be github, open to suggestions; A better means of testing the software rather than the hit and hope method we currently employ: - Open to suggestions here? - Probably starts with a list of manual tests to work through? - Possibly includes automation (Selenium?) - UnitTesting probably a very long term goal, might not even be possible? So my vision would be that we log tickets, we use that list of tickets as a big to-do list; we create a smaller current to-do list from it for the next release; we do the development a la gitflow; changes get pushed to develop and tested; new version released. It sounds good in theory at any rate, it will require a bit more discipline amongst us, but I think the benefits are worth it. I?d very much appreciate your views? Thanks, Julian This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev -- -- Tom Reijnders TOR Informatica Chopinlaan 27 5242HM Rosmalen Tel: 073 5226191 Fax: 073 5226196 This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. Glasgow Caledonian University is a registered Scottish charity, number SC021474 Winner: Times Higher Education?s Widening Participation Initiative of the Year 2009 and Herald Society?s Education Initiative of the Year 2009. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en.html Winner: Times Higher Education?s Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,15691,en.html From xerte at pgogywebstuff.com Sat Sep 7 09:26:14 2013 From: xerte at pgogywebstuff.com (Pat @ Pgogy ) Date: Sat, 7 Sep 2013 10:26:14 +0200 Subject: [Xerte-dev] Re: GitHub and Workflows In-Reply-To: References: <12C67A1EEC419342AF5E59DA31562C3F0C80D193A9@EXCHANGE1.ad.nottingham.ac.uk> <5229D526.1070208@tor.nl> <12C67A1EEC419342AF5E59DA31562C3F0C80CE5DD3@EXCHANGE1.ad.nottingham.ac.uk> Message-ID: <7D8FC181-2EE6-4EE6-958F-A490EFAFC3FE@pgogywebstuff.com> Maybe we have a release candidate branch? So rather than say 2.5 we move to 2.5 rc? This way 2.5 is a sort of sandpit? On 7 Sep 2013, at 10:02, "Smith, John" wrote: > Morning all, > > The way that I see it we should be doing everyday development in the develop branch; I've merged Nikodems changes to Master back into develop (SourceTree wouldn't let me commit to develop while Master was 2 ahead!!). As Julian said in an earlier email, I will either do this directly for a single change or a gitflow branch off of develop for larger changes... > > Not really sure how the releases and hotfixes should work though... > > I think the thing we have to take most care with (which we didn't always do on Google) was the copying of files between branches/releases. Develop files will often have 'new features' with code that might be unstable. on Google SVN there were a few situations where bugfix changes were being made to the latest revision and then the latest revision file(s) in question were just copied straight over to the v2 branch, introducing any new features into an old release. This is the thing that worries me most, especially if we are having 'Stable' zips built straight from these branches... not really sure yet though how we mitigate this although you can mark chunks in SourceTree and only push those over... > > Regards, > > John Smith | Learning Technologist > Room A251, Govan Mbeki Building | School of Health & Life Sciences | Glasgow Caledonian University > Cowcaddens Road | Glasgow | G4 0BA > ________________________________________ > From: xerte-dev-bounces at lists.nottingham.ac.uk [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Julian Tenney [Julian.Tenney at nottingham.ac.uk] > Sent: 06 September 2013 14:37 > To: For Xerte technical developers > Subject: [Xerte-dev] Re: GitHub and Workflows > > I asked him to commit to 'develop'. > > I also wondered about where the unstable build should come from. It's not master, as that would be stable, so it must be develop...? > > ________________________________ > From: xerte-dev-bounces at lists.nottingham.ac.uk [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders [reijnders at tor.nl] > Sent: 06 September 2013 14:14 > To: For Xerte technical developers > Subject: [Xerte-dev] Re: GitHub and Workflows > > Hi, > > I am in the process of modifying the build scripts to use github in stead of svn. > > And I noticed that Nicodem committed to master yesterday, so I've got a question given the workflow mentioned below: > > 1. Will we do hotfixes on released branches, i.e. on master and 2.0? > 2. What shall we put up on the community website? What is the equivalent to the svn trunk. master or develop, i.e. what is the basis for 'unstable'? > > Regards, > > Tom > > Op 5-9-2013 15:39, Julian Tenney schreef: > Hi, > > I think we?ve got the SVN migrated over to Git Hub with all the history, branches etc, which is great. We need to have some discussion about workflow, and I want to suggest gitflow as a good workflow to adopt. Information can be found here http://nvie.com/posts/a-successful-git-branching-model/ and elsewhere (here: https://www.atlassian.com/git/workflows for example). > > I like it for several reasons: > > > - The ?master? branch is always production quality released code > > - Small developments (trivial) can be undertaken directly in ?develop? > > - Larger developments can be undertaken in braches taken from ?develop?, and then merged back into develop once complete? > > - ?testing of develop can then be undertaken before we make a new release number. > > See the information for more details. Does this seem sensible and agreeable to everyone? > > There are two other things I?d like us to work towards, again subject to some discussion between us: > > Using Tickets for Issues and New Features: > > - Using some ticketing system to record bugs to be fixed, new features to be developed, because we keep losing these; > > - Using those tickets as a way of grouping work into sprints towards a new release; > > - Could be trac, could be github, open to suggestions; > > A better means of testing the software rather than the hit and hope method we currently employ: > > - Open to suggestions here? > > - Probably starts with a list of manual tests to work through? > > - Possibly includes automation (Selenium?) > > - UnitTesting probably a very long term goal, might not even be possible? > > So my vision would be that we log tickets, we use that list of tickets as a big to-do list; we create a smaller current to-do list from it for the next release; we do the development a la gitflow; changes get pushed to develop and tested; new version released. It sounds good in theory at any rate, it will require a bit more discipline amongst us, but I think the benefits are worth it. I?d very much appreciate your views? > > Thanks, > > Julian > > > > > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > > > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > > > > -- > -- > > Tom Reijnders > TOR Informatica > Chopinlaan 27 > 5242HM Rosmalen > Tel: 073 5226191 > Fax: 073 5226196 > > > > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > > Glasgow Caledonian University is a registered Scottish charity, number SC021474 > > Winner: Times Higher Education?s Widening Participation Initiative of the Year 2009 and Herald Society?s Education Initiative of the Year 2009. > http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en.html > > Winner: Times Higher Education?s Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. > http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,15691,en.html > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment > may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > > > From reijnders at tor.nl Sat Sep 7 11:51:40 2013 From: reijnders at tor.nl (Tom Reijnders) Date: Sat, 07 Sep 2013 12:51:40 +0200 Subject: [Xerte-dev] Re: GitHub and Workflows In-Reply-To: References: <12C67A1EEC419342AF5E59DA31562C3F0C80D193A9@EXCHANGE1.ad.nottingham.ac.uk>, <5229D526.1070208@tor.nl>, <12C67A1EEC419342AF5E59DA31562C3F0C80CE5DD3@EXCHANGE1.ad.nottingham.ac.uk> Message-ID: <522B053C.1070504@tor.nl> In that, I think, git will help us more than SVN was. For example, for hotfixes, we should REALLY try to refrain ourselves as much as possible. But suppose we have a mechanism in place on what warrants a hotfix, then we could do it as follows ( suggested by http://nvie.com/posts/a-successful-git-branching-model/): Whenever we identify a bug that needs to go in the latest release: 1. Create a branch of master called hotfix (with a nr, or minor version number) 2. Test, merge back into master (set tag on this fix, it will cause git describe to give us a good text for version.txt, and it is marked as a release in github) 3. merge into develop 4. NO MORE work on the hotfix branch, create a new branch for the next one. Then when we're ready to release (also as suggested by the same workflow) 1. Create a release branch, say 2.5 2. Test and fix, and once ready merge into master (set tag on this fix, it will cause git describe to give us a good text for version .txt, and it is marked as a release in github) 3. merge into develop 4. No more work on the release branch, create a new branch for the next one. The master would be the source of the stable release in the future, so from the next release master will be used for the stable release (what is now 2.0) Develop will be the source of the unstable (so it must not be too unstable, really new developments take place on feature branches) When we have an active release branch, there will be an extra zip for the release candidate. The only drawback so far is that if a release has so many new features that not anyone is able to move to the new release, we might need to maintain a previous release for some time (think of the need to go to for example php 5.4, or something similar) We can solve that by branching of master right before the release branch is merged into master and merge hotfixes in there as well (for as long as we deem necessary). So the full workflow will be active after the next release (because master currently, is not released). And you could treat the current 2.0 as a maintenance release now. The merging of hotfixes might be a bit more difficult to the maintenance release, but at least it's better than copying! Op 7-9-2013 10:02, Smith, John schreef: > Morning all, > > The way that I see it we should be doing everyday development in the develop branch; I've merged Nikodems changes to Master back into develop (SourceTree wouldn't let me commit to develop while Master was 2 ahead!!). As Julian said in an earlier email, I will either do this directly for a single change or a gitflow branch off of develop for larger changes... > > Not really sure how the releases and hotfixes should work though... > > I think the thing we have to take most care with (which we didn't always do on Google) was the copying of files between branches/releases. Develop files will often have 'new features' with code that might be unstable. on Google SVN there were a few situations where bugfix changes were being made to the latest revision and then the latest revision file(s) in question were just copied straight over to the v2 branch, introducing any new features into an old release. This is the thing that worries me most, especially if we are having 'Stable' zips built straight from these branches... not really sure yet though how we mitigate this although you can mark chunks in SourceTree and only push those over... > > Regards, > > John Smith | Learning Technologist > Room A251, Govan Mbeki Building | School of Health & Life Sciences | Glasgow Caledonian University > Cowcaddens Road | Glasgow | G4 0BA > ________________________________________ > From: xerte-dev-bounces at lists.nottingham.ac.uk [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Julian Tenney [Julian.Tenney at nottingham.ac.uk] > Sent: 06 September 2013 14:37 > To: For Xerte technical developers > Subject: [Xerte-dev] Re: GitHub and Workflows > > I asked him to commit to 'develop'. > > I also wondered about where the unstable build should come from. It's not master, as that would be stable, so it must be develop...? > > ________________________________ > From: xerte-dev-bounces at lists.nottingham.ac.uk [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders [reijnders at tor.nl] > Sent: 06 September 2013 14:14 > To: For Xerte technical developers > Subject: [Xerte-dev] Re: GitHub and Workflows > > Hi, > > I am in the process of modifying the build scripts to use github in stead of svn. > > And I noticed that Nicodem committed to master yesterday, so I've got a question given the workflow mentioned below: > > 1. Will we do hotfixes on released branches, i.e. on master and 2.0? > 2. What shall we put up on the community website? What is the equivalent to the svn trunk. master or develop, i.e. what is the basis for 'unstable'? > > Regards, > > Tom > > Op 5-9-2013 15:39, Julian Tenney schreef: > Hi, > > I think we?ve got the SVN migrated over to Git Hub with all the history, branches etc, which is great. We need to have some discussion about workflow, and I want to suggest gitflow as a good workflow to adopt. Information can be found here http://nvie.com/posts/a-successful-git-branching-model/ and elsewhere (here: https://www.atlassian.com/git/workflows for example). > > I like it for several reasons: > > > - The ?master? branch is always production quality released code > > - Small developments (trivial) can be undertaken directly in ?develop? > > - Larger developments can be undertaken in braches taken from ?develop?, and then merged back into develop once complete? > > - ?testing of develop can then be undertaken before we make a new release number. > > See the information for more details. Does this seem sensible and agreeable to everyone? > > There are two other things I?d like us to work towards, again subject to some discussion between us: > > Using Tickets for Issues and New Features: > > - Using some ticketing system to record bugs to be fixed, new features to be developed, because we keep losing these; > > - Using those tickets as a way of grouping work into sprints towards a new release; > > - Could be trac, could be github, open to suggestions; > > A better means of testing the software rather than the hit and hope method we currently employ: > > - Open to suggestions here? > > - Probably starts with a list of manual tests to work through? > > - Possibly includes automation (Selenium?) > > - UnitTesting probably a very long term goal, might not even be possible? > > So my vision would be that we log tickets, we use that list of tickets as a big to-do list; we create a smaller current to-do list from it for the next release; we do the development a la gitflow; changes get pushed to develop and tested; new version released. It sounds good in theory at any rate, it will require a bit more discipline amongst us, but I think the benefits are worth it. I?d very much appreciate your views? > > Thanks, > > Julian > > > > > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > > > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > > > > -- > -- > > Tom Reijnders > TOR Informatica > Chopinlaan 27 > 5242HM Rosmalen > Tel: 073 5226191 > Fax: 073 5226196 > > > > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > > Glasgow Caledonian University is a registered Scottish charity, number SC021474 > > Winner: Times Higher Education?s Widening Participation Initiative of the Year 2009 and Herald Society?s Education Initiative of the Year 2009. > http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en.html > > Winner: Times Higher Education?s Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. > http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,15691,en.html > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment > may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > > > > -- -- Tom Reijnders TOR Informatica Chopinlaan 27 5242HM Rosmalen Tel: 073 5226191 Fax: 073 5226196 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dejfjhdi.png Type: image/png Size: 233919 bytes Desc: not available URL: From J.J.Smith at gcu.ac.uk Sat Sep 7 12:07:27 2013 From: J.J.Smith at gcu.ac.uk (Smith, John) Date: Sat, 7 Sep 2013 12:07:27 +0100 Subject: [Xerte-dev] Re: GitHub and Workflows In-Reply-To: <522B053C.1070504@tor.nl> References: <12C67A1EEC419342AF5E59DA31562C3F0C80D193A9@EXCHANGE1.ad.nottingham.ac.uk>, <5229D526.1070208@tor.nl>, <12C67A1EEC419342AF5E59DA31562C3F0C80CE5DD3@EXCHANGE1.ad.nottingham.ac.uk> , <522B053C.1070504@tor.nl> Message-ID: Yes that looks great... I think that rhombus right in the middle (and the associated comment) with the faded arrows is a very important thing to take on board (for me anyway) - we make the changes in the appropriate branch and merge them back to develop (when appropriate), rather than what seemed to happen in SVN - we often worked in trunk and then copied the 'working' file into the v2 branch... We should document this process somewhere and refer to in until it is instilled in our brains. Regards, John Smith | Learning Technologist Room A251, Govan Mbeki Building | School of Health & Life Sciences | Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA ________________________________________ From: xerte-dev-bounces at lists.nottingham.ac.uk [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders [reijnders at tor.nl] Sent: 07 September 2013 11:51 To: For Xerte technical developers Subject: [Xerte-dev] Re: GitHub and Workflows In that, I think, git will help us more than SVN was. For example, for hotfixes, we should REALLY try to refrain ourselves as much as possible. But suppose we have a mechanism in place on what warrants a hotfix, then we could do it as follows ( suggested by http://nvie.com/posts/a-successful-git-branching-model/): Whenever we identify a bug that needs to go in the latest release: 1. Create a branch of master called hotfix (with a nr, or minor version number) 2. Test, merge back into master (set tag on this fix, it will cause git describe to give us a good text for version.txt, and it is marked as a release in github) 3. merge into develop 4. NO MORE work on the hotfix branch, create a new branch for the next one. Then when we're ready to release (also as suggested by the same workflow) 1. Create a release branch, say 2.5 2. Test and fix, and once ready merge into master (set tag on this fix, it will cause git describe to give us a good text for version .txt, and it is marked as a release in github) 3. merge into develop 4. No more work on the release branch, create a new branch for the next one. The master would be the source of the stable release in the future, so from the next release master will be used for the stable release (what is now 2.0) Develop will be the source of the unstable (so it must not be too unstable, really new developments take place on feature branches) When we have an active release branch, there will be an extra zip for the release candidate. The only drawback so far is that if a release has so many new features that not anyone is able to move to the new release, we might need to maintain a previous release for some time (think of the need to go to for example php 5.4, or something similar) We can solve that by branching of master right before the release branch is merged into master and merge hotfixes in there as well (for as long as we deem necessary). So the full workflow will be active after the next release (because master currently, is not released). And you could treat the current 2.0 as a maintenance release now. The merging of hotfixes might be a bit more difficult to the maintenance release, but at least it's better than copying! [cid:part1.06000105.04050501 at tor.nl] Op 7-9-2013 10:02, Smith, John schreef: Morning all, The way that I see it we should be doing everyday development in the develop branch; I've merged Nikodems changes to Master back into develop (SourceTree wouldn't let me commit to develop while Master was 2 ahead!!). As Julian said in an earlier email, I will either do this directly for a single change or a gitflow branch off of develop for larger changes... Not really sure how the releases and hotfixes should work though... I think the thing we have to take most care with (which we didn't always do on Google) was the copying of files between branches/releases. Develop files will often have 'new features' with code that might be unstable. on Google SVN there were a few situations where bugfix changes were being made to the latest revision and then the latest revision file(s) in question were just copied straight over to the v2 branch, introducing any new features into an old release. This is the thing that worries me most, especially if we are having 'Stable' zips built straight from these branches... not really sure yet though how we mitigate this although you can mark chunks in SourceTree and only push those over... Regards, John Smith | Learning Technologist Room A251, Govan Mbeki Building | School of Health & Life Sciences | Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA ________________________________________ From: xerte-dev-bounces at lists.nottingham.ac.uk [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Julian Tenney [Julian.Tenney at nottingham.ac.uk] Sent: 06 September 2013 14:37 To: For Xerte technical developers Subject: [Xerte-dev] Re: GitHub and Workflows I asked him to commit to 'develop'. I also wondered about where the unstable build should come from. It's not master, as that would be stable, so it must be develop...? ________________________________ From: xerte-dev-bounces at lists.nottingham.ac.uk [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders [reijnders at tor.nl] Sent: 06 September 2013 14:14 To: For Xerte technical developers Subject: [Xerte-dev] Re: GitHub and Workflows Hi, I am in the process of modifying the build scripts to use github in stead of svn. And I noticed that Nicodem committed to master yesterday, so I've got a question given the workflow mentioned below: 1. Will we do hotfixes on released branches, i.e. on master and 2.0? 2. What shall we put up on the community website? What is the equivalent to the svn trunk. master or develop, i.e. what is the basis for 'unstable'? Regards, Tom Op 5-9-2013 15:39, Julian Tenney schreef: Hi, I think we?ve got the SVN migrated over to Git Hub with all the history, branches etc, which is great. We need to have some discussion about workflow, and I want to suggest gitflow as a good workflow to adopt. Information can be found here http://nvie.com/posts/a-successful-git-branching-model/ and elsewhere (here: https://www.atlassian.com/git/workflows for example). I like it for several reasons: - The ?master? branch is always production quality released code - Small developments (trivial) can be undertaken directly in ?develop? - Larger developments can be undertaken in braches taken from ?develop?, and then merged back into develop once complete? - ?testing of develop can then be undertaken before we make a new release number. See the information for more details. Does this seem sensible and agreeable to everyone? There are two other things I?d like us to work towards, again subject to some discussion between us: Using Tickets for Issues and New Features: - Using some ticketing system to record bugs to be fixed, new features to be developed, because we keep losing these; - Using those tickets as a way of grouping work into sprints towards a new release; - Could be trac, could be github, open to suggestions; A better means of testing the software rather than the hit and hope method we currently employ: - Open to suggestions here? - Probably starts with a list of manual tests to work through? - Possibly includes automation (Selenium?) - UnitTesting probably a very long term goal, might not even be possible? So my vision would be that we log tickets, we use that list of tickets as a big to-do list; we create a smaller current to-do list from it for the next release; we do the development a la gitflow; changes get pushed to develop and tested; new version released. It sounds good in theory at any rate, it will require a bit more discipline amongst us, but I think the benefits are worth it. I?d very much appreciate your views? Thanks, Julian This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev -- -- Tom Reijnders TOR Informatica Chopinlaan 27 5242HM Rosmalen Tel: 073 5226191 Fax: 073 5226196 This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. Glasgow Caledonian University is a registered Scottish charity, number SC021474 Winner: Times Higher Education?s Widening Participation Initiative of the Year 2009 and Herald Society?s Education Initiative of the Year 2009. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en.html Winner: Times Higher Education?s Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,15691,en.html _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. -- -- Tom Reijnders TOR Informatica Chopinlaan 27 5242HM Rosmalen Tel: 073 5226191 Fax: 073 5226196 Glasgow Caledonian University is a registered Scottish charity, number SC021474 Winner: Times Higher Education?s Widening Participation Initiative of the Year 2009 and Herald Society?s Education Initiative of the Year 2009. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en.html Winner: Times Higher Education?s Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,15691,en.html From Julian.Tenney at nottingham.ac.uk Mon Sep 9 09:21:50 2013 From: Julian.Tenney at nottingham.ac.uk (Julian Tenney) Date: Mon, 9 Sep 2013 09:21:50 +0100 Subject: [Xerte-dev] Re: GitHub and Workflows In-Reply-To: References: <12C67A1EEC419342AF5E59DA31562C3F0C80D193A9@EXCHANGE1.ad.nottingham.ac.uk>, <5229D526.1070208@tor.nl>, <12C67A1EEC419342AF5E59DA31562C3F0C80CE5DD3@EXCHANGE1.ad.nottingham.ac.uk> , <522B053C.1070504@tor.nl> Message-ID: <12C67A1EEC419342AF5E59DA31562C3F0C81E312D2@EXCHANGE1.ad.nottingham.ac.uk> That's how I understand it too: this is the model http://nvie.com/posts/a-successful-git-branching-model I think it pretty much covers everything. For me, I just need some time getting to know git on a practical basis... -----Original Message----- From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Smith, John Sent: 07 September 2013 12:07 To: For Xerte technical developers Subject: [Xerte-dev] Re: GitHub and Workflows Yes that looks great... I think that rhombus right in the middle (and the associated comment) with the faded arrows is a very important thing to take on board (for me anyway) - we make the changes in the appropriate branch and merge them back to develop (when appropriate), rather than what seemed to happen in SVN - we often worked in trunk and then copied the 'working' file into the v2 branch... We should document this process somewhere and refer to in until it is instilled in our brains. Regards, John Smith | Learning Technologist Room A251, Govan Mbeki Building | School of Health & Life Sciences | Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA ________________________________________ From: xerte-dev-bounces at lists.nottingham.ac.uk [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders [reijnders at tor.nl] Sent: 07 September 2013 11:51 To: For Xerte technical developers Subject: [Xerte-dev] Re: GitHub and Workflows In that, I think, git will help us more than SVN was. For example, for hotfixes, we should REALLY try to refrain ourselves as much as possible. But suppose we have a mechanism in place on what warrants a hotfix, then we could do it as follows ( suggested by http://nvie.com/posts/a-successful-git-branching-model/): Whenever we identify a bug that needs to go in the latest release: 1. Create a branch of master called hotfix (with a nr, or minor version number) 2. Test, merge back into master (set tag on this fix, it will cause git describe to give us a good text for version.txt, and it is marked as a release in github) 3. merge into develop 4. NO MORE work on the hotfix branch, create a new branch for the next one. Then when we're ready to release (also as suggested by the same workflow) 1. Create a release branch, say 2.5 2. Test and fix, and once ready merge into master (set tag on this fix, it will cause git describe to give us a good text for version .txt, and it is marked as a release in github) 3. merge into develop 4. No more work on the release branch, create a new branch for the next one. The master would be the source of the stable release in the future, so from the next release master will be used for the stable release (what is now 2.0) Develop will be the source of the unstable (so it must not be too unstable, really new developments take place on feature branches) When we have an active release branch, there will be an extra zip for the release candidate. The only drawback so far is that if a release has so many new features that not anyone is able to move to the new release, we might need to maintain a previous release for some time (think of the need to go to for example php 5.4, or something similar) We can solve that by branching of master right before the release branch is merged into master and merge hotfixes in there as well (for as long as we deem necessary). So the full workflow will be active after the next release (because master currently, is not released). And you could treat the current 2.0 as a maintenance release now. The merging of hotfixes might be a bit more difficult to the maintenance release, but at least it's better than copying! [cid:part1.06000105.04050501 at tor.nl] Op 7-9-2013 10:02, Smith, John schreef: Morning all, The way that I see it we should be doing everyday development in the develop branch; I've merged Nikodems changes to Master back into develop (SourceTree wouldn't let me commit to develop while Master was 2 ahead!!). As Julian said in an earlier email, I will either do this directly for a single change or a gitflow branch off of develop for larger changes... Not really sure how the releases and hotfixes should work though... I think the thing we have to take most care with (which we didn't always do on Google) was the copying of files between branches/releases. Develop files will often have 'new features' with code that might be unstable. on Google SVN there were a few situations where bugfix changes were being made to the latest revision and then the latest revision file(s) in question were just copied straight over to the v2 branch, introducing any new features into an old release. This is the thing that worries me most, especially if we are having 'Stable' zips built straight from these branches... not really sure yet though how we mitigate this although you can mark chunks in SourceTree and only push those over... Regards, John Smith | Learning Technologist Room A251, Govan Mbeki Building | School of Health & Life Sciences | Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA ________________________________________ From: xerte-dev-bounces at lists.nottingham.ac.uk [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Julian Tenney [Julian.Tenney at nottingham.ac.uk] Sent: 06 September 2013 14:37 To: For Xerte technical developers Subject: [Xerte-dev] Re: GitHub and Workflows I asked him to commit to 'develop'. I also wondered about where the unstable build should come from. It's not master, as that would be stable, so it must be develop...? ________________________________ From: xerte-dev-bounces at lists.nottingham.ac.uk [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders [reijnders at tor.nl] Sent: 06 September 2013 14:14 To: For Xerte technical developers Subject: [Xerte-dev] Re: GitHub and Workflows Hi, I am in the process of modifying the build scripts to use github in stead of svn. And I noticed that Nicodem committed to master yesterday, so I've got a question given the workflow mentioned below: 1. Will we do hotfixes on released branches, i.e. on master and 2.0? 2. What shall we put up on the community website? What is the equivalent to the svn trunk. master or develop, i.e. what is the basis for 'unstable'? Regards, Tom Op 5-9-2013 15:39, Julian Tenney schreef: Hi, I think we've got the SVN migrated over to Git Hub with all the history, branches etc, which is great. We need to have some discussion about workflow, and I want to suggest gitflow as a good workflow to adopt. Information can be found here http://nvie.com/posts/a-successful-git-branching-model/ and elsewhere (here: https://www.atlassian.com/git/workflows for example). I like it for several reasons: - The 'master' branch is always production quality released code - Small developments (trivial) can be undertaken directly in 'develop' - Larger developments can be undertaken in braches taken from 'develop', and then merged back into develop once complete... - ...testing of develop can then be undertaken before we make a new release number. See the information for more details. Does this seem sensible and agreeable to everyone? There are two other things I'd like us to work towards, again subject to some discussion between us: Using Tickets for Issues and New Features: - Using some ticketing system to record bugs to be fixed, new features to be developed, because we keep losing these; - Using those tickets as a way of grouping work into sprints towards a new release; - Could be trac, could be github, open to suggestions; A better means of testing the software rather than the hit and hope method we currently employ: - Open to suggestions here? - Probably starts with a list of manual tests to work through? - Possibly includes automation (Selenium?) - UnitTesting probably a very long term goal, might not even be possible? So my vision would be that we log tickets, we use that list of tickets as a big to-do list; we create a smaller current to-do list from it for the next release; we do the development a la gitflow; changes get pushed to develop and tested; new version released. It sounds good in theory at any rate, it will require a bit more discipline amongst us, but I think the benefits are worth it. I'd very much appreciate your views... Thanks, Julian This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev -- -- Tom Reijnders TOR Informatica Chopinlaan 27 5242HM Rosmalen Tel: 073 5226191 Fax: 073 5226196 This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. Glasgow Caledonian University is a registered Scottish charity, number SC021474 Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en.html Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,15691,en.html _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. -- -- Tom Reijnders TOR Informatica Chopinlaan 27 5242HM Rosmalen Tel: 073 5226191 Fax: 073 5226196 Glasgow Caledonian University is a registered Scottish charity, number SC021474 Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en.html Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,15691,en.html _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev From reijnders at tor.nl Mon Sep 9 09:29:26 2013 From: reijnders at tor.nl (Tom Reijnders) Date: Mon, 09 Sep 2013 10:29:26 +0200 Subject: [Xerte-dev] Re: GitHub and Workflows In-Reply-To: <12C67A1EEC419342AF5E59DA31562C3F0C81E312D2@EXCHANGE1.ad.nottingham.ac.uk> References: <12C67A1EEC419342AF5E59DA31562C3F0C80D193A9@EXCHANGE1.ad.nottingham.ac.uk>, <5229D526.1070208@tor.nl>, <12C67A1EEC419342AF5E59DA31562C3F0C80CE5DD3@EXCHANGE1.ad.nottingham.ac.uk> , <522B053C.1070504@tor.nl> <12C67A1EEC419342AF5E59DA31562C3F0C81E312D2@EXCHANGE1.ad.nottingham.ac.uk> Message-ID: <522D86E6.7070403@tor.nl> Do you agree with inclusion of the maintenance branches? Op 9-9-2013 10:21, Julian Tenney schreef: > That's how I understand it too: this is the model http://nvie.com/posts/a-successful-git-branching-model I think it pretty much covers everything. For me, I just need some time getting to know git on a practical basis... > > -----Original Message----- > From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Smith, John > Sent: 07 September 2013 12:07 > To: For Xerte technical developers > Subject: [Xerte-dev] Re: GitHub and Workflows > > Yes that looks great... I think that rhombus right in the middle (and the associated comment) with the faded arrows is a very important thing to take on board (for me anyway) - we make the changes in the appropriate branch and merge them back to develop (when appropriate), rather than what seemed to happen in SVN - we often worked in trunk and then copied the 'working' file into the v2 branch... > > We should document this process somewhere and refer to in until it is instilled in our brains. > > Regards, > > John Smith | Learning Technologist > Room A251, Govan Mbeki Building | School of Health & Life Sciences | Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA ________________________________________ > From: xerte-dev-bounces at lists.nottingham.ac.uk [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders [reijnders at tor.nl] > Sent: 07 September 2013 11:51 > To: For Xerte technical developers > Subject: [Xerte-dev] Re: GitHub and Workflows > > In that, I think, git will help us more than SVN was. > > For example, for hotfixes, we should REALLY try to refrain ourselves as much as possible. But suppose we have a mechanism in place on what warrants a hotfix, then we could do it as follows ( suggested by http://nvie.com/posts/a-successful-git-branching-model/): > > Whenever we identify a bug that needs to go in the latest release: > 1. Create a branch of master called hotfix (with a nr, or minor version number) 2. Test, merge back into master (set tag on this fix, it will cause git describe to give us a good text for version.txt, and it is marked as a release in github) 3. merge into develop 4. NO MORE work on the hotfix branch, create a new branch for the next one. > > Then when we're ready to release (also as suggested by the same workflow) 1. Create a release branch, say 2.5 2. Test and fix, and once ready merge into master (set tag on this fix, it will cause git describe to give us a good text for version .txt, and it is marked as a release in github) 3. merge into develop 4. No more work on the release branch, create a new branch for the next one. > > The master would be the source of the stable release in the future, so from the next release master will be used for the stable release (what is now 2.0) Develop will be the source of the unstable (so it must not be too unstable, really new developments take place on feature branches) When we have an active release branch, there will be an extra zip for the release candidate. > > The only drawback so far is that if a release has so many new features that not anyone is able to move to the new release, we might need to maintain a previous release for some time (think of the need to go to for example php 5.4, or something similar) > > We can solve that by branching of master right before the release branch is merged into master and merge hotfixes in there as well (for as long as we deem necessary). > > So the full workflow will be active after the next release (because master currently, is not released). And you could treat the current 2.0 as a maintenance release now. The merging of hotfixes might be a bit more difficult to the maintenance release, but at least it's better than copying! > > > [cid:part1.06000105.04050501 at tor.nl] > > > > > Op 7-9-2013 10:02, Smith, John schreef: > > Morning all, > > The way that I see it we should be doing everyday development in the develop branch; I've merged Nikodems changes to Master back into develop (SourceTree wouldn't let me commit to develop while Master was 2 ahead!!). As Julian said in an earlier email, I will either do this directly for a single change or a gitflow branch off of develop for larger changes... > > Not really sure how the releases and hotfixes should work though... > > I think the thing we have to take most care with (which we didn't always do on Google) was the copying of files between branches/releases. Develop files will often have 'new features' with code that might be unstable. on Google SVN there were a few situations where bugfix changes were being made to the latest revision and then the latest revision file(s) in question were just copied straight over to the v2 branch, introducing any new features into an old release. This is the thing that worries me most, especially if we are having 'Stable' zips built straight from these branches... not really sure yet though how we mitigate this although you can mark chunks in SourceTree and only push those over... > > Regards, > > John Smith | Learning Technologist > Room A251, Govan Mbeki Building | School of Health & Life Sciences | Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA ________________________________________ > From: xerte-dev-bounces at lists.nottingham.ac.uk [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Julian Tenney [Julian.Tenney at nottingham.ac.uk] > Sent: 06 September 2013 14:37 > To: For Xerte technical developers > Subject: [Xerte-dev] Re: GitHub and Workflows > > I asked him to commit to 'develop'. > > I also wondered about where the unstable build should come from. It's not master, as that would be stable, so it must be develop...? > > ________________________________ > From: xerte-dev-bounces at lists.nottingham.ac.uk [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders [reijnders at tor.nl] > Sent: 06 September 2013 14:14 > To: For Xerte technical developers > Subject: [Xerte-dev] Re: GitHub and Workflows > > Hi, > > I am in the process of modifying the build scripts to use github in stead of svn. > > And I noticed that Nicodem committed to master yesterday, so I've got a question given the workflow mentioned below: > > 1. Will we do hotfixes on released branches, i.e. on master and 2.0? > 2. What shall we put up on the community website? What is the equivalent to the svn trunk. master or develop, i.e. what is the basis for 'unstable'? > > Regards, > > Tom > > Op 5-9-2013 15:39, Julian Tenney schreef: > Hi, > > I think we've got the SVN migrated over to Git Hub with all the history, branches etc, which is great. We need to have some discussion about workflow, and I want to suggest gitflow as a good workflow to adopt. Information can be found here http://nvie.com/posts/a-successful-git-branching-model/ and elsewhere (here: https://www.atlassian.com/git/workflows for example). > > I like it for several reasons: > > > - The 'master' branch is always production quality released code > > - Small developments (trivial) can be undertaken directly in 'develop' > > - Larger developments can be undertaken in braches taken from 'develop', and then merged back into develop once complete... > > - ...testing of develop can then be undertaken before we make a new release number. > > See the information for more details. Does this seem sensible and agreeable to everyone? > > There are two other things I'd like us to work towards, again subject to some discussion between us: > > Using Tickets for Issues and New Features: > > - Using some ticketing system to record bugs to be fixed, new features to be developed, because we keep losing these; > > - Using those tickets as a way of grouping work into sprints towards a new release; > > - Could be trac, could be github, open to suggestions; > > A better means of testing the software rather than the hit and hope method we currently employ: > > - Open to suggestions here? > > - Probably starts with a list of manual tests to work through? > > - Possibly includes automation (Selenium?) > > - UnitTesting probably a very long term goal, might not even be possible? > > So my vision would be that we log tickets, we use that list of tickets as a big to-do list; we create a smaller current to-do list from it for the next release; we do the development a la gitflow; changes get pushed to develop and tested; new version released. It sounds good in theory at any rate, it will require a bit more discipline amongst us, but I think the benefits are worth it. I'd very much appreciate your views... > > Thanks, > > Julian > > > > > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > > > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > > > > -- > -- > > Tom Reijnders > TOR Informatica > Chopinlaan 27 > 5242HM Rosmalen > Tel: 073 5226191 > Fax: 073 5226196 > > > > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > > Glasgow Caledonian University is a registered Scottish charity, number SC021474 > > Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. > http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en.html > > Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. > http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,15691,en.html > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > > > > > > > > -- > -- > > Tom Reijnders > TOR Informatica > Chopinlaan 27 > 5242HM Rosmalen > Tel: 073 5226191 > Fax: 073 5226196 > > > > > Glasgow Caledonian University is a registered Scottish charity, number SC021474 > > Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. > http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en.html > > Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. > http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,15691,en.html > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment > may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > > > -- -- Tom Reijnders TOR Informatica Chopinlaan 27 5242HM Rosmalen Tel: 073 5226191 Fax: 073 5226196 -------------- next part -------------- A non-text attachment was scrubbed... Name: GitFlow.png Type: image/png Size: 226071 bytes Desc: not available URL: From Julian.Tenney at nottingham.ac.uk Mon Sep 9 09:30:37 2013 From: Julian.Tenney at nottingham.ac.uk (Julian Tenney) Date: Mon, 9 Sep 2013 09:30:37 +0100 Subject: [Xerte-dev] Re: GitHub and Workflows In-Reply-To: <522D86E6.7070403@tor.nl> References: <12C67A1EEC419342AF5E59DA31562C3F0C80D193A9@EXCHANGE1.ad.nottingham.ac.uk>, <5229D526.1070208@tor.nl>, <12C67A1EEC419342AF5E59DA31562C3F0C80CE5DD3@EXCHANGE1.ad.nottingham.ac.uk> , <522B053C.1070504@tor.nl> <12C67A1EEC419342AF5E59DA31562C3F0C81E312D2@EXCHANGE1.ad.nottingham.ac.uk> <522D86E6.7070403@tor.nl> Message-ID: <12C67A1EEC419342AF5E59DA31562C3F0C81E312E8@EXCHANGE1.ad.nottingham.ac.uk> The release branches on the diagram? -----Original Message----- From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders Sent: 09 September 2013 09:29 To: For Xerte technical developers Subject: [Xerte-dev] Re: GitHub and Workflows Do you agree with inclusion of the maintenance branches? Op 9-9-2013 10:21, Julian Tenney schreef: > That's how I understand it too: this is the model http://nvie.com/posts/a-successful-git-branching-model I think it pretty much covers everything. For me, I just need some time getting to know git on a practical basis... > > -----Original Message----- > From: xerte-dev-bounces at lists.nottingham.ac.uk > [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Smith, > John > Sent: 07 September 2013 12:07 > To: For Xerte technical developers > Subject: [Xerte-dev] Re: GitHub and Workflows > > Yes that looks great... I think that rhombus right in the middle (and the associated comment) with the faded arrows is a very important thing to take on board (for me anyway) - we make the changes in the appropriate branch and merge them back to develop (when appropriate), rather than what seemed to happen in SVN - we often worked in trunk and then copied the 'working' file into the v2 branch... > > We should document this process somewhere and refer to in until it is instilled in our brains. > > Regards, > > John Smith | Learning Technologist > Room A251, Govan Mbeki Building | School of Health & Life Sciences | > Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA > ________________________________________ > From: xerte-dev-bounces at lists.nottingham.ac.uk > [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders > [reijnders at tor.nl] > Sent: 07 September 2013 11:51 > To: For Xerte technical developers > Subject: [Xerte-dev] Re: GitHub and Workflows > > In that, I think, git will help us more than SVN was. > > For example, for hotfixes, we should REALLY try to refrain ourselves as much as possible. But suppose we have a mechanism in place on what warrants a hotfix, then we could do it as follows ( suggested by http://nvie.com/posts/a-successful-git-branching-model/): > > Whenever we identify a bug that needs to go in the latest release: > 1. Create a branch of master called hotfix (with a nr, or minor version number) 2. Test, merge back into master (set tag on this fix, it will cause git describe to give us a good text for version.txt, and it is marked as a release in github) 3. merge into develop 4. NO MORE work on the hotfix branch, create a new branch for the next one. > > Then when we're ready to release (also as suggested by the same workflow) 1. Create a release branch, say 2.5 2. Test and fix, and once ready merge into master (set tag on this fix, it will cause git describe to give us a good text for version .txt, and it is marked as a release in github) 3. merge into develop 4. No more work on the release branch, create a new branch for the next one. > > The master would be the source of the stable release in the future, so from the next release master will be used for the stable release (what is now 2.0) Develop will be the source of the unstable (so it must not be too unstable, really new developments take place on feature branches) When we have an active release branch, there will be an extra zip for the release candidate. > > The only drawback so far is that if a release has so many new features > that not anyone is able to move to the new release, we might need to > maintain a previous release for some time (think of the need to go to > for example php 5.4, or something similar) > > We can solve that by branching of master right before the release branch is merged into master and merge hotfixes in there as well (for as long as we deem necessary). > > So the full workflow will be active after the next release (because master currently, is not released). And you could treat the current 2.0 as a maintenance release now. The merging of hotfixes might be a bit more difficult to the maintenance release, but at least it's better than copying! > > > [cid:part1.06000105.04050501 at tor.nl] > > > > > Op 7-9-2013 10:02, Smith, John schreef: > > Morning all, > > The way that I see it we should be doing everyday development in the develop branch; I've merged Nikodems changes to Master back into develop (SourceTree wouldn't let me commit to develop while Master was 2 ahead!!). As Julian said in an earlier email, I will either do this directly for a single change or a gitflow branch off of develop for larger changes... > > Not really sure how the releases and hotfixes should work though... > > I think the thing we have to take most care with (which we didn't always do on Google) was the copying of files between branches/releases. Develop files will often have 'new features' with code that might be unstable. on Google SVN there were a few situations where bugfix changes were being made to the latest revision and then the latest revision file(s) in question were just copied straight over to the v2 branch, introducing any new features into an old release. This is the thing that worries me most, especially if we are having 'Stable' zips built straight from these branches... not really sure yet though how we mitigate this although you can mark chunks in SourceTree and only push those over... > > Regards, > > John Smith | Learning Technologist > Room A251, Govan Mbeki Building | School of Health & Life Sciences | > Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA > ________________________________________ > From: > xerte-dev-bounces at lists.nottingham.ac.uk s.nottingham.ac.uk> > [xerte-dev-bounces at lists.nottingham.ac.uk ts.nottingham.ac.uk>] On Behalf Of Julian Tenney > [Julian.Tenney at nottingham.ac.uk > ] > Sent: 06 September 2013 14:37 > To: For Xerte technical developers > Subject: [Xerte-dev] Re: GitHub and Workflows > > I asked him to commit to 'develop'. > > I also wondered about where the unstable build should come from. It's not master, as that would be stable, so it must be develop...? > > ________________________________ > From: > xerte-dev-bounces at lists.nottingham.ac.uk s.nottingham.ac.uk> > [xerte-dev-bounces at lists.nottingham.ac.uk ts.nottingham.ac.uk>] On Behalf Of Tom Reijnders > [reijnders at tor.nl] > Sent: 06 September 2013 14:14 > To: For Xerte technical developers > Subject: [Xerte-dev] Re: GitHub and Workflows > > Hi, > > I am in the process of modifying the build scripts to use github in stead of svn. > > And I noticed that Nicodem committed to master yesterday, so I've got a question given the workflow mentioned below: > > 1. Will we do hotfixes on released branches, i.e. on master and 2.0? > 2. What shall we put up on the community website? What is the equivalent to the svn trunk. master or develop, i.e. what is the basis for 'unstable'? > > Regards, > > Tom > > Op 5-9-2013 15:39, Julian Tenney schreef: > Hi, > > I think we've got the SVN migrated over to Git Hub with all the history, branches etc, which is great. We need to have some discussion about workflow, and I want to suggest gitflow as a good workflow to adopt. Information can be found here http://nvie.com/posts/a-successful-git-branching-model/ and elsewhere (here: https://www.atlassian.com/git/workflows for example). > > I like it for several reasons: > > > - The 'master' branch is always production quality released code > > - Small developments (trivial) can be undertaken directly in 'develop' > > - Larger developments can be undertaken in braches taken from 'develop', and then merged back into develop once complete... > > - ...testing of develop can then be undertaken before we make a new release number. > > See the information for more details. Does this seem sensible and agreeable to everyone? > > There are two other things I'd like us to work towards, again subject to some discussion between us: > > Using Tickets for Issues and New Features: > > - Using some ticketing system to record bugs to be fixed, new features to be developed, because we keep losing these; > > - Using those tickets as a way of grouping work into sprints towards a new release; > > - Could be trac, could be github, open to suggestions; > > A better means of testing the software rather than the hit and hope method we currently employ: > > - Open to suggestions here? > > - Probably starts with a list of manual tests to work through? > > - Possibly includes automation (Selenium?) > > - UnitTesting probably a very long term goal, might not even be possible? > > So my vision would be that we log tickets, we use that list of tickets as a big to-do list; we create a smaller current to-do list from it for the next release; we do the development a la gitflow; changes get pushed to develop and tested; new version released. It sounds good in theory at any rate, it will require a bit more discipline amongst us, but I think the benefits are worth it. I'd very much appreciate your views... > > Thanks, > > Julian > > > > > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > > > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk uk> ttingham.ac.uk> > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > > > > -- > -- > > Tom Reijnders > TOR Informatica > Chopinlaan 27 > 5242HM Rosmalen > Tel: 073 5226191 > Fax: 073 5226196 > > > > > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > > Glasgow Caledonian University is a registered Scottish charity, number > SC021474 > > Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. > http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6 > 219,en.html > > Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. > http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,1 > 5691,en.html > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk uk> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > > > > > > > > -- > -- > > Tom Reijnders > TOR Informatica > Chopinlaan 27 > 5242HM Rosmalen > Tel: 073 5226191 > Fax: 073 5226196 > > > > > Glasgow Caledonian University is a registered Scottish charity, number > SC021474 > > Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. > http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6 > 219,en.html > > Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. > http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,1 > 5691,en.html > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > > > -- -- Tom Reijnders TOR Informatica Chopinlaan 27 5242HM Rosmalen Tel: 073 5226191 Fax: 073 5226196 From reijnders at tor.nl Mon Sep 9 09:37:33 2013 From: reijnders at tor.nl (Tom Reijnders) Date: Mon, 09 Sep 2013 10:37:33 +0200 Subject: [Xerte-dev] Re: GitHub and Workflows In-Reply-To: <12C67A1EEC419342AF5E59DA31562C3F0C81E312E8@EXCHANGE1.ad.nottingham.ac.uk> References: <12C67A1EEC419342AF5E59DA31562C3F0C80D193A9@EXCHANGE1.ad.nottingham.ac.uk>, <5229D526.1070208@tor.nl>, <12C67A1EEC419342AF5E59DA31562C3F0C80CE5DD3@EXCHANGE1.ad.nottingham.ac.uk> , <522B053C.1070504@tor.nl> <12C67A1EEC419342AF5E59DA31562C3F0C81E312D2@EXCHANGE1.ad.nottingham.ac.uk> <522D86E6.7070403@tor.nl> <12C67A1EEC419342AF5E59DA31562C3F0C81E312E8@EXCHANGE1.ad.nottingham.ac.uk> Message-ID: <522D88CD.4020304@tor.nl> No I added something to the diagram (included in last e-mail) 'maintenance': See also attached email Tom Op 9-9-2013 10:30, Julian Tenney schreef: > The release branches on the diagram? > > -----Original Message----- > From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders > Sent: 09 September 2013 09:29 > To: For Xerte technical developers > Subject: [Xerte-dev] Re: GitHub and Workflows > > Do you agree with inclusion of the maintenance branches? > > Op 9-9-2013 10:21, Julian Tenney schreef: >> That's how I understand it too: this is the model http://nvie.com/posts/a-successful-git-branching-model I think it pretty much covers everything. For me, I just need some time getting to know git on a practical basis... >> >> -----Original Message----- >> From: xerte-dev-bounces at lists.nottingham.ac.uk >> [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Smith, >> John >> Sent: 07 September 2013 12:07 >> To: For Xerte technical developers >> Subject: [Xerte-dev] Re: GitHub and Workflows >> >> Yes that looks great... I think that rhombus right in the middle (and the associated comment) with the faded arrows is a very important thing to take on board (for me anyway) - we make the changes in the appropriate branch and merge them back to develop (when appropriate), rather than what seemed to happen in SVN - we often worked in trunk and then copied the 'working' file into the v2 branch... >> >> We should document this process somewhere and refer to in until it is instilled in our brains. >> >> Regards, >> >> John Smith | Learning Technologist >> Room A251, Govan Mbeki Building | School of Health & Life Sciences | >> Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA >> ________________________________________ >> From: xerte-dev-bounces at lists.nottingham.ac.uk >> [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders >> [reijnders at tor.nl] >> Sent: 07 September 2013 11:51 >> To: For Xerte technical developers >> Subject: [Xerte-dev] Re: GitHub and Workflows >> >> In that, I think, git will help us more than SVN was. >> >> For example, for hotfixes, we should REALLY try to refrain ourselves as much as possible. But suppose we have a mechanism in place on what warrants a hotfix, then we could do it as follows ( suggested by http://nvie.com/posts/a-successful-git-branching-model/): >> >> Whenever we identify a bug that needs to go in the latest release: >> 1. Create a branch of master called hotfix (with a nr, or minor version number) 2. Test, merge back into master (set tag on this fix, it will cause git describe to give us a good text for version.txt, and it is marked as a release in github) 3. merge into develop 4. NO MORE work on the hotfix branch, create a new branch for the next one. >> >> Then when we're ready to release (also as suggested by the same workflow) 1. Create a release branch, say 2.5 2. Test and fix, and once ready merge into master (set tag on this fix, it will cause git describe to give us a good text for version .txt, and it is marked as a release in github) 3. merge into develop 4. No more work on the release branch, create a new branch for the next one. >> >> The master would be the source of the stable release in the future, so from the next release master will be used for the stable release (what is now 2.0) Develop will be the source of the unstable (so it must not be too unstable, really new developments take place on feature branches) When we have an active release branch, there will be an extra zip for the release candidate. >> >> The only drawback so far is that if a release has so many new features >> that not anyone is able to move to the new release, we might need to >> maintain a previous release for some time (think of the need to go to >> for example php 5.4, or something similar) >> >> We can solve that by branching of master right before the release branch is merged into master and merge hotfixes in there as well (for as long as we deem necessary). >> >> So the full workflow will be active after the next release (because master currently, is not released). And you could treat the current 2.0 as a maintenance release now. The merging of hotfixes might be a bit more difficult to the maintenance release, but at least it's better than copying! >> >> >> [cid:part1.06000105.04050501 at tor.nl] >> >> >> >> >> Op 7-9-2013 10:02, Smith, John schreef: >> >> Morning all, >> >> The way that I see it we should be doing everyday development in the develop branch; I've merged Nikodems changes to Master back into develop (SourceTree wouldn't let me commit to develop while Master was 2 ahead!!). As Julian said in an earlier email, I will either do this directly for a single change or a gitflow branch off of develop for larger changes... >> >> Not really sure how the releases and hotfixes should work though... >> >> I think the thing we have to take most care with (which we didn't always do on Google) was the copying of files between branches/releases. Develop files will often have 'new features' with code that might be unstable. on Google SVN there were a few situations where bugfix changes were being made to the latest revision and then the latest revision file(s) in question were just copied straight over to the v2 branch, introducing any new features into an old release. This is the thing that worries me most, especially if we are having 'Stable' zips built straight from these branches... not really sure yet though how we mitigate this although you can mark chunks in SourceTree and only push those over... >> >> Regards, >> >> John Smith | Learning Technologist >> Room A251, Govan Mbeki Building | School of Health & Life Sciences | >> Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA >> ________________________________________ >> From: >> xerte-dev-bounces at lists.nottingham.ac.uk> s.nottingham.ac.uk> >> [xerte-dev-bounces at lists.nottingham.ac.uk> ts.nottingham.ac.uk>] On Behalf Of Julian Tenney >> [Julian.Tenney at nottingham.ac.uk >> ] >> Sent: 06 September 2013 14:37 >> To: For Xerte technical developers >> Subject: [Xerte-dev] Re: GitHub and Workflows >> >> I asked him to commit to 'develop'. >> >> I also wondered about where the unstable build should come from. It's not master, as that would be stable, so it must be develop...? >> >> ________________________________ >> From: >> xerte-dev-bounces at lists.nottingham.ac.uk> s.nottingham.ac.uk> >> [xerte-dev-bounces at lists.nottingham.ac.uk> ts.nottingham.ac.uk>] On Behalf Of Tom Reijnders >> [reijnders at tor.nl] >> Sent: 06 September 2013 14:14 >> To: For Xerte technical developers >> Subject: [Xerte-dev] Re: GitHub and Workflows >> >> Hi, >> >> I am in the process of modifying the build scripts to use github in stead of svn. >> >> And I noticed that Nicodem committed to master yesterday, so I've got a question given the workflow mentioned below: >> >> 1. Will we do hotfixes on released branches, i.e. on master and 2.0? >> 2. What shall we put up on the community website? What is the equivalent to the svn trunk. master or develop, i.e. what is the basis for 'unstable'? >> >> Regards, >> >> Tom >> >> Op 5-9-2013 15:39, Julian Tenney schreef: >> Hi, >> >> I think we've got the SVN migrated over to Git Hub with all the history, branches etc, which is great. We need to have some discussion about workflow, and I want to suggest gitflow as a good workflow to adopt. Information can be found here http://nvie.com/posts/a-successful-git-branching-model/ and elsewhere (here: https://www.atlassian.com/git/workflows for example). >> >> I like it for several reasons: >> >> >> - The 'master' branch is always production quality released code >> >> - Small developments (trivial) can be undertaken directly in 'develop' >> >> - Larger developments can be undertaken in braches taken from 'develop', and then merged back into develop once complete... >> >> - ...testing of develop can then be undertaken before we make a new release number. >> >> See the information for more details. Does this seem sensible and agreeable to everyone? >> >> There are two other things I'd like us to work towards, again subject to some discussion between us: >> >> Using Tickets for Issues and New Features: >> >> - Using some ticketing system to record bugs to be fixed, new features to be developed, because we keep losing these; >> >> - Using those tickets as a way of grouping work into sprints towards a new release; >> >> - Could be trac, could be github, open to suggestions; >> >> A better means of testing the software rather than the hit and hope method we currently employ: >> >> - Open to suggestions here? >> >> - Probably starts with a list of manual tests to work through? >> >> - Possibly includes automation (Selenium?) >> >> - UnitTesting probably a very long term goal, might not even be possible? >> >> So my vision would be that we log tickets, we use that list of tickets as a big to-do list; we create a smaller current to-do list from it for the next release; we do the development a la gitflow; changes get pushed to develop and tested; new version released. It sounds good in theory at any rate, it will require a bit more discipline amongst us, but I think the benefits are worth it. I'd very much appreciate your views... >> >> Thanks, >> >> Julian >> >> >> >> >> >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> >> >> _______________________________________________ >> Xerte-dev mailing list >> Xerte-dev at lists.nottingham.ac.uk> uk>> ttingham.ac.uk> >> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> >> >> >> -- >> -- >> >> Tom Reijnders >> TOR Informatica >> Chopinlaan 27 >> 5242HM Rosmalen >> Tel: 073 5226191 >> Fax: 073 5226196 >> >> >> >> >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> Glasgow Caledonian University is a registered Scottish charity, number >> SC021474 >> >> Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. >> http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6 >> 219,en.html >> >> Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. >> http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,1 >> 5691,en.html >> >> _______________________________________________ >> Xerte-dev mailing list >> Xerte-dev at lists.nottingham.ac.uk> uk> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> >> >> >> >> >> >> -- >> -- >> >> Tom Reijnders >> TOR Informatica >> Chopinlaan 27 >> 5242HM Rosmalen >> Tel: 073 5226191 >> Fax: 073 5226196 >> >> >> >> >> Glasgow Caledonian University is a registered Scottish charity, number >> SC021474 >> >> Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. >> http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6 >> 219,en.html >> >> Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. >> http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,1 >> 5691,en.html >> >> _______________________________________________ >> Xerte-dev mailing list >> Xerte-dev at lists.nottingham.ac.uk >> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> >> _______________________________________________ >> Xerte-dev mailing list >> Xerte-dev at lists.nottingham.ac.uk >> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an >> attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> >> > -- > -- > > Tom Reijnders > TOR Informatica > Chopinlaan 27 > 5242HM Rosmalen > Tel: 073 5226191 > Fax: 073 5226196 > > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment > may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > > > -- -- Tom Reijnders TOR Informatica Chopinlaan 27 5242HM Rosmalen Tel: 073 5226191 Fax: 073 5226196 -------------- next part -------------- An embedded message was scrubbed... From: Tom Reijnders Subject: Re: [Xerte-dev] Re: GitHub and Workflows Date: Sat, 07 Sep 2013 12:51:40 +0200 Size: 341023 URL: From Julian.Tenney at nottingham.ac.uk Mon Sep 9 09:38:55 2013 From: Julian.Tenney at nottingham.ac.uk (Julian Tenney) Date: Mon, 9 Sep 2013 09:38:55 +0100 Subject: [Xerte-dev] Re: GitHub and Workflows In-Reply-To: <522D88CD.4020304@tor.nl> References: <12C67A1EEC419342AF5E59DA31562C3F0C80D193A9@EXCHANGE1.ad.nottingham.ac.uk>, <5229D526.1070208@tor.nl>, <12C67A1EEC419342AF5E59DA31562C3F0C80CE5DD3@EXCHANGE1.ad.nottingham.ac.uk> , <522B053C.1070504@tor.nl> <12C67A1EEC419342AF5E59DA31562C3F0C81E312D2@EXCHANGE1.ad.nottingham.ac.uk> <522D86E6.7070403@tor.nl> <12C67A1EEC419342AF5E59DA31562C3F0C81E312E8@EXCHANGE1.ad.nottingham.ac.uk> <522D88CD.4020304@tor.nl> Message-ID: <12C67A1EEC419342AF5E59DA31562C3F0C81E312F9@EXCHANGE1.ad.nottingham.ac.uk> Sorry, I missed that. That's fine - but what's the difference between that and a finished 'release'? -----Original Message----- From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders Sent: 09 September 2013 09:38 To: For Xerte technical developers Subject: [Xerte-dev] Re: GitHub and Workflows No I added something to the diagram (included in last e-mail) 'maintenance': See also attached email Tom Op 9-9-2013 10:30, Julian Tenney schreef: > The release branches on the diagram? > > -----Original Message----- > From: xerte-dev-bounces at lists.nottingham.ac.uk > [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom > Reijnders > Sent: 09 September 2013 09:29 > To: For Xerte technical developers > Subject: [Xerte-dev] Re: GitHub and Workflows > > Do you agree with inclusion of the maintenance branches? > > Op 9-9-2013 10:21, Julian Tenney schreef: >> That's how I understand it too: this is the model http://nvie.com/posts/a-successful-git-branching-model I think it pretty much covers everything. For me, I just need some time getting to know git on a practical basis... >> >> -----Original Message----- >> From: xerte-dev-bounces at lists.nottingham.ac.uk >> [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Smith, >> John >> Sent: 07 September 2013 12:07 >> To: For Xerte technical developers >> Subject: [Xerte-dev] Re: GitHub and Workflows >> >> Yes that looks great... I think that rhombus right in the middle (and the associated comment) with the faded arrows is a very important thing to take on board (for me anyway) - we make the changes in the appropriate branch and merge them back to develop (when appropriate), rather than what seemed to happen in SVN - we often worked in trunk and then copied the 'working' file into the v2 branch... >> >> We should document this process somewhere and refer to in until it is instilled in our brains. >> >> Regards, >> >> John Smith | Learning Technologist >> Room A251, Govan Mbeki Building | School of Health & Life Sciences | >> Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA >> ________________________________________ >> From: xerte-dev-bounces at lists.nottingham.ac.uk >> [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders >> [reijnders at tor.nl] >> Sent: 07 September 2013 11:51 >> To: For Xerte technical developers >> Subject: [Xerte-dev] Re: GitHub and Workflows >> >> In that, I think, git will help us more than SVN was. >> >> For example, for hotfixes, we should REALLY try to refrain ourselves as much as possible. But suppose we have a mechanism in place on what warrants a hotfix, then we could do it as follows ( suggested by http://nvie.com/posts/a-successful-git-branching-model/): >> >> Whenever we identify a bug that needs to go in the latest release: >> 1. Create a branch of master called hotfix (with a nr, or minor version number) 2. Test, merge back into master (set tag on this fix, it will cause git describe to give us a good text for version.txt, and it is marked as a release in github) 3. merge into develop 4. NO MORE work on the hotfix branch, create a new branch for the next one. >> >> Then when we're ready to release (also as suggested by the same workflow) 1. Create a release branch, say 2.5 2. Test and fix, and once ready merge into master (set tag on this fix, it will cause git describe to give us a good text for version .txt, and it is marked as a release in github) 3. merge into develop 4. No more work on the release branch, create a new branch for the next one. >> >> The master would be the source of the stable release in the future, so from the next release master will be used for the stable release (what is now 2.0) Develop will be the source of the unstable (so it must not be too unstable, really new developments take place on feature branches) When we have an active release branch, there will be an extra zip for the release candidate. >> >> The only drawback so far is that if a release has so many new >> features that not anyone is able to move to the new release, we might >> need to maintain a previous release for some time (think of the need >> to go to for example php 5.4, or something similar) >> >> We can solve that by branching of master right before the release branch is merged into master and merge hotfixes in there as well (for as long as we deem necessary). >> >> So the full workflow will be active after the next release (because master currently, is not released). And you could treat the current 2.0 as a maintenance release now. The merging of hotfixes might be a bit more difficult to the maintenance release, but at least it's better than copying! >> >> >> [cid:part1.06000105.04050501 at tor.nl] >> >> >> >> >> Op 7-9-2013 10:02, Smith, John schreef: >> >> Morning all, >> >> The way that I see it we should be doing everyday development in the develop branch; I've merged Nikodems changes to Master back into develop (SourceTree wouldn't let me commit to develop while Master was 2 ahead!!). As Julian said in an earlier email, I will either do this directly for a single change or a gitflow branch off of develop for larger changes... >> >> Not really sure how the releases and hotfixes should work though... >> >> I think the thing we have to take most care with (which we didn't always do on Google) was the copying of files between branches/releases. Develop files will often have 'new features' with code that might be unstable. on Google SVN there were a few situations where bugfix changes were being made to the latest revision and then the latest revision file(s) in question were just copied straight over to the v2 branch, introducing any new features into an old release. This is the thing that worries me most, especially if we are having 'Stable' zips built straight from these branches... not really sure yet though how we mitigate this although you can mark chunks in SourceTree and only push those over... >> >> Regards, >> >> John Smith | Learning Technologist >> Room A251, Govan Mbeki Building | School of Health & Life Sciences | >> Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA >> ________________________________________ >> From: >> xerte-dev-bounces at lists.nottingham.ac.uk> t >> s.nottingham.ac.uk> >> [xerte-dev-bounces at lists.nottingham.ac.uk> s ts.nottingham.ac.uk>] On Behalf Of Julian Tenney >> [Julian.Tenney at nottingham.ac.uk> > >> ] >> Sent: 06 September 2013 14:37 >> To: For Xerte technical developers >> Subject: [Xerte-dev] Re: GitHub and Workflows >> >> I asked him to commit to 'develop'. >> >> I also wondered about where the unstable build should come from. It's not master, as that would be stable, so it must be develop...? >> >> ________________________________ >> From: >> xerte-dev-bounces at lists.nottingham.ac.uk> t >> s.nottingham.ac.uk> >> [xerte-dev-bounces at lists.nottingham.ac.uk> s ts.nottingham.ac.uk>] On Behalf Of Tom Reijnders >> [reijnders at tor.nl] >> Sent: 06 September 2013 14:14 >> To: For Xerte technical developers >> Subject: [Xerte-dev] Re: GitHub and Workflows >> >> Hi, >> >> I am in the process of modifying the build scripts to use github in stead of svn. >> >> And I noticed that Nicodem committed to master yesterday, so I've got a question given the workflow mentioned below: >> >> 1. Will we do hotfixes on released branches, i.e. on master and 2.0? >> 2. What shall we put up on the community website? What is the equivalent to the svn trunk. master or develop, i.e. what is the basis for 'unstable'? >> >> Regards, >> >> Tom >> >> Op 5-9-2013 15:39, Julian Tenney schreef: >> Hi, >> >> I think we've got the SVN migrated over to Git Hub with all the history, branches etc, which is great. We need to have some discussion about workflow, and I want to suggest gitflow as a good workflow to adopt. Information can be found here http://nvie.com/posts/a-successful-git-branching-model/ and elsewhere (here: https://www.atlassian.com/git/workflows for example). >> >> I like it for several reasons: >> >> >> - The 'master' branch is always production quality released code >> >> - Small developments (trivial) can be undertaken directly in 'develop' >> >> - Larger developments can be undertaken in braches taken from 'develop', and then merged back into develop once complete... >> >> - ...testing of develop can then be undertaken before we make a new release number. >> >> See the information for more details. Does this seem sensible and agreeable to everyone? >> >> There are two other things I'd like us to work towards, again subject to some discussion between us: >> >> Using Tickets for Issues and New Features: >> >> - Using some ticketing system to record bugs to be fixed, new features to be developed, because we keep losing these; >> >> - Using those tickets as a way of grouping work into sprints towards a new release; >> >> - Could be trac, could be github, open to suggestions; >> >> A better means of testing the software rather than the hit and hope method we currently employ: >> >> - Open to suggestions here? >> >> - Probably starts with a list of manual tests to work through? >> >> - Possibly includes automation (Selenium?) >> >> - UnitTesting probably a very long term goal, might not even be possible? >> >> So my vision would be that we log tickets, we use that list of tickets as a big to-do list; we create a smaller current to-do list from it for the next release; we do the development a la gitflow; changes get pushed to develop and tested; new version released. It sounds good in theory at any rate, it will require a bit more discipline amongst us, but I think the benefits are worth it. I'd very much appreciate your views... >> >> Thanks, >> >> Julian >> >> >> >> >> >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> >> >> _______________________________________________ >> Xerte-dev mailing list >> Xerte-dev at lists.nottingham.ac.uk> uk>> uk>o >> ttingham.ac.uk> >> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> >> >> >> -- >> -- >> >> Tom Reijnders >> TOR Informatica >> Chopinlaan 27 >> 5242HM Rosmalen >> Tel: 073 5226191 >> Fax: 073 5226196 >> >> >> >> >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> Glasgow Caledonian University is a registered Scottish charity, >> number >> SC021474 >> >> Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. >> http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name, >> 6 >> 219,en.html >> >> Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. >> http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name, >> 1 >> 5691,en.html >> >> _______________________________________________ >> Xerte-dev mailing list >> Xerte-dev at lists.nottingham.ac.uk> uk> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> >> >> >> >> >> >> -- >> -- >> >> Tom Reijnders >> TOR Informatica >> Chopinlaan 27 >> 5242HM Rosmalen >> Tel: 073 5226191 >> Fax: 073 5226196 >> >> >> >> >> Glasgow Caledonian University is a registered Scottish charity, >> number >> SC021474 >> >> Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. >> http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name, >> 6 >> 219,en.html >> >> Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. >> http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name, >> 1 >> 5691,en.html >> >> _______________________________________________ >> Xerte-dev mailing list >> Xerte-dev at lists.nottingham.ac.uk >> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> >> _______________________________________________ >> Xerte-dev mailing list >> Xerte-dev at lists.nottingham.ac.uk >> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an >> attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> >> > -- > -- > > Tom Reijnders > TOR Informatica > Chopinlaan 27 > 5242HM Rosmalen > Tel: 073 5226191 > Fax: 073 5226196 > > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > > > -- -- Tom Reijnders TOR Informatica Chopinlaan 27 5242HM Rosmalen Tel: 073 5226191 Fax: 073 5226196 From reijnders at tor.nl Mon Sep 9 09:46:56 2013 From: reijnders at tor.nl (Tom Reijnders) Date: Mon, 09 Sep 2013 10:46:56 +0200 Subject: [Xerte-dev] Re: GitHub and Workflows In-Reply-To: <12C67A1EEC419342AF5E59DA31562C3F0C81E312F9@EXCHANGE1.ad.nottingham.ac.uk> References: <12C67A1EEC419342AF5E59DA31562C3F0C80D193A9@EXCHANGE1.ad.nottingham.ac.uk>, <5229D526.1070208@tor.nl>, <12C67A1EEC419342AF5E59DA31562C3F0C80CE5DD3@EXCHANGE1.ad.nottingham.ac.uk> , <522B053C.1070504@tor.nl> <12C67A1EEC419342AF5E59DA31562C3F0C81E312D2@EXCHANGE1.ad.nottingham.ac.uk> <522D86E6.7070403@tor.nl> <12C67A1EEC419342AF5E59DA31562C3F0C81E312E8@EXCHANGE1.ad.nottingham.ac.uk> <522D88CD.4020304@tor.nl> <12C67A1EEC419342AF5E59DA31562C3F0C81E312F9@EXCHANGE1.ad.nottingham.ac.uk> Message-ID: <522D8B00.6000008@tor.nl> Normally you wouldn't do maintenance (i.e. hotfixes) on a /previous/ release, only the current. So normally we wouldn't do this, but in some cases when the latest release has new requirements on the server we could consider to do hotfixes on a /previous/ release. I added that to the picture. It follows naturally from using hotfix branches. The 'only' issue now, is to determine what warrants a hotfix :-) Tom Op 9-9-2013 10:38, Julian Tenney schreef: > Sorry, I missed that. That's fine - but what's the difference between that and a finished 'release'? > > -----Original Message----- > From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders > Sent: 09 September 2013 09:38 > To: For Xerte technical developers > Subject: [Xerte-dev] Re: GitHub and Workflows > > No I added something to the diagram (included in last e-mail) 'maintenance': > > See also attached email > > Tom > > > Op 9-9-2013 10:30, Julian Tenney schreef: >> The release branches on the diagram? >> >> -----Original Message----- >> From: xerte-dev-bounces at lists.nottingham.ac.uk >> [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom >> Reijnders >> Sent: 09 September 2013 09:29 >> To: For Xerte technical developers >> Subject: [Xerte-dev] Re: GitHub and Workflows >> >> Do you agree with inclusion of the maintenance branches? >> >> Op 9-9-2013 10:21, Julian Tenney schreef: >>> That's how I understand it too: this is the model http://nvie.com/posts/a-successful-git-branching-model I think it pretty much covers everything. For me, I just need some time getting to know git on a practical basis... >>> >>> -----Original Message----- >>> From: xerte-dev-bounces at lists.nottingham.ac.uk >>> [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Smith, >>> John >>> Sent: 07 September 2013 12:07 >>> To: For Xerte technical developers >>> Subject: [Xerte-dev] Re: GitHub and Workflows >>> >>> Yes that looks great... I think that rhombus right in the middle (and the associated comment) with the faded arrows is a very important thing to take on board (for me anyway) - we make the changes in the appropriate branch and merge them back to develop (when appropriate), rather than what seemed to happen in SVN - we often worked in trunk and then copied the 'working' file into the v2 branch... >>> >>> We should document this process somewhere and refer to in until it is instilled in our brains. >>> >>> Regards, >>> >>> John Smith | Learning Technologist >>> Room A251, Govan Mbeki Building | School of Health & Life Sciences | >>> Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA >>> ________________________________________ >>> From: xerte-dev-bounces at lists.nottingham.ac.uk >>> [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders >>> [reijnders at tor.nl] >>> Sent: 07 September 2013 11:51 >>> To: For Xerte technical developers >>> Subject: [Xerte-dev] Re: GitHub and Workflows >>> >>> In that, I think, git will help us more than SVN was. >>> >>> For example, for hotfixes, we should REALLY try to refrain ourselves as much as possible. But suppose we have a mechanism in place on what warrants a hotfix, then we could do it as follows ( suggested by http://nvie.com/posts/a-successful-git-branching-model/): >>> >>> Whenever we identify a bug that needs to go in the latest release: >>> 1. Create a branch of master called hotfix (with a nr, or minor version number) 2. Test, merge back into master (set tag on this fix, it will cause git describe to give us a good text for version.txt, and it is marked as a release in github) 3. merge into develop 4. NO MORE work on the hotfix branch, create a new branch for the next one. >>> >>> Then when we're ready to release (also as suggested by the same workflow) 1. Create a release branch, say 2.5 2. Test and fix, and once ready merge into master (set tag on this fix, it will cause git describe to give us a good text for version .txt, and it is marked as a release in github) 3. merge into develop 4. No more work on the release branch, create a new branch for the next one. >>> >>> The master would be the source of the stable release in the future, so from the next release master will be used for the stable release (what is now 2.0) Develop will be the source of the unstable (so it must not be too unstable, really new developments take place on feature branches) When we have an active release branch, there will be an extra zip for the release candidate. >>> >>> The only drawback so far is that if a release has so many new >>> features that not anyone is able to move to the new release, we might >>> need to maintain a previous release for some time (think of the need >>> to go to for example php 5.4, or something similar) >>> >>> We can solve that by branching of master right before the release branch is merged into master and merge hotfixes in there as well (for as long as we deem necessary). >>> >>> So the full workflow will be active after the next release (because master currently, is not released). And you could treat the current 2.0 as a maintenance release now. The merging of hotfixes might be a bit more difficult to the maintenance release, but at least it's better than copying! >>> >>> >>> [cid:part1.06000105.04050501 at tor.nl] >>> >>> >>> >>> >>> Op 7-9-2013 10:02, Smith, John schreef: >>> >>> Morning all, >>> >>> The way that I see it we should be doing everyday development in the develop branch; I've merged Nikodems changes to Master back into develop (SourceTree wouldn't let me commit to develop while Master was 2 ahead!!). As Julian said in an earlier email, I will either do this directly for a single change or a gitflow branch off of develop for larger changes... >>> >>> Not really sure how the releases and hotfixes should work though... >>> >>> I think the thing we have to take most care with (which we didn't always do on Google) was the copying of files between branches/releases. Develop files will often have 'new features' with code that might be unstable. on Google SVN there were a few situations where bugfix changes were being made to the latest revision and then the latest revision file(s) in question were just copied straight over to the v2 branch, introducing any new features into an old release. This is the thing that worries me most, especially if we are having 'Stable' zips built straight from these branches... not really sure yet though how we mitigate this although you can mark chunks in SourceTree and only push those over... >>> >>> Regards, >>> >>> John Smith | Learning Technologist >>> Room A251, Govan Mbeki Building | School of Health & Life Sciences | >>> Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA >>> ________________________________________ >>> From: >>> xerte-dev-bounces at lists.nottingham.ac.uk>> t >>> s.nottingham.ac.uk> >>> [xerte-dev-bounces at lists.nottingham.ac.uk>> s ts.nottingham.ac.uk>] On Behalf Of Julian Tenney >>> [Julian.Tenney at nottingham.ac.uk>> ] >>> Sent: 06 September 2013 14:37 >>> To: For Xerte technical developers >>> Subject: [Xerte-dev] Re: GitHub and Workflows >>> >>> I asked him to commit to 'develop'. >>> >>> I also wondered about where the unstable build should come from. It's not master, as that would be stable, so it must be develop...? >>> >>> ________________________________ >>> From: >>> xerte-dev-bounces at lists.nottingham.ac.uk>> t >>> s.nottingham.ac.uk> >>> [xerte-dev-bounces at lists.nottingham.ac.uk>> s ts.nottingham.ac.uk>] On Behalf Of Tom Reijnders >>> [reijnders at tor.nl] >>> Sent: 06 September 2013 14:14 >>> To: For Xerte technical developers >>> Subject: [Xerte-dev] Re: GitHub and Workflows >>> >>> Hi, >>> >>> I am in the process of modifying the build scripts to use github in stead of svn. >>> >>> And I noticed that Nicodem committed to master yesterday, so I've got a question given the workflow mentioned below: >>> >>> 1. Will we do hotfixes on released branches, i.e. on master and 2.0? >>> 2. What shall we put up on the community website? What is the equivalent to the svn trunk. master or develop, i.e. what is the basis for 'unstable'? >>> >>> Regards, >>> >>> Tom >>> >>> Op 5-9-2013 15:39, Julian Tenney schreef: >>> Hi, >>> >>> I think we've got the SVN migrated over to Git Hub with all the history, branches etc, which is great. We need to have some discussion about workflow, and I want to suggest gitflow as a good workflow to adopt. Information can be found here http://nvie.com/posts/a-successful-git-branching-model/ and elsewhere (here: https://www.atlassian.com/git/workflows for example). >>> >>> I like it for several reasons: >>> >>> >>> - The 'master' branch is always production quality released code >>> >>> - Small developments (trivial) can be undertaken directly in 'develop' >>> >>> - Larger developments can be undertaken in braches taken from 'develop', and then merged back into develop once complete... >>> >>> - ...testing of develop can then be undertaken before we make a new release number. >>> >>> See the information for more details. Does this seem sensible and agreeable to everyone? >>> >>> There are two other things I'd like us to work towards, again subject to some discussion between us: >>> >>> Using Tickets for Issues and New Features: >>> >>> - Using some ticketing system to record bugs to be fixed, new features to be developed, because we keep losing these; >>> >>> - Using those tickets as a way of grouping work into sprints towards a new release; >>> >>> - Could be trac, could be github, open to suggestions; >>> >>> A better means of testing the software rather than the hit and hope method we currently employ: >>> >>> - Open to suggestions here? >>> >>> - Probably starts with a list of manual tests to work through? >>> >>> - Possibly includes automation (Selenium?) >>> >>> - UnitTesting probably a very long term goal, might not even be possible? >>> >>> So my vision would be that we log tickets, we use that list of tickets as a big to-do list; we create a smaller current to-do list from it for the next release; we do the development a la gitflow; changes get pushed to develop and tested; new version released. It sounds good in theory at any rate, it will require a bit more discipline amongst us, but I think the benefits are worth it. I'd very much appreciate your views... >>> >>> Thanks, >>> >>> Julian >>> >>> >>> >>> >>> >>> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >>> >>> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >>> >>> >>> >>> >>> _______________________________________________ >>> Xerte-dev mailing list >>> Xerte-dev at lists.nottingham.ac.uk>> uk>>> uk>o >>> ttingham.ac.uk> >>> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >>> >>> >>> >>> -- >>> -- >>> >>> Tom Reijnders >>> TOR Informatica >>> Chopinlaan 27 >>> 5242HM Rosmalen >>> Tel: 073 5226191 >>> Fax: 073 5226196 >>> >>> >>> >>> >>> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >>> >>> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >>> >>> >>> Glasgow Caledonian University is a registered Scottish charity, >>> number >>> SC021474 >>> >>> Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. >>> http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name, >>> 6 >>> 219,en.html >>> >>> Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. >>> http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name, >>> 1 >>> 5691,en.html >>> >>> _______________________________________________ >>> Xerte-dev mailing list >>> Xerte-dev at lists.nottingham.ac.uk>> uk> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >>> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >>> >>> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> -- >>> >>> Tom Reijnders >>> TOR Informatica >>> Chopinlaan 27 >>> 5242HM Rosmalen >>> Tel: 073 5226191 >>> Fax: 073 5226196 >>> >>> >>> >>> >>> Glasgow Caledonian University is a registered Scottish charity, >>> number >>> SC021474 >>> >>> Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. >>> http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name, >>> 6 >>> 219,en.html >>> >>> Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. >>> http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name, >>> 1 >>> 5691,en.html >>> >>> _______________________________________________ >>> Xerte-dev mailing list >>> Xerte-dev at lists.nottingham.ac.uk >>> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >>> >>> _______________________________________________ >>> Xerte-dev mailing list >>> Xerte-dev at lists.nottingham.ac.uk >>> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >>> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >>> >>> This message has been checked for viruses but the contents of an >>> attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >>> >>> >>> >>> >> -- >> -- >> >> Tom Reijnders >> TOR Informatica >> Chopinlaan 27 >> 5242HM Rosmalen >> Tel: 073 5226191 >> Fax: 073 5226196 >> >> >> _______________________________________________ >> Xerte-dev mailing list >> Xerte-dev at lists.nottingham.ac.uk >> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev >> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. >> >> This message has been checked for viruses but the contents of an >> attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. >> >> >> >> > -- > -- > > Tom Reijnders > TOR Informatica > Chopinlaan 27 > 5242HM Rosmalen > Tel: 073 5226191 > Fax: 073 5226196 > > > _______________________________________________ > Xerte-dev mailing list > Xerte-dev at lists.nottingham.ac.uk > http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev > This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. > > This message has been checked for viruses but the contents of an attachment > may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. > > > > -- -- Tom Reijnders TOR Informatica Chopinlaan 27 5242HM Rosmalen Tel: 073 5226191 Fax: 073 5226196 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Julian.Tenney at nottingham.ac.uk Mon Sep 9 09:54:53 2013 From: Julian.Tenney at nottingham.ac.uk (Julian Tenney) Date: Mon, 9 Sep 2013 09:54:53 +0100 Subject: [Xerte-dev] Re: GitHub and Workflows In-Reply-To: <522D8B00.6000008@tor.nl> References: <12C67A1EEC419342AF5E59DA31562C3F0C80D193A9@EXCHANGE1.ad.nottingham.ac.uk>, <5229D526.1070208@tor.nl>, <12C67A1EEC419342AF5E59DA31562C3F0C80CE5DD3@EXCHANGE1.ad.nottingham.ac.uk> , <522B053C.1070504@tor.nl> <12C67A1EEC419342AF5E59DA31562C3F0C81E312D2@EXCHANGE1.ad.nottingham.ac.uk> <522D86E6.7070403@tor.nl> <12C67A1EEC419342AF5E59DA31562C3F0C81E312E8@EXCHANGE1.ad.nottingham.ac.uk> <522D88CD.4020304@tor.nl> <12C67A1EEC419342AF5E59DA31562C3F0C81E312F9@EXCHANGE1.ad.nottingham.ac.uk> <522D8B00.6000008@tor.nl> Message-ID: <12C67A1EEC419342AF5E59DA31562C3F0C81E3132A@EXCHANGE1.ad.nottingham.ac.uk> > The 'only' issue now, is to determine what warrants a hotfix :-) Quite. It's not every bug fix as I understand it. It's super-important stuff that really does need putting out there right now. A bit like a bug fix then! I tend to think that we will make life easier for ourselves if releases are frequent, and we don't attempt too much in each development cycle. Or, we just have a fixed cycle, say monthly, and release each time it ticks over? From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders Sent: 09 September 2013 09:47 To: For Xerte technical developers Subject: [Xerte-dev] Re: GitHub and Workflows Normally you wouldn't do maintenance (i.e. hotfixes) on a previous release, only the current. So normally we wouldn't do this, but in some cases when the latest release has new requirements on the server we could consider to do hotfixes on a previous release. I added that to the picture. It follows naturally from using hotfix branches. The 'only' issue now, is to determine what warrants a hotfix :-) Tom Op 9-9-2013 10:38, Julian Tenney schreef: Sorry, I missed that. That's fine - but what's the difference between that and a finished 'release'? -----Original Message----- From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders Sent: 09 September 2013 09:38 To: For Xerte technical developers Subject: [Xerte-dev] Re: GitHub and Workflows No I added something to the diagram (included in last e-mail) 'maintenance': See also attached email Tom Op 9-9-2013 10:30, Julian Tenney schreef: The release branches on the diagram? -----Original Message----- From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders Sent: 09 September 2013 09:29 To: For Xerte technical developers Subject: [Xerte-dev] Re: GitHub and Workflows Do you agree with inclusion of the maintenance branches? Op 9-9-2013 10:21, Julian Tenney schreef: That's how I understand it too: this is the model http://nvie.com/posts/a-successful-git-branching-model I think it pretty much covers everything. For me, I just need some time getting to know git on a practical basis... -----Original Message----- From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Smith, John Sent: 07 September 2013 12:07 To: For Xerte technical developers Subject: [Xerte-dev] Re: GitHub and Workflows Yes that looks great... I think that rhombus right in the middle (and the associated comment) with the faded arrows is a very important thing to take on board (for me anyway) - we make the changes in the appropriate branch and merge them back to develop (when appropriate), rather than what seemed to happen in SVN - we often worked in trunk and then copied the 'working' file into the v2 branch... We should document this process somewhere and refer to in until it is instilled in our brains. Regards, John Smith | Learning Technologist Room A251, Govan Mbeki Building | School of Health & Life Sciences | Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA ________________________________________ From: xerte-dev-bounces at lists.nottingham.ac.uk [xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders [reijnders at tor.nl] Sent: 07 September 2013 11:51 To: For Xerte technical developers Subject: [Xerte-dev] Re: GitHub and Workflows In that, I think, git will help us more than SVN was. For example, for hotfixes, we should REALLY try to refrain ourselves as much as possible. But suppose we have a mechanism in place on what warrants a hotfix, then we could do it as follows ( suggested by http://nvie.com/posts/a-successful-git-branching-model/): Whenever we identify a bug that needs to go in the latest release: 1. Create a branch of master called hotfix (with a nr, or minor version number) 2. Test, merge back into master (set tag on this fix, it will cause git describe to give us a good text for version.txt, and it is marked as a release in github) 3. merge into develop 4. NO MORE work on the hotfix branch, create a new branch for the next one. Then when we're ready to release (also as suggested by the same workflow) 1. Create a release branch, say 2.5 2. Test and fix, and once ready merge into master (set tag on this fix, it will cause git describe to give us a good text for version .txt, and it is marked as a release in github) 3. merge into develop 4. No more work on the release branch, create a new branch for the next one. The master would be the source of the stable release in the future, so from the next release master will be used for the stable release (what is now 2.0) Develop will be the source of the unstable (so it must not be too unstable, really new developments take place on feature branches) When we have an active release branch, there will be an extra zip for the release candidate. The only drawback so far is that if a release has so many new features that not anyone is able to move to the new release, we might need to maintain a previous release for some time (think of the need to go to for example php 5.4, or something similar) We can solve that by branching of master right before the release branch is merged into master and merge hotfixes in there as well (for as long as we deem necessary). So the full workflow will be active after the next release (because master currently, is not released). And you could treat the current 2.0 as a maintenance release now. The merging of hotfixes might be a bit more difficult to the maintenance release, but at least it's better than copying! [cid:part1.06000105.04050501 at tor.nl] Op 7-9-2013 10:02, Smith, John schreef: Morning all, The way that I see it we should be doing everyday development in the develop branch; I've merged Nikodems changes to Master back into develop (SourceTree wouldn't let me commit to develop while Master was 2 ahead!!). As Julian said in an earlier email, I will either do this directly for a single change or a gitflow branch off of develop for larger changes... Not really sure how the releases and hotfixes should work though... I think the thing we have to take most care with (which we didn't always do on Google) was the copying of files between branches/releases. Develop files will often have 'new features' with code that might be unstable. on Google SVN there were a few situations where bugfix changes were being made to the latest revision and then the latest revision file(s) in question were just copied straight over to the v2 branch, introducing any new features into an old release. This is the thing that worries me most, especially if we are having 'Stable' zips built straight from these branches... not really sure yet though how we mitigate this although you can mark chunks in SourceTree and only push those over... Regards, John Smith | Learning Technologist Room A251, Govan Mbeki Building | School of Health & Life Sciences | Glasgow Caledonian University Cowcaddens Road | Glasgow | G4 0BA ________________________________________ From: xerte-dev-bounces at lists.nottingham.ac.uk t s.nottingham.ac.uk> [xerte-dev-bounces at lists.nottingham.ac.uk s ts.nottingham.ac.uk>] On Behalf Of Julian Tenney [Julian.Tenney at nottingham.ac.uk t s.nottingham.ac.uk> [xerte-dev-bounces at lists.nottingham.ac.uk s ts.nottingham.ac.uk>] On Behalf Of Tom Reijnders [reijnders at tor.nl] Sent: 06 September 2013 14:14 To: For Xerte technical developers Subject: [Xerte-dev] Re: GitHub and Workflows Hi, I am in the process of modifying the build scripts to use github in stead of svn. And I noticed that Nicodem committed to master yesterday, so I've got a question given the workflow mentioned below: 1. Will we do hotfixes on released branches, i.e. on master and 2.0? 2. What shall we put up on the community website? What is the equivalent to the svn trunk. master or develop, i.e. what is the basis for 'unstable'? Regards, Tom Op 5-9-2013 15:39, Julian Tenney schreef: Hi, I think we've got the SVN migrated over to Git Hub with all the history, branches etc, which is great. We need to have some discussion about workflow, and I want to suggest gitflow as a good workflow to adopt. Information can be found here http://nvie.com/posts/a-successful-git-branching-model/ and elsewhere (here: https://www.atlassian.com/git/workflows for example). I like it for several reasons: - The 'master' branch is always production quality released code - Small developments (trivial) can be undertaken directly in 'develop' - Larger developments can be undertaken in braches taken from 'develop', and then merged back into develop once complete... - ...testing of develop can then be undertaken before we make a new release number. See the information for more details. Does this seem sensible and agreeable to everyone? There are two other things I'd like us to work towards, again subject to some discussion between us: Using Tickets for Issues and New Features: - Using some ticketing system to record bugs to be fixed, new features to be developed, because we keep losing these; - Using those tickets as a way of grouping work into sprints towards a new release; - Could be trac, could be github, open to suggestions; A better means of testing the software rather than the hit and hope method we currently employ: - Open to suggestions here? - Probably starts with a list of manual tests to work through? - Possibly includes automation (Selenium?) - UnitTesting probably a very long term goal, might not even be possible? So my vision would be that we log tickets, we use that list of tickets as a big to-do list; we create a smaller current to-do list from it for the next release; we do the development a la gitflow; changes get pushed to develop and tested; new version released. It sounds good in theory at any rate, it will require a bit more discipline amongst us, but I think the benefits are worth it. I'd very much appreciate your views... Thanks, Julian This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk uk> uk>o ttingham.ac.uk> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev -- -- Tom Reijnders TOR Informatica Chopinlaan 27 5242HM Rosmalen Tel: 073 5226191 Fax: 073 5226196 This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. Glasgow Caledonian University is a registered Scottish charity, number SC021474 Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name, 6 219,en.html Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name, 1 5691,en.html _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk uk> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. -- -- Tom Reijnders TOR Informatica Chopinlaan 27 5242HM Rosmalen Tel: 073 5226191 Fax: 073 5226196 Glasgow Caledonian University is a registered Scottish charity, number SC021474 Winner: Times Higher Education's Widening Participation Initiative of the Year 2009 and Herald Society's Education Initiative of the Year 2009. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name, 6 219,en.html Winner: Times Higher Education's Outstanding Support for Early Career Researchers of the Year 2010, GCU as a lead with Universities Scotland partners. http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name, 1 5691,en.html _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. -- -- Tom Reijnders TOR Informatica Chopinlaan 27 5242HM Rosmalen Tel: 073 5226191 Fax: 073 5226196 _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. -- -- Tom Reijnders TOR Informatica Chopinlaan 27 5242HM Rosmalen Tel: 073 5226191 Fax: 073 5226196 _______________________________________________ Xerte-dev mailing list Xerte-dev at lists.nottingham.ac.uk http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. -- -- Tom Reijnders TOR Informatica Chopinlaan 27 5242HM Rosmalen Tel: 073 5226191 Fax: 073 5226196 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Julian.Tenney at nottingham.ac.uk Thu Sep 19 08:40:28 2013 From: Julian.Tenney at nottingham.ac.uk (Julian Tenney) Date: Thu, 19 Sep 2013 08:40:28 +0100 Subject: [Xerte-dev] FW: [Forum XCW] Problem with Youtube