Tools for collaborative working
The real problem though is not the actual size of the limit , but the manual interaction that is required and the time delay until rejection. If the list could be changed to automatic rejection this would solve the problem . Sebastian Am 16.09.2011 19:21, schrieb Thomas Beale: > The 40kb limit was one of the sysadmin rules at UCL, and I happen to > agree with it (obviously, it could have been 50 or 100 or whatever, but > they use 40). I know it is sometimes annoying but it does prevent > massive attachments. Some years ago I was on probably 6 HL7 lists (they > have about 40) and there was not only no limit to size, but continual > cross-posting, with the result that 3Mb attachments were regularly sent, > and received 4 times! I for one don't want to go there again i think > today there is always an option for putting up some large file and just > emailing the link to it. > > If people want to up the actual current limit of 40kb to 70, 100 or so, > that is certainly doable, but I am not sure what problem it is solving. > > - thomas > > On 16/09/2011 17:42, Rong Chen wrote: >> Hi all, >> >> I am quite happy with the current infrastructure - mailing lists, >> issue tracking and SVN repositories. One thing I am missing for the >> java project is a build server, something like Apach Continuum that >> can check out the latest code, compile, run all the testcases, and >> publish reports and successful builds somewhere. >> >> Sebastian, It seems we have a manual step in the process of >> rejecting(or allowing) large mail. At least that's the case with the >> java list that I am monitoring. It will be convenient if the mail is >> just bounced automatically if it's too large. Perhaps there is a >> setting somewhere we could use with the current mailing list software. >> >> Cheers, >> Rong
Tools for collaborative working
Hi all, I am quite happy with the current infrastructure - mailing lists, issue tracking and SVN repositories. One thing I am missing for the java project is a build server, something like Apach Continuum that can check out the latest code, compile, run all the testcases, and publish reports and successful builds somewhere. Sebastian, It seems we have a manual step in the process of rejecting(or allowing) large mail. At least that's the case with the java list that I am monitoring. It will be convenient if the mail is just bounced automatically if it's too large. Perhaps there is a setting somewhere we could use with the current mailing list software. Cheers, Rong On 16 September 2011 17:17, Sebastian Garde wrote: > > > Am 16.09.2011 16:27, schrieb pablo pazos: >> Nabble is great for mailing lists. http://www.nabble.com/ (one thing >> that bothers me is the 40KB limit of the openEHR lists emails) > The 40kB limit is indeed a bit on the low side. > But it would not be so bad if the mailing list would immediately reject > your post and notify you. > Then you can shorten (usually just delete part of the email trail) and > send again - This is a bit annoying, but handable. > But the way it is currently, you don't know what is happening to your > email..and may not even realise that it is still in limbo...until you > get a rejection email a day later. > Even if you realise that it hasn't been delivered so far, you don't know > why and so you wait with resending it - often so long that the email > thread has moved on so much that you actually hope that your email will > be rejected :-) > > Sebastian > > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
Tools for collaborative working
The 40kb limit was one of the sysadmin rules at UCL, and I happen to agree with it (obviously, it could have been 50 or 100 or whatever, but they use 40). I know it is sometimes annoying but it does prevent massive attachments. Some years ago I was on probably 6 HL7 lists (they have about 40) and there was not only no limit to size, but continual cross-posting, with the result that 3Mb attachments were regularly sent, and received 4 times! I for one don't want to go there again i think today there is always an option for putting up some large file and just emailing the link to it. If people want to up the actual current limit of 40kb to 70, 100 or so, that is certainly doable, but I am not sure what problem it is solving. - thomas On 16/09/2011 17:42, Rong Chen wrote: > Hi all, > > I am quite happy with the current infrastructure - mailing lists, > issue tracking and SVN repositories. One thing I am missing for the > java project is a build server, something like Apach Continuum that > can check out the latest code, compile, run all the testcases, and > publish reports and successful builds somewhere. > > Sebastian, It seems we have a manual step in the process of > rejecting(or allowing) large mail. At least that's the case with the > java list that I am monitoring. It will be convenient if the mail is > just bounced automatically if it's too large. Perhaps there is a > setting somewhere we could use with the current mailing list software. > > Cheers, > Rong >
Tools for collaborative working
On 16/09/2011 15:27, pablo pazos wrote: > I agree with you both: we need to get things done and find reliable > tools up to the task. > > Many opensource projects use cloud based services, and don't need/try > to make everything open source at the infrastructure level. > > Jira is great for issue reporting and bug tracking. > http://www.atlassian.com/software/jira/ > Nabble is great for mailing lists. http://www.nabble.com/ (one thing > that bothers me is the 40KB limit of the openEHR lists emails) > SVN or Git area great for version control. BTW I wasn't trying to make any ideological statements, I have just fought with Bugzilla and some other bug tracking solutions in the past whose names I forget now, and they just got in the way. Likewise, in the days that CVS was the only open source versioning system, it was just not a choice from my point of view - the commercial products were miles ahead if you wanted proper change sets and so on (Torvalds more or less still says that SVN is pretty hopeless, and in some ways he is right, depending on what your requirements are). This has all changed as we now know. And I for one don't want to go back to fighting tools! In terms of need - one need we do have is to get off the UCL servers where all the infrastructure has to be maintained by hand and get on the cloud where it is maintained and backed up server-side. - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110916/f455e062/attachment.html>
Tools for collaborative working
at are in early >> development (certainly my experience with most free issue tracking >> systems - maybe the Git one is better). >> >> - thomas >> >> On 16/09/2011 09:29, Ian McNicoll wrote: >>> Hi Tim, >>> >>> >>> Can you give some examples of good open-source tools in this area? >>> >>> Ian >>> >>> Dr Ian McNicoll >>> office +44 (0)1536 414 994 >>> fax +44 (0)1536 516317 >>> mobile +44 (0)775 209 7859 >>> skype ianmcnicoll >>> ian.mcnicoll at oceaninformatics.com >>> >>> Clinical Modelling Consultant, Ocean Informatics, UK >>> openEHR Clinical Knowledge Editorwww.openehr.org/knowledge >>> Honorary Senior Research Associate, CHIME, UCL >>> BCS Primary Health Carewww.phcsg.org >>> >>> >>> >>> >>> On 16 September 2011 00:09, Timothy Cook >>> wrote: >>>> Well, maybe you should consider real open source tools. > > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110916/7f954e91/attachment.html>
Tools for collaborative working
Am 16.09.2011 16:27, schrieb pablo pazos: > Nabble is great for mailing lists. http://www.nabble.com/ (one thing > that bothers me is the 40KB limit of the openEHR lists emails) The 40kB limit is indeed a bit on the low side. But it would not be so bad if the mailing list would immediately reject your post and notify you. Then you can shorten (usually just delete part of the email trail) and send again - This is a bit annoying, but handable. But the way it is currently, you don't know what is happening to your email..and may not even realise that it is still in limbo...until you get a rejection email a day later. Even if you realise that it hasn't been delivered so far, you don't know why and so you wait with resending it - often so long that the email thread has moved on so much that you actually hope that your email will be rejected :-) Sebastian
Tools for collaborative working
Hi Bert, I have participated in a lot of open source projects, for a long time, that make use of software in the cloud as infrastructure. These projects are "long lasting" and because the infrastructure is in the cloud, we as users doesn't have to bother with backward compatibility issues. Cheers, Pablo. I wouldn't trust software which is not open source. You cannot judge if it does its job well, especcially in long lasting use, like f.e. a database, how do you know if it still works if your table reach the million records and the table is 127 fields wide with on the second field a VARCHAR (127), I have seen many strange things in software products. What happens if a vendor gives up, or isn't interested anymore in the specific product, or is bankrupt What happens if a vendor decides to break backwards compatibility, or he is just clumsy? -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110916/41a43f2f/attachment.html>
Tools for collaborative working
It would be nice to know if an email is sent or not with an instant notification, instead of waiting a random amount of time to receive a notice (if the notice ever comes :). -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos > Date: Fri, 16 Sep 2011 18:21:59 +0100 > From: thomas.beale at oceaninformatics.com > To: openehr-technical at openehr.org > Subject: Re: Tools for collaborative working > > > The 40kb limit was one of the sysadmin rules at UCL, and I happen to > agree with it (obviously, it could have been 50 or 100 or whatever, but > they use 40). I know it is sometimes annoying but it does prevent > massive attachments. Some years ago I was on probably 6 HL7 lists (they > have about 40) and there was not only no limit to size, but continual > cross-posting, with the result that 3Mb attachments were regularly sent, > and received 4 times! I for one don't want to go there again i think > today there is always an option for putting up some large file and just > emailing the link to it. > > If people want to up the actual current limit of 40kb to 70, 100 or so, > that is certainly doable, but I am not sure what problem it is solving. > > - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110916/d1098031/attachment.html>
Tools for collaborative working
I agree with you Thomas, Whether these tools are open source or just free as in beer (for openEHR) - doesn't matter too much...for me it is far more important that the tool does its job. If there are open source tools that really do the job - finevery fine indeed, but if not, I for one, do not want to use tools just because they are open source if we can have better ones that are just free. Not sure where this discussion stems from, but I am reasonably happy with the current Jira, Confluence and SVN approach and do not think that changing this is a huge priority. (It's not like there isn't anything on the foundation's priority list at the moment :-) ) But I may have missed the reasoning why openEHR's current tooling is not sufficient in the first place? Sebastian Am 16.09.2011 14:22, schrieb Thomas Beale: > > For openEHR, Atlassian hosted solution JiraStudio (not open source) > may be worth considering since it solves the problem of physical > hosting without (in theory) causing much disruption, since all the > tools are the same - Confluence, Jira (particularly) and SVN. > > Atlassian bitbucket (completely separate from Atlassian mainstream > hosted tools) uses Mercurial, a better DVCS than SVN, but its issue > tracking etc is minimal. > > For the price of more disruption, Github would be one place to go, and > it is probably the best DVCS there is (it was designed based on the > BitKeeper solution we used to use in openEHR). How good the project > tracking tools are I don't know, but they are claimed to be good. The > main thing that is needed is integrated DVCS, project / issue tracking > (with configurable workflows, security etc), wiki, mailing lists and > continuous build server. > > Whether having everything open source is fundamentally important is > debatable - in principle it is nicer, but I am more interested in > getting work done efficiently, not battling tools that are in early > development (certainly my experience with most free issue tracking > systems - maybe the Git one is better). > > - thomas > > On 16/09/2011 09:29, Ian McNicoll wrote: >> Hi Tim, >> >> >> Can you give some examples of good open-source tools in this area? >> >> Ian >> >> Dr Ian McNicoll >> office +44 (0)1536 414 994 >> fax +44 (0)1536 516317 >> mobile +44 (0)775 209 7859 >> skype ianmcnicoll >> ian.mcnicoll at oceaninformatics.com >> >> Clinical Modelling Consultant, Ocean Informatics, UK >> openEHR Clinical Knowledge Editorwww.openehr.org/knowledge >> Honorary Senior Research Associate, CHIME, UCL >> BCS Primary Health Carewww.phcsg.org >> >> >> >> >> On 16 September 2011 00:09, Timothy Cook >> wrote: >>> Well, maybe you should consider real open source tools. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110916/85fae7e0/attachment.html>
Tools for collaborative working
This would be great! > One thing I am missing for the > java project is a build server, something like Apach Continuum that > can check out the latest code, compile, run all the testcases, and > publish reports and successful builds somewhere. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110916/bd4e6d9d/attachment.html>
Tools for collaborative working
For openEHR, Atlassian hosted solution JiraStudio (not open source) may be worth considering since it solves the problem of physical hosting without (in theory) causing much disruption, since all the tools are the same - Confluence, Jira (particularly) and SVN. Atlassian bitbucket (completely separate from Atlassian mainstream hosted tools) uses Mercurial, a better DVCS than SVN, but its issue tracking etc is minimal. For the price of more disruption, Github would be one place to go, and it is probably the best DVCS there is (it was designed based on the BitKeeper solution we used to use in openEHR). How good the project tracking tools are I don't know, but they are claimed to be good. The main thing that is needed is integrated DVCS, project / issue tracking (with configurable workflows, security etc), wiki, mailing lists and continuous build server. Whether having everything open source is fundamentally important is debatable - in principle it is nicer, but I am more interested in getting work done efficiently, not battling tools that are in early development (certainly my experience with most free issue tracking systems - maybe the Git one is better). - thomas On 16/09/2011 09:29, Ian McNicoll wrote: > Hi Tim, > > > Can you give some examples of good open-source tools in this area? > > Ian > > Dr Ian McNicoll > office +44 (0)1536 414 994 > fax +44 (0)1536 516317 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian.mcnicoll at oceaninformatics.com > > Clinical Modelling Consultant, Ocean Informatics, UK > openEHR Clinical Knowledge Editor www.openehr.org/knowledge > Honorary Senior Research Associate, CHIME, UCL > BCS Primary Health Care www.phcsg.org > > > > > On 16 September 2011 00:09, Timothy Cook > wrote: >> Well, maybe you should consider real open source tools. >> >> >> >> On Thu, Sep 15, 2011 at 16:34, Sam Heard >> wrote: >>> Dear All >>> >>> The Board is interested in using tools for collaborative online working and >>> keeping these coordinated. We already have Jira and Confluence from >>> Atlassian. These are working well as far as I am aware. >>> >>> I would like to propose that we consider going to third parties for: >>> >>> Source code repository >>> - Bitbucket from Atlassian (Mercurial) >>> - ? other options >>> >>> Agile development >>> - Pivot Tracker (I have applied for 4 accounts for free - openEHR >>> Specifications, openEHR Software, openEHR Clinical Models, openEHR >>> Localisation) Projects would then be created under each of these by the >>> Members if we chose to use this tool. >>> - ? other options >>> >>> Please discuss these issues. I have asked a couple of the less technical >>> people to review Pivot Tracker to consider its role in tasks other than >>> software development. >>> >>> We will obviously be guided totally by the lists on these matters - the >>> point being that we really want to use one tool for one purpose across >>> different programs if possible or appropriate. Even if the tool turns out >>> not to be the best one at times, the uniformity will be very important going >>> forward. >>> >>> Cheers, Sam >>> >>> >>> Dr Sam Heard >>> Chief Executive Officer >>> Director, openEHR Foundation >>> Senior Visiting Research Fellow, University College London >>> >>> 214 Victoria Avenue >>> Chatswood, NSW, 2067 >>> Phone: +61 2 9415 4994 >>> Mobile: +61 4 1783 8808 >>> 21 Chester Cres >>> London E8 2PH >>> Phone: +44 20 7249 7085 >>> Mobile: +44 75 7549 7937 >>> >>> >>> >>> >>> ___ >>> openEHR-technical mailing list >>> openEHR-technical at openehr.org >>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >>> >> >> >> -- >> >> Timothy Cook, MSc >> LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook >> Skype ID == timothy.cook >> Academic.Edu Profile: http://uff.academia.edu/TimothyCook >> >> ___ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-tech
Tools for collaborative working
I agree with you both: we need to get things done and find reliable tools up to the task. Many opensource projects use cloud based services, and don't need/try to make everything open source at the infrastructure level. Jira is great for issue reporting and bug tracking. http://www.atlassian.com/software/jira/ Nabble is great for mailing lists. http://www.nabble.com/ (one thing that bothers me is the 40KB limit of the openEHR lists emails) SVN or Git area great for version control. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Fri, 16 Sep 2011 14:51:33 +0200 From: sebastian.ga...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: Tools for collaborative working I agree with you Thomas, Whether these tools are open source or just free as in beer (for openEHR) - doesn't matter too much...for me it is far more important that the tool does its job. If there are open source tools that really do the job - finevery fine indeed, but if not, I for one, do not want to use tools just because they are open source if we can have better ones that are just free. Not sure where this discussion stems from, but I am reasonably happy with the current Jira, Confluence and SVN approach and do not think that changing this is a huge priority. (It's not like there isn't anything on the foundation's priority list at the moment :-) ) But I may have missed the reasoning why openEHR's current tooling is not sufficient in the first place? Sebastian Am 16.09.2011 14:22, schrieb Thomas Beale: For openEHR, Atlassian hosted solution JiraStudio (not open source) may be worth considering since it solves the problem of physical hosting without (in theory) causing much disruption, since all the tools are the same - Confluence, Jira (particularly) and SVN. Atlassian bitbucket (completely separate from Atlassian mainstream hosted tools) uses Mercurial, a better DVCS than SVN, but its issue tracking etc is minimal. For the price of more disruption, Github would be one place to go, and it is probably the best DVCS there is (it was designed based on the BitKeeper solution we used to use in openEHR). How good the project tracking tools are I don't know, but they are claimed to be good. The main thing that is needed is integrated DVCS, project / issue tracking (with configurable workflows, security etc), wiki, mailing lists and continuous build server. Whether having everything open source is fundamentally important is debatable - in principle it is nicer, but I am more interested in getting work done efficiently, not battling tools that are in early development (certainly my experience with most free issue tracking systems - maybe the Git one is better). - thomas On 16/09/2011 09:29, Ian McNicoll wrote: Hi Tim, Can you give some examples of good open-source tools in this area? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org On 16 September 2011 00:09, Timothy Cook wrote: Well, maybe you should consider real open source tools. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110916/859386ea/attachment.html>
Tools for collaborative working
On 16/09/2011 01:09, Timothy Cook wrote: > Well, maybe you should consider real open source tools. > does git http://git-scm.com/ have any place in the discussion? As a version control/repository system it has the advantage that it's designed to combat bi-trot - while being nicely distributive. github - https://github.com/plans The git repository service for many open-source project (including linux) is _not_ free (as in beer) though.
Tools for collaborative working
Hi Tim, Can you give some examples of good open-source tools in this area? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care ?www.phcsg.org On 16 September 2011 00:09, Timothy Cook wrote: > Well, maybe you should consider real open source tools. > > > > On Thu, Sep 15, 2011 at 16:34, Sam Heard > wrote: >> Dear All >> >> The Board is interested in using tools for collaborative online working and >> keeping these coordinated. We already have Jira and Confluence from >> Atlassian. These are working well as far as I am aware. >> >> I would like to propose that we consider going to third parties for: >> >> Source code repository >> ? ? ? ?- Bitbucket from Atlassian (Mercurial) >> ? ? ?- ? other options >> >> Agile development >> ? ? ? ?- Pivot Tracker (I have applied for 4 accounts for free - openEHR >> Specifications, openEHR Software, openEHR Clinical Models, openEHR >> Localisation) Projects would then be created under each of these by the >> Members if we chose to use this tool. >> ? ? ? ?- ? other options >> >> Please discuss these issues. I have asked a couple of the less technical >> people to review Pivot Tracker to consider its role in tasks other than >> software development. >> >> We will obviously be guided totally by the lists on these matters - the >> point being that we really want to use one tool for one purpose across >> different programs if possible or appropriate. Even if the tool turns out >> not to be the best one at times, the uniformity will be very important going >> forward. >> >> Cheers, Sam >> >> >> Dr Sam Heard >> Chief Executive Officer >> Director, openEHR Foundation >> Senior Visiting Research Fellow, University College London >> >> 214 Victoria Avenue >> Chatswood, NSW, 2067 >> Phone: +61 2 9415 4994 >> Mobile: +61 4 1783 8808 >> 21 Chester Cres >> London E8 2PH >> Phone: +44 20 7249 7085 >> Mobile: +44 75 7549 7937 >> >> >> >> >> ___ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> > > > > -- > > Timothy Cook, MSc > LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook > Skype ID == timothy.cook > Academic.Edu Profile: http://uff.academia.edu/TimothyCook > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
Tools for collaborative working
Dear All The Board is interested in using tools for collaborative online working and keeping these coordinated. We already have Jira and Confluence from Atlassian. These are working well as far as I am aware. I would like to propose that we consider going to third parties for: Source code repository - Bitbucket from Atlassian (Mercurial) - ? other options Agile development - Pivot Tracker (I have applied for 4 accounts for free - openEHR Specifications, openEHR Software, openEHR Clinical Models, openEHR Localisation) Projects would then be created under each of these by the Members if we chose to use this tool. - ? other options Please discuss these issues. I have asked a couple of the less technical people to review Pivot Tracker to consider its role in tasks other than software development. We will obviously be guided totally by the lists on these matters - the point being that we really want to use one tool for one purpose across different programs if possible or appropriate. Even if the tool turns out not to be the best one at times, the uniformity will be very important going forward. Cheers, Sam Dr Sam Heard Chief Executive Officer Director, openEHR Foundation Senior Visiting Research Fellow, University College London 214 Victoria Avenue Chatswood, NSW, 2067 Phone: +61 2 9415 4994 Mobile: +61 4 1783 8808 21 Chester Cres London E8 2PH Phone: +44 20 7249 7085 Mobile: +44 75 7549 7937
