Below is the transcript of a committer's meeting held on #dspace at irc.freenode.net at 20:00 GMT on April 29.
We intend to hold the next meeting on #dspace May 6th at 16:00 GMT. Anyone is welcome to attend. You can see the upcoming schedule as well as other DSpace developer events at: http://www.google.com/calendar/embed?src=3mfp5qsv0kejvsbh558lmshujk%40group.calendar.google.com Meeting Summary: We discussed next steps on the 1.6 survey results, and agreed to post the results, and designate leaders for the top three areas of interest. Each of these topic leaders is tasked with driving conversation, finding stakeholders, moderating/mediating discussion and generating Jira entries to accomplish the feature in question. Mark Wood will handle improved statistics, Stuart Lewis will handle batch metadata editing, and Richard Rogers will handle embargoes. We discussed the status of moving SVN to OSUOSL, and are continuing forward with exploring and planning for that move. No firm conclusions yet. Transcript: bradmc: I'll be waiting until a minutes after the hour per usual. Think up possible topics, please. [4:00pm] bradmc: Dspace.org had a DNS bobble (wrong MX with 1 week expiration), and I haven't gotten anything on lists since 4/23, and won't until likely tomorrow. Apologies if I'm behind. [4:01pm] mhwood: [wakens] [4:02pm] bradmc: Seed topics: [4:02pm] bradmc: GSOC. [4:02pm] bradmc: Who will be at OR09? Around for workshop Thu 1pm? [4:02pm] bradmc: 1.5.2 issues or updates. [4:02pm] bradmc: What else? [4:03pm] stuartlewis: 1.6 survey results - how we publish them. [4:03pm] bradmc: Foundation also has a user group survey, with results to be published soon, BTW. [4:04pm] bollini: osuosl update [4:04pm] scottatm: Topic nomination: OAI-harvesting addon for the next version of DSpace. [4:05pm] stuartlewis: Survey results (not much of a surprise): #1 Stats, #2 Embargoes, #3 Batch metadata editing (community admin and versioning as runners up) [4:05pm] stuartlewis: scottatm: There were a few mentions of that in the survey which is good. [4:05pm] scottatm: What stat's patch is there ready to be applied to DSpace? [4:05pm] mhwood: Any answers to the question: "what do you mean by 'statistics'?" [4:06pm] scottatm: mhwood: exactly. [4:06pm] stuartlewis: Thats where we need to refine the results - maybe working groups, or use JIRA to let people express what htey mean/want from stats? [4:06pm] mdiggory_: ok, is it possible to have "too many topics" [4:06pm] bradmc: I think we're starting with survey ? [4:06pm] mhwood: Yes, that's probably at least enough. [4:07pm] bradmc: Then OAI-harvesting, osuosl, and choose again after that? [4:07pm] scottatm: As for my topic, harvesting I would just really like to spawn another conference call to talk about it with those who are intrested. [4:07pm] bradmc: oh, ok. [4:07pm] mdiggory_: my concern is with when we say "ready to be applied to DSpace"... [4:07pm] stuartlewis: Survey results here: http://www.wordle.net/gallery/wrdl/794098/DSpace_1.6_survey_results [4:08pm] rrodgers: stuartlewis: did we get any detailed sense of metadata editing? [4:08pm] stuartlewis: Not really. Most of the responses were just thinkgs like 'better statistics", "batch metadata editing" etc. [4:08pm] rrodgers: ok [4:08pm] mdiggory_: And I expressed my cautions on the listserv in response to threads about the OAI Harvester... Think we need to talk about how to structure new code into modules even for 1.6 [4:09pm] scottatm: mdiggory: I agree. I have some concerns and would like to talk about them. [4:09pm] stuartlewis: I think we need to pick the ones we want to see in 1.6 and think we can muster the effort for, and then gather groups to decide what do stats meean, what needs to be batch editable etc. [4:09pm] mdiggory_: stuartlewis: I will refrain from marketing, but I have to reference that @mire has both those as products ATM [4:09pm] scottatm: mdiggory_: I've been debating over an email response for a couple of days, and I'm unsure about what i think. [4:09pm] bollini: stuartlewis: can we see also the "original file" behind wordle? [4:10pm] stuartlewis: bollini: yes, once I have santized it. There are the odd personal comment that I need to remove first. [4:11pm] stuartlewis: mdiggory_: Regarding the @mire implementations - how do we work with them / can we work with them / what do they do if we build alternatives into the core? [4:11pm] mdiggory_: stuartlewis: my point in mentioning that is in concert with the comment to scottatm about modularity. It would be best to provide for these features a number of options [4:12pm] mdiggory_: and let the community choose... when we say "core" it is different than a default distribution [4:12pm] stuartlewis: Do we have the framework for modularity yet? [4:12pm] bollini: for the stats we should use a modular approach but the batch edit need only one implementation [4:12pm] mdiggory_: We have modularity provided by both MAven and Cocoon [4:13pm] mhwood: It's getting there. Much more so on the XMLUI side I think. [4:13pm] stuartlewis: We have add-on modules like SWORD and LNI which other than using the API sit right outside the UIs. How would modules fit into the UIs? has that been sussed yet? [4:13pm] scottatm: My comments about the addon point, is that it's basically unknown territory for anything other than a webapp that creates a completely new webapp. 1) Where does the code live? 2) How is an addon installed without editing POM files, 3) How can an addon play nice with the administrative interface? [4:13pm] mdiggory_: and @mire uses this modularity to create addons that are enabled into dspace xmlui by just adding dependencies and the @mire repository [4:14pm] mdiggory_: scottatm: I'm presenting on modularity in DSpace 1.5.2 (and now apparently 1.6) and 2.0 [4:14pm] mdiggory_: at OR09 [4:15pm] mhwood: That's one I definitely want to attend. [4:15pm] scottatm: mdiggory: would you mind having a conference call to discuss that for the harvesting addon? (preferably before OR09) [4:15pm] mdiggory_: scottatm: absolutely [4:15pm] stuartlewis: Yes - if we could all join in on that to see the general principles of how add-ons can work better, that would be great. [4:16pm] scottatm: mdiggory_: okay, i'll schedule that over the dev list. [4:16pm] mdiggory_: sure... [4:16pm] bradmc: Is it safe to assume that @mire will be sharing this technique, and advocating it for general use? [4:16pm] mdiggory_: bradmc: thats why I proposed the presentation. [4:16pm] bradmc: (twas just for the record ? [4:17pm] mdiggory_: ? [4:17pm] stuartlewis: Ok - so with the survey top 3, would we say that stats should be modular, but bacth editing and embargoes be core? [4:17pm] bollini: anyone has idea about improve the modularity also for JSPUI? [4:18pm] mhwood: One difficulty is that we have modularity all over the place, but it's different for different purposes. We have plugin points for things like authentication. We can add stuff to XMLUI pages by dropping in Aspects, and the Theme end of the pipeline is nicely modular (but needs documentation). [4:18pm] scottatm: Is the JSPUI going to be ported to DS2.0? [4:18pm] mdiggory_: stuartlewis: likewise, we've done two embargo solutions since I joined @mire, both accompish embargo without touching the database table schema [4:18pm] mdiggory_: one focuses on embargoing the entire item, those other individual bitstreams [4:19pm] bollini: scottatm: I like to see a new JSPUI in DS 2.0 [4:19pm] bradmc: Shame Graham isn't here. He's working on new JSPUI in 2.0 [4:19pm] mdiggory_: mdiggory_: scottatm bollini I worry about more than one UI and the issues with maintaing both in concert [4:20pm] bradmc: Interesting data points from latest user survey: [4:20pm] mdiggory_: for instance, I havn't a clue about what Grahams been implmenting [4:20pm] mdiggory_: even though we are working in the DSpace 2.0 group together [4:20pm] mhwood: Yes, there are things that got into one but not the other, and things they have in common but configure differently. [4:21pm] bradmc: 45% 1.5.x 32% 1.4.x 16% 1.3 or less [4:21pm] rrodgers: bradmc: interpret please? [4:21pm] bollini: the actual JSPUI is pretty "old" but now we can do better... I'm not a fun of XMLUI sorry [4:21pm] mdiggory_: My goal with the XMLUI port to 2.0 is to drive the requirements for the services API and modular strategy [4:21pm] stuartlewis: bradmc: Are there results for xmlui vs. jspui too? [4:21pm] bradmc: 67% JSP-UI, 39% XML-UI (some overlap) [4:22pm] stuartlewis: Wow - those figures (for 1.5 + xmlui) are higher than I imagined, but really good news. [4:22pm] bradmc: 41% prefer XMLUI, 16% prefer JSP UI, 38% don't know. [4:22pm] mdiggory_: There are things we (Ben and myself) are doing that impact the DSpace 2.0 core and we are not taking into concern maintence of Grahams jspui as we do these adjustments. [4:23pm] stuartlewis: bradmnc: And what about the other 5%? ? [4:23pm] bradmc: Neither. [4:23pm] mdiggory_: (mostly because we haven't time to maintain two implementations for the community) [4:24pm] scottatm: It's very hard to communicate what capabilities DSpace supports when there is not parity between the interfaces. It leads to a lot of confusion. (i.e. does the Minho stat's package work with the XMLUI?) [4:24pm] stuartlewis: Should we make a new rule for 1.6+ that all new features must be in jspui + xmlui? I'd be in favour of that. [4:25pm] scottatm: stuartlewis: The problem is time... who's going to develop all those features? [4:25pm] mhwood: Seconded [4:25pm] bollini: stuartlewis: -1 [4:25pm] stuartlewis: bollini: Why not? [4:25pm] bollini: time [4:25pm] mdiggory_: one final point on the subject of the modularity work I've been doing... since XMLUI has richer plug-ability than JSPUI, it has limited benefit on JSPUI. [4:26pm] stuartlewis: scottatm: Well hopefully the big thinkgs people want (stats / embargoes etc) are already implemented, we just need to find the time to agree which solution to all work together on, and get those integrated. [4:26pm] mdiggory_: per JSPUI, you can create maven dependencies and overlays, but it requires hacking the web.xml and other part of JSPUI to introduce new services/servlets. [4:27pm] scottatm: stuartlewis: It's alot to ask of a contributor who developed something cool to go learn a completely new framework and re-develop your cool thing. [4:27pm] bollini: mdiggory: we should explore some solutions like OJS template "hook", I remember that R Jones has already walk in this direction [4:27pm] mdiggory_: will take a look [4:28pm] mdiggory_: if you take a look at OSL right now... heres the landscape of how we need to think about working with "modules" [4:28pm] mhwood: If you developed something cool for interface I but don't have the time or knowledge to do it for J, then you need to find someone else who can help with J. [4:28pm] scottatm: I'm obviously not impartial, but it seems to me that we as a community should narrow down the primary interface to one.... either XMLUI or JSPUI or something new.... [4:28pm] mdiggory_: https://dspace.osuosl.org/svn/bazaar/ [4:28pm] mdiggory_: language packs located in... https://dspace.osuosl.org/svn/bazaar/modules/ [4:29pm] stuartlewis: Yes - perhaps we need to slowly move away from adding cool features to one UI, and work on the missing core features for both uis that the users really want? [4:29pm] bradmc: scottatm: I think the question is _when_ [4:29pm] rrodgers: I think the proof of a real service architecture is UI agnositicism [4:29pm] scottatm: bradmc: We should make the decision of where we want to go now. Then slowly move there. [4:30pm] mdiggory_: rrodgers: yes, but theres alot of functionality that comes into the application on that services framework and dspace is both of those [4:30pm] bollini: rrodgers: we need also to provide a full solution "out-of-box" [4:30pm] stuartlewis: Presumably it should be xmlui, as jspui will die in 2.0 (even if it is resurrected in a new form?) [4:30pm] rrodgers: agreed to both points [4:31pm] mdiggory_: rrodgers: but yea, we are keeping the services as UI agnostic as possible. [4:31pm] bollini: I agree that we need to define a primary interface but we should delay the decision some time after the 2.0 release [4:32pm] mdiggory_: if Graham were here... we'd have a debate ont he topic of DSpace 2.0 JSPUI [4:32pm] bradmc: Even if the services are agnostic, you will still have UI code, and developers will still develop for one, leaving us without parity. [4:33pm] bollini: bradmc: I think that the comunity will develop for the UI technology more known [4:33pm] stuartlewis: Should we decide what is core and needs parity, and what is cool which doesn't? [4:33pm] mdiggory_: my assertion on this topic is we are working on XMLUI because we find it the ideal target for implementing the demonstration for OR09 and we've been very successful in getting a running demo on it [4:33pm] rrodgers: I guess I'm imagining 'parity' as a disappearing concept - people will use different module-sets [4:35pm] bradmc: bollini: It's not clear to me which is "more known" at this point. XMLUI is showing substantial growth. [4:36pm] scottatm: The XMLUI was built from the ground up to support abstraction in the interface layer..... to modularize. [4:36pm] mhwood: If there's not a module-set that provides Feature Q on your preferred UI, that breaks parity. [4:36pm] scottatm: It was built to address that problem in the JSPUI. [4:36pm] bollini: bradmc: XMLUI is growning in the dspace community... I'm looking to coocon vs spring mvc or jboss seam [4:37pm] mdiggory_: I suspect if Aaron were here we would be talking about the REST app and its mediating a boundary between the kernel/core services and UI implementations. But, there is still not a REST implementation yet in 2.0 [4:38pm] mdiggory_ thinks parity is a red herring [4:38pm] stuartlewis: What is the end game? A Fedora like community which comes together around different UIs and a core repository model, or an out the box solution with a couple of optional UIs? [4:38pm] bollini: anyway I think that *we* can not solve this issue at the moment... [4:38pm] scottatm: bollini: agreed, and this should be on the email lists for *way* more participation. [4:38pm] bradmc: Can't solve it, but it definitely was time to reopen the debate. Lots of new data and options since last go round. [4:39pm] bradmc: Shall we move on to OSUOSL update? [4:39pm] stuartlewis: Have we decided how to move forward with the 1.6 survey results? [4:40pm] mdiggory_: I assume that there are parties already planning what they want to see get into 1.6... [4:40pm] stuartlewis: We can publish the results, but if we don't act (in some way) on them, we'll be asked why we asked then did nothing. [4:41pm] bradmc: I think sanitize and publish. Wiki, maybe? Then let the proposed interest groups rally around each area and get 'em into useful form on Jira. So we should find a point person for each of the top N (3?) [4:41pm] stuartlewis: bradmc: Good idea. [4:41pm] mhwood: I think the survey tells us what we ought to be looking at prepping for 1.6 whether it tops our personal lists or not. [4:41pm] mdiggory_: I agree, but we also need to be collaborative on the solutions. [4:42pm] bradmc: definitely. [4:42pm] stuartlewis: mdiggory_: Yes - so the pioint person can be the hub and enabler of that collaoration and discussion. [4:42pm] mdiggory_: with multiple implementations of various features (like embargo) we need to get concensus on which is appropriate [4:43pm] mdiggory_: or if we are utilizing them to inform an ultimately better solution [4:43pm] mhwood: With diffuse concepts like "statistics" we may not get a consensus. [4:43pm] stuartlewis: So, 3 volunteers? I'm happy to be one. [4:43pm] mdiggory_: mhwood: I agree [4:44pm] bradmc: Hopefully, we'll get to "core" pieces, and "modular addons", and can get consensus on the "core". [4:44pm] mhwood: Since I'm always whining that I want to know more clearly what "better statistics" means, I guess I should volunteer for that one. [4:44pm] mdiggory_: mhwood: one for the reasons that UsageEvent hooks are so critical to the core... [4:44pm] stuartlewis: I can volunteer for batch metadata editing. [4:45pm] stuartlewis: Which leaves embargoes. Anyone? [4:45pm] rrodgers: I can have a look [4:45pm] mdiggory_: I don't think we should be volunteering here... we should be requesting this asyncronously within the community on the listservs [4:46pm] stuartlewis: Great ? So when I publish the results, I'll name Richard, Mark, and myself and contact points for those, and we can start further discussions on those points. [4:46pm] mdiggory_: I need to consult with my pack to determine how/what we intend to do [4:46pm] stuartlewis: mdiggory_: I think these are big ebnough topics to require a person to drive them forward and keep the discussions on track. Otherwise they [4:46pm] stuartlewis: ll go nowhere. [4:46pm] bradmc: stuartlewis: agreed. [4:47pm] mdiggory_: stuartlewis: agreed if they are acting as mediators/managers [4:47pm] mhwood: mdiggory: what would you like to see then? [4:48pm] mdiggory_: mhwood: a couple more clones of Brad ? [4:48pm] bradmc shivers [4:48pm] mhwood: What should happen on the mailing lists, specifically? [4:48pm] bradmc: By default, everything ? [4:49pm] mhwood: No finished slate of volunteers, but what? [4:49pm] stuartlewis: Or can we gather interested parties if required, meet on IRC, and publish logs like we do with these meetings? Sometimes being able to chat gets further than just emails to lists. [4:49pm] mdiggory_: my point is that we take each target, identify the participants and solutions and evaluate to achieve some comunity agreement on the appropriate strategy for implementation [4:50pm] stuartlewis: mdiggory_: I think that is what we were suggesting, just with a point person to keep things on track. [4:50pm] mhwood: But how? These topics always die after everybody agrees that they're important. [4:50pm] bradmc: I like that technique. Send an email announcing an IRC. Have the IRC, post the results. [4:50pm] mdiggory_: in each case we are probibly talk both core changes and creation of alternative modules [4:51pm] stuartlewis: mhwood: Thats down to us to not let them die if we are driving them. [4:51pm] bradmc: Then, point person should drive to a goal of Jira entries that are accepted, and gather volunteers to own those entries. [4:51pm] mdiggory_: topic die because no one is a stakeholder in them [4:51pm] bradmc: Ah, so do our 3 topic leaders feel they are stakeholders on the topics? [4:52pm] stuartlewis: Yes, and they need to gather more stakeholders to make a group. [4:52pm] rrodgers: Yes, our recent open-access mandate has me looking at embargo.... [4:52pm] mhwood: I have some investment in statistics. [4:52pm] mdiggory_: I am certainly a stakeholder on all three of the topics (because we have commercial products in all three areas we've discussed) [4:53pm] bradmc: Apologies, I have to step away in just 2-3 minutes. Please continue and I will summarize the result and send out later. [4:53pm] stuartlewis: Ok - so I'll draft a response to the survey, run it past the -commit list, then we go from there. [4:53pm] stuartlewis: Is that the survey results discussion finished? Move on to OSUOSL? [4:54pm] mhwood: OK [4:54pm] bollini: yes please [4:54pm] mdiggory_: So with the changes on SF and the addition of Ben as a commiter, I feel we have more time to evaluate OSL prior to a full fledged migration [4:55pm] mdiggory_: I've added all the commiters I found in the users list of the OSL trac to be svn commiters [4:55pm] mdiggory_: This is currently divided into two overlapping groups... [4:56pm] mdiggory_: ok, three overlapping groups [4:56pm] mdiggory_: admins Group Members [4:56pm] mdiggory_: mdiggory [4:56pm] mdiggory_: bradm [4:56pm] mdiggory_: dspace1 [4:56pm] mdiggory_: Group Members [4:56pm] mdiggory_: mwoodiupui [4:56pm] mdiggory_: bollini [4:56pm] mdiggory_: ScottPhillips [4:56pm] mdiggory_: stuartlewis [4:56pm] mdiggory_: grahamtriggs [4:56pm] mdiggory_: mdiggory [4:57pm] mdiggory_: gabriela [4:57pm] mdiggory_: cjuergen [4:57pm] mdiggory_: tdonohue [4:57pm] mdiggory_: @admins [4:57pm] mdiggory_: dspace2 [4:57pm] mdiggory_: Group Members [4:57pm] mdiggory_: ben [4:57pm] mdiggory_: ScottPhillips [4:57pm] mdiggory_: aaronz [4:57pm] mdiggory_: grahamtriggs [4:57pm] mdiggory_: mdiggory [4:57pm] mdiggory_: bradm [4:57pm] mdiggory_: @admins [4:57pm] mdiggory_: sorry, that messy [4:57pm] mdiggory_: I'll put it up somewhere it can be presented better after the meeting [4:57pm] stuartlewis: Is there any reason for us all not to be admins? [4:58pm] mdiggory_: theres a /bazaar/dspace project with the original SF source [4:58pm] mdiggory_: theres a /bazaar/dspace2 project with the 2.0 work [4:58pm] mdiggory_: and /modules/dspace-xxx-lang projects as examples from dspace-sandbox [4:59pm] mdiggory_: stuartlewis: admins isn't all that exciting [4:59pm] bollini: mdiggory: can we put simple comment anywhere to test commit right? [4:59pm] stuartlewis: No, but less bottlenecks and depency on 2 people [4:59pm] mdiggory_: I expect the admin group to grow, but I want to manage it conservatively [5:00pm] mdiggory_: all admins are doing ATM is managing the TRAC permissions [5:00pm] stuartlewis: So whats next? Do we just need to decide a move date, or are there still questions about the move that need resolving? [5:01pm] mdiggory_: we can delegate rights for creating new bazaar/modules and bazaar/* projects to limit the risk of bottlenecks [5:02pm] mdiggory_: I think we need to build a list of issues that need to be addressed prior to a move... [5:02pm] mdiggory_: for instance, server resolution of scm.dspace.org [5:02pm] mdiggory_: cnfiguration of Atlassian FishEye and JIRA isntances [5:03pm] mdiggory_: svn hooks for emailing to change listserv [5:03pm] stuartlewis: But are there any objections to moving, or do we just need to wait a couple of weeks while you and Brad put these things in place? [5:03pm] mdiggory_: ? [5:03pm] mhwood: No objection here. [5:04pm] stuartlewis: None here - if we are going to do it, now seems a good time at the start of the 1.6 iteration. [5:04pm] bollini: none here [5:04pm] rrodgers: I don't care [5:04pm] mhwood: Better sooner, before we figure out what 1.6 is and start sending updates. [5:06pm] mdiggory_ shivers [5:06pm] stuartlewis: So maybe we get those last bits put in place, give -devel a chance to shout if there is a problem with moving, then set a date to move? [5:06pm] mdiggory_: I just want to be very sure everything is stable before we transition [5:07pm] mhwood: What do you need to see? [5:07pm] mdiggory_: I'll probibly need to do something like I did with ou CVS2SVN migration [5:08pm] mdiggory_: That is, Identifying where svn reorgs are occurring so is clearly understood [5:09pm] mhwood: Sounds good. [5:09pm] mdiggory_: we will be dropping certain branches and trunk at SF after the move and freezing commit activity there [5:10pm] mdiggory_: we do so to assure that there is no confusion concerning where the 'HEAD" is located [5:10pm] stuartlewis: dropping = deleting? [5:11pm] mdiggory_: right. history will still be intact, but not visible in last revision [5:11pm] bollini: I'm sorry, I have to leave - I will check the transcription and add my comments if needed [5:12pm] mdiggory_: or, it may be better to leave the branch/trunk with a README identifying the new location but all other contents deleted [5:12pm] mdiggory_: thnx bollini [5:12pm] rrodgers: I've got to run soon as well [5:12pm] mhwood: I should leave soon too. [5:13pm] mdiggory_: I think thats a natural segway [5:14pm] stuartlewis: Agreed. ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
