Unterhaltung mit #deegree

(14:31:48) Das Thema für #deegree ist: Welcome to deegree, an OSGeo project. Visit the main project page at http://deegree.org and our wiki at http://wiki.deegree.org with lots of extra info. Check out a running system at http://demo.deegree.org and follow us on twitter @deegree_org.
(14:32:47) mrsnyder: hi everybody!
(14:32:51) copierrj: hi
(14:32:52) mrsnyder: shall we begin?
(14:32:57) ndrs`: hi
(14:33:05) jwilden: Hi
(14:33:09) jwilden: I'd say so
(14:33:26) copierrj: ok
(14:33:38) mrsnyder: http://wiki.deegree.org/deegreeWiki/TmcMeeting/TmcMeeting20130122
(14:33:52) mrsnyder: anything missing from the agenda?
(14:34:09) copierrj: not for me
(14:34:12) tfr42 [8bbf3e9f@gateway/web/freenode/ip.139.191.62.159] hat den Raum betreten.
(14:34:17) tfr42: Hello
(14:34:29) mrsnyder: hi
(14:34:32) copierrj: hi
(14:34:39) jwilden: Hi
(14:34:41) mrsnyder: first item: pull requests.
(14:34:47) mrsnyder: https://github.com/deegree/deegree3/pulls
(14:35:20) mrsnyder: first one: https://github.com/deegree/deegree3/pull/16
(14:35:35) copierrj: +1
(14:35:40) ndrs`: +1
(14:35:50) mrsnyder: 0 (can't really tell)
(14:36:03) jwilden: 0 (same)
(14:36:13) tfr42: 0
(14:36:31) ndrs`: merged.
(14:36:37) mrsnyder: https://github.com/deegree/deegree3/pull/23
(14:36:38) copierrj: nice!
(14:36:52) ndrs`: +1
(14:36:54) mrsnyder: +1
(14:37:16) copierrj: 0
(14:37:19) jwilden: +1
(14:37:41) tfr42: +1
(14:38:05) ndrs`: merged.
(14:38:25) mrsnyder: https://github.com/deegree/deegree3/pull/24
(14:38:35) ndrs`: +1
(14:38:41) tfr42: +1
(14:38:42) copierrj: +1
(14:38:51) jwilden: +1
(14:38:52) mrsnyder: +1
(14:39:01) ndrs`: merged.
(14:39:17) mrsnyder: https://github.com/deegree/deegree3/pull/25
(14:39:22) copierrj: +1
(14:39:36) ndrs`: +1
(14:39:40) mrsnyder: +1
(14:39:56) jwilden: +1
(14:40:24) tfr42: +1
(14:40:38) ndrs`: merged.
(14:40:44) mrsnyder: https://github.com/deegree/deegree3/pull/26
(14:40:58) ndrs`: +1
(14:41:01) copierrj: +1
(14:41:11) jwilden: 0
(14:41:22) mrsnyder: +1 (but i think we should consider to protect access to the generic client)
(14:41:39) copierrj: agreed, the safer the better
(14:42:31) tfr42: 0
(14:42:40) ndrs`: merged.
(14:42:41) mrsnyder: https://github.com/deegree/deegree3/pull/27
(14:42:52) ndrs`: +1
(14:42:53) copierrj: +1
(14:43:05) copierrj: (don't like dependencies)
(14:43:11) ndrs`: everyone good if I remove the old parser stuff first?
(14:43:26) jwilden: yes
(14:43:27) mrsnyder: yep (+1)
(14:43:28) copierrj: ok
(14:43:44) mrsnyder: ddl
(14:44:04) tfr42: yes please
(14:44:17) ndrs`: ok, I'll merge it once I removed those
(14:44:45) mrsnyder: https://github.com/deegree/deegree3/pull/31
(14:44:53) ndrs`: +1
(14:44:59) mrsnyder: added tests, btw
(14:45:02) jwilden: 0
(14:45:08) copierrj: +1
(14:46:00) tfr42: +1
(14:46:13) mrsnyder: +1
(14:46:17) ndrs`: merged.
(14:46:27) mrsnyder: https://github.com/deegree/deegree3/pull/32
(14:46:32) copierrj: +1
(14:46:41) copierrj: BTW: root cause is in XMLAdapter
(14:46:49) copierrj: didn't have the time to fix that
(14:47:01) mrsnyder: +1
(14:47:01) jwilden: So the test still fails?
(14:47:18) copierrj: no, the test doesn't fail anymore
(14:47:20) ndrs`: +1
(14:47:26) jwilden: then: +1
(14:48:20) tfr42: Ok, in those cases it would be great to link to the succesfull run of the build job on jenkins
(14:48:31) tfr42: trust you, that tests are OK
(14:48:32) tfr42: +1
(14:48:44) copierrj: jenkins never complaint
(14:48:50) copierrj: = windows issue
(14:48:53) mrsnyder: how should it?
(14:48:58) ndrs`: merged.
(14:49:10) mrsnyder: https://github.com/deegree/deegree3/pull/33
(14:49:27) ndrs`: +1
(14:49:30) jwilden: +1
(14:49:39) tfr42: +1
(14:49:51) mrsnyder: 0
(14:49:54) copierrj: did everyone/anyone really look at this one?
(14:50:06) ndrs`: yes, I had a look
(14:50:16) copierrj: ok then +1
(14:50:29) ndrs`: merged.
(14:50:36) tfr42: Well, again there is the unit test missing
(14:50:48) copierrj: neary impossible to unittest
(14:50:52) copierrj: nearly
(14:50:59) mrsnyder: https://github.com/deegree/deegree3/pull/34
(14:51:04) tfr42: I strongly recommend, that with each change there is a NEW unit test proofing the expected behaviour
(14:51:23) copierrj: how would you propose to do that in this case?
(14:52:41) mrsnyder: of course, you could turn this line into a method that you could test...
(14:52:54) ndrs`: well, maybe we should skip the philosophical discussions right now...
(14:53:05) tfr42: our use mock objects to verify the expected behaviour
(14:53:11) tfr42: right move
(14:53:12) tfr42: on
(14:53:22) mrsnyder: https://github.com/deegree/deegree3/pull/34
(14:53:26) jwilden: +1
(14:53:26) ndrs`: +1
(14:53:30) copierrj: +1
(14:53:32) tfr42: +1
(14:53:36) mrsnyder: +1
(14:53:43) ndrs`: merged.
(14:53:55) mrsnyder: nice, thank you.
(14:54:14) mrsnyder: Next item: Perform pre-release builds after every TMC meeting/GitHub pull session
(14:54:25) copierrj: would be very nice to have
(14:54:26) mrsnyder: this is my proposal, but i think some of you like it
(14:54:28) mrsnyder: +1
(14:54:33) tfr42: +1
(14:54:34) ndrs`: +1
(14:54:40) jwilden: I think it's a good idea
(14:54:42) jwilden: +1
(14:54:45) copierrj: +1
(14:55:01) mrsnyder: great, thank you. is this an automatic task for johannes then?
(14:55:35) mrsnyder: of course, we should help you to streamline the process
(14:55:43) mrsnyder: "one click is enough"
(14:55:59) mrsnyder: (and writing the email to deegree-users=
(14:56:01) mrsnyder: )
(14:56:07) ndrs`: well, updates of the demos would be easy enough to automate
(14:56:14) jwilden: I think so,too
(14:56:16) ndrs`: updating the web page/links would be more difficult
(14:56:56) mrsnyder: @johannes: so you're going to perform the pre13 release today, right?
(14:57:24) jwilden: I can start the job, yes. I don't know if there is enough time to install the demos
(14:57:44) jwilden: As there is still a lot to do
(14:57:46) mrsnyder: fair enough. tell us if you need help?
(14:57:50) mrsnyder: !
(14:58:06) mrsnyder: (to automate things=
(14:58:07) mrsnyder: )
(14:58:10) jwilden: Ok, I will do it on skype later on
(14:58:23) mrsnyder: next item: Continuous Integration for open pull requests
(14:58:35) mrsnyder: Reijer, do you take over?
(14:58:39) copierrj: yes,
(14:59:03) copierrj: currently it's very time consuming to verify that things are not going to break
(14:59:18) copierrj: why not having jenkins to do the hard work for us
(14:59:46) copierrj: apparently other people though about this too
(15:00:02) ndrs`: we at OL have our own Jenkins jobs. We periodically merge our pull request branches into our master, and have Jenkins run on that
(15:00:12) tfr42: so, you propose to have a Job per pull request?
(15:00:25) copierrj: would be nice
(15:00:40) jwilden: So the idea is to create a branch from the latest deegree3 release, add the new feature to this branch and create a job including integration tests for each of those banches?
(15:00:56) copierrj: indeed
(15:01:04) jwilden: I like the idea
(15:01:06) ndrs`: well, Jenkins can run on multiple branches
(15:01:24) jwilden: Nice
(15:01:25) ndrs`: which works especially well if you poll from scm
(15:01:28) mrsnyder: my question is: is the official jenkins the right instance to do that?!
(15:01:40) jwilden: @Markus: I think it is
(15:01:50) copierrj: me2
(15:02:00) ndrs`: well, I imagine that that would mean a lot of builds
(15:02:18) copierrj: for security reasons, doing it for all pull requests automatically is probably not a good idea though
(15:02:20) ndrs`: since building with IT tests runs about 40-50 Minutes, that might be too many builds
(15:02:21) mrsnyder: i find it very slow and it used to run out of disk space constantly in the past
(15:02:23) jwilden: But it is the only way to verify that IT-tests don't fail
(15:02:41) ndrs`: not if everyone has their own Jenkins
(15:03:01) copierrj: not everyone has their own Jenkins unfortunately
(15:03:06) copierrj: (we don't_
(15:03:18) copierrj: yet
(15:03:20) mrsnyder: but i see a definite benefit: we could link to the job in the pull request
(15:03:27) mrsnyder: i like that
(15:03:30) jwilden: Thats the point
(15:04:18) mrsnyder: probably we need a dedicated maintainer/admin for the jenkins machine first
(15:04:30) mrsnyder: someone who feels responsible
(15:05:42) mrsnyder: anybody shares my feeling here?
(15:05:50) jwilden: I do
(15:05:50) mrsnyder: or am i completely mistaken?
(15:05:54) ndrs`: I'm not sure if it's worth it. Seeing that many pull requests only live for 2 Weeks
(15:06:09) mrsnyder: shall we vote?
(15:06:16) jwilden: Yes
(15:06:22) ndrs`: perhaps Reijer can get access to the official Jenkins?
(15:06:34) ndrs`: that way he can just use it as long as they don't have their own
(15:06:38) mrsnyder: one moment.
(15:06:50) ndrs`: not sure we need an official policy here
(15:07:15) mrsnyder: the proposal is "always use the official jenkins for building the branch related to a pull request"
(15:07:29) jwilden: +1
(15:07:32) copierrj: +1
(15:07:44) ndrs`: -1
(15:07:50) mrsnyder: 0 (not sure the machine can handle that)
(15:08:12) tfr42: -1
(15:08:24) mrsnyder: ok: total: 0
(15:08:30) mrsnyder: :-)
(15:08:35) copierrj: hmm
(15:08:36) ndrs`: so what's the policy now :-)
(15:08:39) jwilden: They only have to run once, so maybe one job per pull-request is better.
(15:08:50) mrsnyder: ??
(15:08:58) ndrs`: wasn't that the proposal?
(15:09:08) mrsnyder: torsten: what is your reason for the -1
(15:09:16) mrsnyder: and andreas?
(15:09:17) copierrj: well technically every combination should be tested to be absolutely sure of no failure
(15:09:26) jwilden: There was the idea of joining them in one job with multiple branches
(15:09:46) tfr42: don't see a chance to setup a job automatically for each pull request
(15:09:50) copierrj: ok, but than you don't know what causes the failure
(15:09:53) ndrs`: if eg. we as OL have merged our stuff into our master, and can show that there are no failures, surely merging all of those pull reqs. is fine
(15:10:06) tfr42: if this could be fully automatized then I would vote +1
(15:10:32) copierrj: I think we have to investigate into the technically feasibility further
(15:10:33) mrsnyder: @tfr42: no, but the manual work should be < 1 min. copy the deegree3 job, adapt branch (turn off deploy)
(15:10:56) copierrj: (I don't know much about jenkins yet)
(15:11:24) tfr42: And who will do this? Shall we open jenkins to the public so that every person who offers a pull request can do this?
(15:11:34) tfr42: Or is this a task to the jenkins admin?
(15:11:40) mrsnyder: that's a good question...
(15:11:57) copierrj: not for everyone obviously
(15:12:01) copierrj: way to dangerous!
(15:12:05) ndrs`: tfr42: that's indeed a good question. I'm personally fine with giving Reijer/all TMC members access to the Jenkins
(15:12:29) mrsnyder: i agree: all tmc members should have access to the official jenkins instance.
(15:12:40) jwilden: Agreed
(15:12:54) tfr42: ok
(15:13:02) mrsnyder: there's even a jenkins plugin that allows github project owners to log in
(15:13:13) copierrj: cool
(15:13:39) tfr42: so the TMC will be in charge to setup the jobs?
(15:13:52) tfr42: and not the person who offers the pull request?
(15:13:55) mrsnyder: yes.
(15:14:03) ndrs`: I'm still not in favour of having so many jobs
(15:14:06) tfr42: How do we map a pull request to a TMC member?
(15:14:17) mrsnyder: (if it is a tmc member, he should set it up himself)
(15:14:30) tfr42: assumed that the pull requests comes from a non-tmc-member
(15:15:04) ndrs`: If someone makes a pull requests, and convinces me that the tests don't fail, I can just as well believe him
(15:15:11) ndrs`: and if he lied, roll back the merge :-)
(15:15:41) ndrs`: after all, we review the requests during this meeting (and possibly before)
(15:16:10) mrsnyder: @ndrs: does it hurt to have a prove that the tests work?
(15:16:31) mrsnyder: generally, i consider this a good thing
(15:16:52) ndrs`: it doesn't hurt of course, but if someone *has* to prove it, it makes contributing hard
(15:17:12) mrsnyder: well, the tmc is going to assist here.
(15:18:05) ndrs`: well, we can vote again. We don't have to have an unanimous vote...
(15:18:25) mrsnyder: 0 (still think we need a dedicated admin first)
(15:18:35) tfr42: yep
(15:18:37) ndrs`: -1
(15:18:41) jwilden: Agreed
(15:18:46) copierrj: +1 (we do indeed need an admin)
(15:19:01) mrsnyder: well, any volunteers?
(15:19:03) mrsnyder: reijer?
(15:19:18) copierrj: I've to discuss this there at IDgis
(15:19:21) copierrj: it's on my list
(15:19:39) jwilden: Ok, then postpone this decision to the next meeting?
(15:19:41) mrsnyder: ok, shall we postpone this then?
(15:19:42) mrsnyder: yep
(15:19:44) copierrj: =1
(15:19:45) copierrj: +1
(15:19:54) jwilden: +1
(15:20:10) ndrs`: +1
(15:20:25) mrsnyder: Next: How to properly perform/maintain custom deegree3 builds?
(15:20:28) mrsnyder: Reijer?
(15:21:05) copierrj: We've used 3.2-pre8 as a cross over between a maintenance release and a specific project branch
(15:21:15) copierrj: probably not a good idea
(15:21:43) copierrj: not directly a TMS/deegree issue perhaps
(15:21:59) ndrs`: well, if you have project specific changes you can keep them in a separate branch, which would be based on 3.2-pre8
(15:22:10) copierrj: which repo
(15:22:22) ndrs`: then you can merge 3.2-pre8 changes into your project specific branch
(15:22:32) mrsnyder: imho, we should only maintain non-pre releases in the deegree repo
(15:22:36) ndrs`: well, I'd imagine an IDGis repo or your personal repo
(15:23:17) mrsnyder: a company can always decide to have a branch based on a pre-version in their own githib repo,
(15:23:18) copierrj: possible
(15:23:22) copierrj: possibly
(15:23:47) mrsnyder: and pull changes from the official repo
(15:24:01) copierrj: hmm, I'm going to place this one on my list too
(15:24:06) copierrj: to be discussed internally
(15:24:25) mrsnyder: fine. so no action!?
(15:24:29) mrsnyder: here
(15:24:33) jwilden: Nope
(15:24:34) copierrj: not yet
(15:24:45) mrsnyder: Next item: PSC questions on JIRA
(15:24:54) mrsnyder: http://wiki.deegree.org/deegreeWiki/TmcMeeting/TmcMeeting20130122#PSC_questions_on_JIRA
(15:25:35) mrsnyder: i have to admit that i feel a bit exhausted on this topic...
(15:25:50) copierrj: we could still decide to postpone JIRA and stick with GitHub tracker for a while
(15:25:55) tfr42: my task!
(15:26:02) mrsnyder: :-)
(15:26:11) tfr42: no, github tracker is not an option.
(15:26:13) ndrs`: tfr42: so you'll answer this to the PSC?
(15:26:19) tfr42: yes
(15:26:50) mrsnyder: very well. i will update the corresponding ticket.
(15:27:16) tfr42: related question: who is admin of the trac instance at tracker.deegree.org?
(15:27:26) mrsnyder: this would be jeronimo, AFAIK
(15:27:35) tfr42: he is not tmc member
(15:27:47) tfr42: can this task move to a tmc member please
(15:27:56) mrsnyder: +1
(15:28:08) jwilden: +1
(15:28:12) jwilden: any volunteers?
(15:28:44) tfr42: well, I would do a part but I do see also the role of the release manager involved to prepare releases in the issue tracker
(15:29:23) mrsnyder: this sounds professional, indeed
(15:29:39) ndrs`: so why don't you two share it? (jwilden and tfr42)
(15:29:43) jwilden: ok
(15:29:55) tfr42: yes, that's a good proposal
(15:30:10) tfr42: votes please
(15:30:11) mrsnyder: +1
(15:30:13) jwilden: +1
(15:30:13) ndrs`: +1
(15:30:16) copierrj: +1
(15:30:23) tfr42: +1
(15:30:55) mrsnyder: fine.
(15:31:02) mrsnyder: shall we call it a day?
(15:31:16) ndrs`: yep
(15:31:17) jwilden: Yep, nothing else to add today
(15:31:21) copierrj: yes
(15:31:24) tfr42: yes
(15:31:30) mrsnyder: well, thank you guys
(15:31:38) tfr42: cheers and bye bye
(15:31:38) jwilden: Thanks!
(15:31:40) jwilden: Bye :)
(15:31:41) ndrs`: ok, see some of you in Essen
(15:31:42) copierrj: bye
(15:31:43) ndrs`: bye