[Tue Nov 22 2011] Hi [14:27] Reijer? Hi people [14:28] Yes Hi shall we start? Johannes is on vacation and will probably not join us So were complete already. Johannes is on vacation. [14:29] ok ok * ndrs thinks markusschneider should lead the meeting ok Did you have a look at the agenda/wiki page: http://wiki.deegree.org/deegreeWiki/TmcMeeting/TmcMeeting20111123 [14:30] ShAnything important missing? looks fine to me ok Ok, so review is over :-) What do you guys have in mind with regard to our meeting schedule? I'd suggest a meeting every two weeks [14:31] fine to me +1 fixed time every week? if possible, yes I think we should try. is this a good time? usually it is [14:32] Fine with me. then let's go with it and change it as needed Next meeting on Tuesday, 6th, 14:30 then agreed right Ok. We are asked by the PSC to elect a chair. [14:33] I'd like to suggest markusschneider for the job me2 Ok, no work for you, fame for me. Fine. ok ;-) Is it ok for everybody that Johannes is not able to vote here? [14:34] I would say there is a majority present yes. We can still ask him for his opinion in two weeks Right. So, I accept the honor for now. congrats Thanks :-) yes, cheers Lets move on to the tracker items, shall we? [14:35] ok ok Most important seems 6265 what's a deegree summit? [14:36] TMC+PSC meeting f2f? I assume irc but makes a lot of sense IIRC [14:37] there is a issue in the psc meeting log that says f2f Any ideas concerning release date? true, I did not see that I heard that deegree day is planned for May. then that sounds like a reasonable date for 3.2 [14:38] I guess we should try to find a release schedule from 3 to 6 months yep Fine by me. if the deegree day will indeed be bi-annual, having a release ready for it seems like a good idea 3.1 was released only a few weeks ago [14:39] So we agree on a release for May 2012 (deegree day 2012). +1 +1 ok a specific day in May set already? [14:40] I don't think a date has been set yet I don't feel that this make too much sense at the moment. not for the release of course maybe end of April would be a good target Yes, this would give us some room for stabilizing [14:41] +1 +1 +1 Ok. End of April 2012 it is. [14:42] Any *important* issues for 3.2 ? Oracle support Here's one: CRS definately! Reijer, are you aware, that we have it already? layer/feature resource concept, new WMS config It's in 3.1 Separate JAR download. [14:43] deegree-sqldialect-oracle we haven't used it yet Should be on the same level as PostGIS support, although not as well tested. nice shall we put up some security release goals? [14:44] layer/feature concept: +1 what do you mean ? what security aspect? [14:45] eg. ability to secure WMS layers ah, ok only the layers, or it's content too that's indeed the question first parts of the security subsystem I think aiming for a complete deegree2 OWSProxy replacement would be a bit high I would suggest to only make it part of the official 3.2 release if configuration is already stable. And I doubt that... [14:46] but maybe we can state a release goal 'ability to secure access to resources' we've developed a deegree2 app that's able to filter out 'forbidden' features = ready nice feature would be nice if we had something similar in stock deegree3 like OWSProxy? yes, it's planned for d3 as well, but finegrained control like that will come after general access control to resources [14:47] It's definitely on the roadmap. no, a database hack that adds additional contraints to queries Maybe we should compile a list of all roadmap items first, and then decided what to put in 3.2. +1 http://wiki.deegree.org/deegreeWiki/deegree3/Roadmap Argh [14:48] SOS? WPVS? very out of date, but quite a lot of these items still stand open the question is, how do we decide what to put in for 3.2? full wfs 2.0 support might be nice Agreed. Ok, I would suggest to bring the list in shape off-line. [14:49] Not now. alright ok [14:50] action item for markusschneider? ;-) Except if you want to discuss anything in particular. Nah. Action item for ndrs? Any volunteers? I can do that +1 if I get input from you all regarding what features you know are planned to be developed until April 2012 [14:51] We can discuss this by mail already and then schedule stuff for 3.2. ok. I can bring the roadmap up to date, and we vote on that in two weeks +1 +1 [14:52] #6264? Any feelings whatsoever? -1 -2 [14:53] pointless imho I see two options: Stay with "services" or use "deegree-ows". Geoserver calls the endpoint "ows". I vote for staying with services if someone wants to change if -> build your own war agreed Ok. So we're staying with services? [14:54] +1 0 they want to improve the visibility of the product maybe we can think of something else? [14:55] Right. Considering that, I would agree with "deegree-ows" / "deegree-services". In the URL? What do you reckon? I still think this is from the time where there was no web console I personality don't like urls that advertise products [14:56] so the endpoint was the only option to propagate the deegree name but now that's changed, so I suggest to stay with services by default +1 (changed my mind) not everyone deploys the web console (we don't) [14:57] Considering visibility: +1 regarding not changing the endpoint How about putting a deegree / version header into deegree responses? or a favicon.ico? Or capabilities comments? extended capabilities? [14:58] Not every client will like that... I am afraid they have to learn to deal with that anyway (inspire) favicon is fine (for the console) I'd like to see a favicon also I like HTTP response headers +1 http response header [14:59] favicon: +1, http headers: +1 So we agreed on HTTP headers. splash screen (logo + text) when deployed without console? And favicon, I guess. Interesting ASCII-art? [15:00] http://deegree3-testing.deegree.org/utah-workspace/services?request=GetLogo nice, but probably not fashionable enough This could be a problem for CITE-compliance... true, it's more of an easter egg ;-) the GetLogo request has been included since 3.0... [15:01] I mean, if services would return an HTML/text response. I think that would apply to http://localhost:8080/deegree-webservices/, not to http://localhost:8080/deegree-webservices/services [15:02] But if we put another JSP/JSF whatever page, people may still not deploy it. just having an alternate welcoming page would be nice you can never prevent people from doing that, or from changing mappings in the web.xml So what's the point. [15:03] ? +1 welcome page, if small enough, and no active content, there is no reason not to deploy it But who will look at it anyway? Average users will always deploy the console. And expert installations are usually not accessed beyond the services mapping. [15:04] large portal webapps (= deegree should be visible here) are not going to deploy the console But if anybody wants to make a good looking start page, be my guest. so shall we suggest the use of HTTP-headers and a favicon to the PSC? [15:05] or just do it? + http headers I guess this could be too technical for the PSC... + 1 (again) Let's simply do the headers and inform the PSC about favicon/alternative start page. [15:06] +1 +1 +1 Good. #6263? [15:07] where is the document mentioned? I think that Johannes is actually very involved with this :-) "Ask Jens for the document" I would suggest to let the release manager act here. [15:08] yes, could be an action item for Johannes to document the process in the wiki +1 and even not knowing about the document, I'm sure we don't use it any more for d3 ;-) [15:09] But it's got to be updated for Maven... Reijer, any feelings here? I've no idea about the content of such a document [15:10] I think it describes how to build a release, where to deploy artifacts etc. best left to be documented and to be done by the release manager seems reasonable then, +1 [15:11] Ok, this one goes to: Johannes #6253? Again, this appears to be a release manager task. yep, maybe we should postpone it til next meeting, and then discuss how to proceed/if he needs help writing automated tests [15:12] +1 +1 #1305? [15:13] Anybody had a look at the SVN structure? [15:14] that would basically mean to put what's in deegree-workspaces into /applications, right a kind of contrib? ? http://svn.wald.intevation.org/svn/deegree/ well, contrib is IIRC 'things contributed by a third party' I think this task is really about organizing the SVN in a smart way. [15:15] deegree 2 / deegree 3 are fine IMHO base should be removed (merged into deegree2) [15:16] yep applications is almost obsolete as well apps should be removed (merged into deegree2) what's currently in deegree2 and base? Just deegree 2 artefacts [15:17] deegree2 is an out-of-date mavenized base ok base is ant-based deegree2 nono base is old, deegree2 is new deegree2 is based on an old base revision, I checked that today so deegree2 is a old version of the future deegree2? [15:18] argh :-) yes, exactly ;-) nice I can merge the changes in base into deegree2 I guess, we have to make an action item of that: complete mavenizing of d2 ok +1 +1 And then get rid of base. [15:19] yep how about poc's (proof of concepts) How about the other directories except deegree2 and deegree3? sharing wild ideas What do you mean? Do you have an example in mind? [15:20] Personally, I would like to minimize the structure as far as possible. (too) experimental feature stores, different ways to implement stuff etc. we can still include 'experimental' feature stores etc. in the main deegree3 build [15:21] they just won't be included in deegree-webservices I would also prefer that. And there's uncoupled below deegree3/trunk. [15:22] For stuff that's currently not maintained. Or not bound to the same version as the rest. ok But we probably have to discuss some details here in the future. Shall we continue removing directories? [15:23] ok, moving forward: contrib is still needed, I guess docs -> deegree2 it contains geoide, tibesti and so on yep contrib geoide is no longer in use demo -> deegree2 test -> deegree2 ok, one-by-one? [15:24] I think properly integrating all that stuff is a lot of technical detail which probably needs not be discussed here. I guess we all agree that having a clean top-level svn as suggested is a Good Thing? +1 [15:25] Maybe lets just finish the stuff that can clearly be moved to deegree2 folder? ok Anyway, we will have to report back to the PSC what we intend to do. we can communicate that we'll clean up as suggested [15:26] Ok. And who is going to perform the cleanup? The two of us? I think for available resources we shall have to talk to our companies Or do you want to be involved, Reijer? I can move stuff, but merging is a different matter [15:27] it'll probably involve mavenizing a project or 20 I wouldn't do this right now. I can do some of that, but I've to ask for the required time the more important stuff we should talk about is the extraction of the deegree-workspaces to /applications [15:28] Right. Do you want to explain the ideas on the future workspace registry? ok. the idea is to have a service somewhere, similar to a maven repository server such as artifactory [15:29] which can be queried to give (a list of) workspaces as opposed to the manually edited text file we currently have Meant for downloading example workspaces using the console. [15:30] together with a maven plugin to deploy workspaces to such a registry it would be a solution which has all workspaces in one place yes, to be accessed through the console how about storing a workspace inside a jar? a workspace is already a .zip/jar and the deegree-maven-plugin already generates these as maven artifacts [15:31] we just don't have a place to store information such as 'what deegree version was I intended for' or description/name etc. We believe it's a really nice feature to have for people learning deegree configuration or who want to have something to start with. [15:32] adding a kind of manifest to a workspace zip/jar > ? right but there must be a bit of server protocol as well a manifest would not enable you to search through 100s of workspaces to retrieve the manifests remotely imagine you have the utah-workspace for each 3.1-prex version Maybe we could even use the workspace POMs for that. [15:33] yes, but that's technical details. I think we should discuss whether we want deegree-workspaces to be removed from the main deegree tree because that's what the PSC is suggesting [15:34] or rather, telling us to implement If the version is going to become uncoupled from the rest, we could move it to uncoupled or put it outside of the deegree 3 tree completely (in applications). yes, that's what the PSC wants us to do [15:35] Personally, I would prefer a directory workspaces on top of the tree. As workspaces are so vital. Maybe: deegree3-workspaces then we'd have to give this back to the PSC [15:36] Maybe we postpone this for now. It's getting late. ok ok so we covered all the important issues? [15:37] #1256 can be closed, I guess. +1 commit templates are now longer in use? [15:38] no, not really ok -> +1 if we will have requirements in the future, I guess it will involve something with an integrated issue tracking system (and mylyn) [15:39] Shall we call it a day? yes, let's postpone the rest of the issues until the next meeting wiki for agenda next meeting? I will update the wiki page and provide a new page. ok you'll write down the action items as well? [15:40] yep I'll attach the IRC log thanks. i will go through it and update the wiki page thank you then [15:41] and good bye ok, see you in two weeks, bye cu, bye