Below is the transcript of a committer's meeting held on #dspace at irc.freenode.net at 20:00 GMT on June 24, 2009.
We intend to hold the next meeting on #duraspace July 1 at 16:00 GMT. NOTE: that's #DURASPACE, not #DSPACE. We're experimenting with sharing a channel with the Fedora-commons projects for meetings. You can see the upcoming (weekly) schedule as well as other DSpace developer events at: http://www.google.com/calendar/embed?src=3mfp5qsv0kejvsbh558lmshujk%40group.calendar.google.com&ctz=America/New_York Anyone is welcome to attend. Meeting Summary: We had the usual updates on 1.6 and GSoC. There is a solid first draft of batch metadata editing ready to go for command line and JSPUI; XMLUI version is forthcoming. Delegated administration (DS-228) is making good progress. We decided that we should require submissions in Jira to have associated documentation before an issue is closed. A field to flag this will be added, and will help Jeff Trimble (and others) keep track of documentation changes. There was a bit of discussion about in-memory item counters. Finally, we scratched the surface of how to get the DSpace and Fedora committer's communities interacting. One initial step is to hold both team's committer meetings on a common channel, #duraspace. Transcript: bradmc: Hello all. We'll start in a few minutes. Meanwhile, let's start placing potential topics on the floor: [4:00pm] bradmc: Should we engage with the Fedora committers (and how)? [4:00pm] bradmc: DSpace 2.0 process integration into mainstream DSpace. [4:00pm] bradmc: What to do / when to address orphaned issues (now in Jira). [4:00pm] bradmc: Documentation update process. [4:00pm] stuartlewis: Documentation, and relationship between committers and documenters (is that a word?) [4:01pm] jeffreytrimble: document gardners you said earlier. [4:02pm] bradmc: That was me, with attribution to Thorny Staples of Fedora which is where I heard the term. [4:03pm] bradmc: Topic: GSOC update. [4:04pm] rrodgers: 1.6 update [4:04pm] bradmc: Should we start with 1.6, then GSOC updates (that we have), then take up documentation, then Fedora interaction, and end on DS2 integration? [4:05pm] rrodgers: works for me [4:05pm] stuartlewis: Sounds good [4:05pm] bradmc: Okay, Richard, Stuart, or MarkW, you have the keyboard ... [4:05pm] rrodgers: Re embargo: I put a skeleton strawman (block that metaphor!) up on the wiki [4:06pm] stuartlewis: 1.6: batch editing: A first draft now exists, command line version, and jspui version. It exports and imports csv, and seems to work well. Jeffrey has been testing it. [4:06pm] • grahamtriggs_ thinks this could take some time if we are passing keyboards between US and NZ [4:06pm] stuartlewis: http://wiki.dspace.org/index.php/Batch_Metadata_Editing_Prototype [4:07pm] stuartlewis: If everyone is happy, I can commit the batch editing stuff to svn to make it easier for everyone to play with it. Other than the jspui integration, it is all quite insular and sits in its own package within org.dspace.app [4:08pm] rrodgers: what about an XMLUI version? [4:08pm] stuartlewis: It will come - but I can develop in jspui faster than I can in manakin right now. [4:08pm] stuartlewis: So to be able to show a demo, it is nicer in the UI, so hence I chose jspui first. [4:08pm] rrodgers: Cool - just since we committed to 'parity' [4:09pm] kshepherd: i was planning to look at doing the xmlui version but time's gotten away from me.. [4:09pm] grahamtriggs_: although it didn't come up on the Wiki, I suspect a number of responses to the survey would have been wanting / expecting some kind of interactive UI in the web application itself [4:09pm] stuartlewis: kshepherd: If you could, that would be great. Didn't want to volunteer you without asking first though! [4:10pm] grahamtriggs_: however, I think what has been implemented does provide for some interesting scenarios, and should certainly exist as another tool in the armoury [4:10pm] stuartlewis: grahamtriggs: Agreed, but I suspect that would cost 5* the dev effort. I've not got that effort [4:10pm] stuartlewis: Ok then - unless anyone shouts otherwise, once I've done a final polish on it, I'll commit it. [4:10pm] bradmc: +1 [4:11pm] rrodgers: go for it +1 [4:11pm] kshepherd: +1 [4:11pm] stuartlewis: Also for 1.6: Looks like Tim and Andrea are doing a good job on the delegated admin, so that is progressing nicely. [4:11pm] mhwood: +1 [4:11pm] bradmc: Yes, DS-228 is looking healthy. [4:12pm] rrodgers: Would folks want a memory-based Item Counter? [4:12pm] kshepherd: re: 1.6 stats -- I've made notes on my stats app and have linked to demos, but haven't actually made source available or documented it properly, so that's my next step, in case there's anything people can take from the 'homegrown stats' we've come up with here [4:13pm] mhwood: That's helpful. Things are still quiet (and I still need to stir them up). [4:13pm] grahamtriggs_: stuartlewis: one caveat - how does the performance look? Looking at the described functionality, it looks like there might be some problems scaling to dealing with large numbers of items [4:13pm] jeffreytrimble: We're about to find out...I'm loading some 400+ changes tomorrow on our production server. [4:14pm] stuartlewis: rrodgers: What sort of item counter? [4:14pm] rrodgers: Just like the current one - without the database (faster, no batch update, etc) [4:14pm] stuartlewis: rrodgers: The communiy strengths? [4:14pm] rrodgers: yes [4:15pm] kshepherd: seems reasonable [4:15pm] stuartlewis: grahamtirggs: Depends on how many changes there are (as opposed to lines to read). But I think for the UI we should pace a limit - e.g. no more than 100 changes at a go. CLI would be unrestricted. [4:15pm] stuartlewis: rrodgers: Sounds sensible. Would it manage its own updates then? [4:16pm] rrodgers: either invalidate the cache every x hours (config) or run as event listener and always stay current [4:16pm] stuartlewis: Sounds great. [4:16pm] bradmc: If the CLI is unrestricted, what happens if the operator aborts it? [4:17pm] grahamtriggs_: stuartlewis: but surely it has to load all the items that are described in the CSV, to see if there are changes - that's not free! (although if people leave hundreds of unchanged items in an exported CSV for import, that's their own damn problem) [4:17pm] bradmc: (I'm poking around the edges of batch size limits) [4:17pm] stuartlewis: It commits changes line by line as it makes them. So no rollback. [4:17pm] awoods joined the chat room. [4:17pm] bradmc: Okay. Thanks. [4:17pm] stuartlewis: Is that good behaviour though? Would it be better to commit in one go, but could get dicey with large numbers of changes? [4:18pm] rrodgers: I think that is good behavior - the batch is a convenience, not a transaction isn't it? [4:18pm] stuartlewis: rrodgers: Yes, I guess so. [4:18pm] grahamtriggs_: rrodgers: wouldn't work for web app server clusters [4:19pm] mhwood: I think we have a number of problems here and there with assumptions about how big a batch could be. A commit every 100 changes might be a good idea. [4:19pm] rrodgers: grahamtriggs_: what wouldn't? [4:19pm] grahamtriggs_: the in memory counter [4:20pm] stuartlewis: It is semi fail-safe in the fact that should it break half way through (although on its first run through it checks everythign is Ok, so in theory can't break on the second run which performs the changes) then when you ruin it again, the first x rows will have already updated, and it will pick up from where it left off. [4:20pm] • bradmc likes "ruin it again" [4:20pm] • stuartlewis performed an excellent fruidian slip! [4:20pm] kshepherd: heh [4:21pm] rrodgers: grahamtriggs_: not sure about that - why not every class-loader has it's cache? [4:22pm] bradmc: rrodgers: Different nodes in the cluster could have different counts, no? [4:22pm] grahamtriggs_: stuartlewis: do you export the owning collection / implement moving items? [4:22pm] stuartlewis: I suppose the event mech wouldn't work across clusters, but the in memory cache (with invalidation every x hours) would? [4:23pm] stuartlewis: grahamtriggs: Yes! One of the cool features it has that I think people will really like. [4:23pm] bradmc: On the batch transaction size of 1: I think that's good, at least for now. [4:25pm] bradmc: Are we close to wrapping 1.6 and moving to GSOC? [4:25pm] stuartlewis: If I get the time, I'll awrite an extension to the batch editor that writes a transaction log that can be rolled back (in otherwords a csv of the items before the changes were made) [4:25pm] stuartlewis: bradmc: GSoC: OK [4:25pm] grahamtriggs_: rrodgers: yes, each classloader would have it's own cache. The event mechanism would only notify the cache within the classloader that triggered the event. Invalidation every x hours would lead to the servers reporting data out of sync [4:27pm] • bradmc has Scottie beam the keyboards to the GSoC reporters [4:27pm] You left the chat by being disconnected from the server. [4:27pm] You rejoined the room. [4:28pm] grahamtriggs_: the numbers would be different depending on which server your request was being directed to [4:29pm] stuartlewis: GSoC: db-driven input forms: Progressing. Not much more to say really. Student is active on IRC from time to time, so that is good to see. [4:29pm] rrodgers: No update from my student to report [4:30pm] stuartlewis: rrodgers: Is that a case of "no news is good news"? [4:30pm] rrodgers: Generally yes, with him [4:31pm] stuartlewis: Cool [4:31pm] bradmc: Next up will be Documentation, unless more GSoC reports ... [4:32pm] stuartlewis: With documentation, we have Jeff Trimble online today Jeff has kindly agreed to help us with documentation. So we want to discuss how best to manage the interaction between commnitters committing code, and making sure it is documented, and jeff can work on it etc. [4:33pm] stuartlewis: Like we dislike people throwing code over the wall at us, we don't want to throw bad (or zero) documentation over the wall to Jeff. [4:33pm] jeffreytrimble: Well, fortunately, I'm teflon, so all code will bounce back. [4:34pm] stuartlewis: [4:34pm] • bradmc sheepishly takes back his zero documentation [4:34pm] • stuartlewis meant 'zero' on a patch per patch basis only! [4:34pm] jeffreytrimble: Seriously, is there a way for Jira to have a stage where the software can be committed only after the coder/submitter has also deposited the basic documentation? [4:35pm] bradmc: Potentially, yes. [4:35pm] mhwood: So, someone Out There submits a nice patch or addon or whatever, but the documentation is poor or nonexistent. What happens and who makes it happen? [4:35pm] jeffreytrimble: I think if you want to commit the code, you got to throw the documentation dog a bone. Something is better than nothing. [4:35pm] bradmc: Either by defining what we mean by an existing state, or by adding a new one. We just need to answer questions like mhwood's first. [4:36pm] mhwood: So there's a workflow step "check and repair documentation". [4:37pm] stuartlewis: Suppose it depends on us. If we feel we can write the documentation and have the time to do so, and it will be less painful that requesting it, then do so. Otherwise request documentation to be added to JIRA, otherwise it is unlikely to get committed? [4:38pm] bradmc: I do think we want the doc patch (or doc contents) associated with the Jira entry. [4:38pm] jeffreytrimble: Yeah, if it something new, I (as a in-the-treanch admin) need to know the basics of what it does and what I need to do to make it work. Grammer isn't important--I'm happy to fix that. [4:39pm] jeffreytrimble: that alone should trigger something in Jira. [4:39pm] jeffreytrimble: Same with enhancements and fixes. [4:39pm] mhwood: How does Jira know that a patch needs doco? [4:40pm] stuartlewis: mhwood: We'd have to leave a comment to that effect. [4:40pm] jeffreytrimble: And can there be exceptions to having Jira let code go through that doesnt need documentation? (Like a bug fix ) [4:41pm] bradmc: Or we insert a workflow state of "Resolved - Pending Documentation". [4:41pm] kshepherd: "documentation?! my code is self-explanatory!" </kidding> [4:42pm] bradmc: kshepherd: It displays itself in the browser window? [4:42pm] grahamtriggs_: Add a separate field to JIRA for documentation - forces people to at least make a statement: no doc required, doc included in zip, brief description of feature / usage, etc [4:42pm] bradmc: jeffreytrimble: It's always possible to push past a workflow step. [4:42pm] kshepherd: grahamtriggs_: good idea [4:43pm] • bradmc checks Jira's capabilities ... yes, can do a doco field. [4:43pm] jeffreytrimble: Yes, as long as we have a way to flag the code with some type of documentation status, I'm able to assess what needs to be done in the documetation forest. [4:44pm] kshepherd: i have a staff forum in 5min (and i'm presenting :/) so i'll be gone soon [4:46pm] mhwood: More on documentation, or next topic? [4:46pm] bradmc: So, I definitely think I should add a "Doc" [needed, not required, included] flag. Do we need a workflow step or a doc detail field, or should the detail go in a comment or attachment? [4:46pm] bradmc: Next topic coming right up after I make sure I know what to do to Jira [4:47pm] bradmc: Fedora Interaction: [4:47pm] bradmc: We have Chris Wilper, and Andrew Woods from Fedora auditing this meeting. They have a committer's meeting Tuesdays, 10am (medium varies, under investigation) that some or all or you could attend. We probably want to have some targeted conversations just on working together as well. Spit out your ideas, please. [4:48pm] grahamtriggs_: states: needed, not required, in attachment(s), in description, in comments [4:48pm] gaurav_hiiii joined the chat room. [4:48pm] bradmc: grahamtriggs_: +1 [4:49pm] stuartlewis: needed = missing? [4:49pm] grahamtriggs_: stuartlewis: yes [4:50pm] bradmc: needed = WTFM! [4:50pm] mhwood: Call it "missing" then, to set the right tone. [4:50pm] stuartlewis: Maybe change 'in comments' to 'in JIRA comments' for clarity? [4:50pm] rrodgers: Well one obvious one is how - without undue proliferation of new communication channels - does information flow? [4:51pm] bradmc: rrodgers: Yes, I'm inclined to dedicate a little time in the existing meetings, if that's acceptable. If we have a few cross-pollinators we should be able to get started. [4:52pm] grahamtriggs_: obvious first step to answering that one - there are already a number of projects under the Fedora commons banner. How does communication work within that structure? [4:52pm] cwilper: Hi all...I've just been lurking here but find it interesting to follow along with your discussions. Since both of us have open meetings already that seems like a natural thing to do [4:53pm] mhwood: Agreed, I guess what we need to know is "where?" [4:53pm] grahamtriggs_: #duraspace [4:53pm] cwilper: #fcrepo [4:53pm] rrodgers: bradmc: I think that's great as a start, if you don't mind being a correspondent [4:53pm] bradmc: One of the challenges for Fedora is that a lot of central management was done; the direction is to get more community like (DSpace like). So there isn't an existing community driven cross-project mechanism. [4:53pm] bradmc: rrodgers: As long as I'm not the only one. [4:54pm] cwilper: graham, communication across the different fc projects is usually pretty loose and just occurs on the mailing list or via email. the fcrepo (fc repository project) has the weekly meetings. [4:54pm] bradmc: Interesting point, grahamtriggs_ What would happen if the IRC channels were intermingled? [4:54pm] • bradmc doesn't want to jump right to that, though. [4:55pm] cwilper: I think having a group channel would be cool. They're cheap, right? [4:55pm] grahamtriggs_: I'm not sure we should do that for everything, but if we had #duraspace for holding meetings, we could leave #dspace, etc. free for people wanting to chat about problems, etc. [4:57pm] cwilper: We only recently started using irc (and really only for meetings), so switching channels for meetings wouldn't be a problem here [4:57pm] grahamtriggs_: it would also encourage us not to arrange meetings for overlapping times, ensuring that people at least have some opportunity for participating in all / any they want to [4:58pm] stuartlewis: #dspace is pretty quiet most of the time too, so would swapping be a problem for us? [4:58pm] gaurav_hiiii left the chat room. [4:58pm] bradmc: cwilper: I think the larger challenge is that the historically the Fedora folks are used to a voice channel. (Everyone, Fedora has been experimenting with joint voice / IRC calls as well). [4:59pm] bradmc: Should we try an experiment with meetings in #duraspace for a little while? [4:59pm] stuartlewis: +1 [4:59pm] mhwood: +1 [4:59pm] • bradmc notes that he'll be on an airplane during the next dspace committer's mtg. [4:59pm] cwilper: +1 [4:59pm] grahamtriggs_: slight tangent (but still communication related) - have people seen this: http://www.yuuguu.com/home [5:00pm] stuartlewis: Virgin has wi-fi now [5:00pm] bradmc: JetBlue doesn't. [5:00pm] rrodgers: +1 (but I will also be away next week) [5:00pm] grahamtriggs_: +1 [5:01pm] • bradmc thanks grahamtriggs_ and gets ready to investigate. [5:01pm] bradmc: Last topic was to be merging 2.0 processes back into 1.0. However we're at one hour, and mdiggory couldn't make it, and I suspect he'll have a few points to make ... [5:02pm] mhwood: Tabled until next week? [5:02pm] bradmc: I think so. Last thoughts anyone? [5:03pm] bradmc: We seem to have done a decent job of interleaving this meeting, which although slightly cognitively jarring, is an efficient use of time. Is everybody comfortable with this? Should we actively encourage or discourage it? [5:04pm] mhwood: I think there's a limit to how dense an interleaving the average brain can handle. [5:04pm] bradmc: Agreed, I guess my question is should we aggressively close each topic, or use today's looser, "look-ahead 1" style? [5:05pm] mhwood: Try for closure but not insist on it? [5:05pm] bradmc: I'm happy to do that. [5:05pm] stuartlewis: I'm easy - both methods have worked, but today did seem more efficient. [5:07pm] mhwood: I think we just need to keep the context switching rate down to human scale. [5:07pm] rrodgers: I'm always slightly interleaved anyway, since I can't type (always composing the last reply when the topic has moved) [5:08pm] bradmc: Thanks everyone. I'll miss next week, can somebody volunteer to moderate? [5:08pm] mhwood: I will. [5:09pm] bradmc: Thanks, Mark. [5:09pm] mhwood: You're welcome. It's on my calendar. [5:10pm] mhwood: I need to go. Thanks, all! [5:10pm] rrodgers: Bye all [5:10pm] rrodgers left the chat room. [5:10pm] stuartlewis: Bye [5:10pm] mhwood left the chat room. ------------------------------------------------------------------------------ _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
