Below is the transcript of a committer's meeting held on #dspace at irc.freenode.net at 16:00 GMT on June 3, 2009.
We intend to hold the next meeting on #dspace June 10 at 20:00 GMT. 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: Discussion of timeboxing the feedback for 1.6 areas (embargo, batch edit, stats) due to general lack of response. Suggestion to declare strawperson proposals to stimulate feedback. GSOC update and proposals for weekly reporting on progress. Quick update on DS2.0 (some reorg of code going on this week), and discussion of when to declare the 1.6 schedule. Transcript: bradmc: Hi Folks, topics for today's Committer's session? [12:05pm] mhwood: Left over from last week: access control. [12:06pm] StuartLewis_: DS2 update? [12:06pm] rrodgers: Not sure it needs to be a topic, but I can update about 1.6 stuff & GSOC [12:07pm] bradmc: Sounds good. I'll try to leave it to mdiggory to update on DS2. Confession: I'm multitasking, as I'm presenting in a Sun Webinar simultaneously. [12:08pm] bradmc: Shall we start at access control? [12:08pm] StuartLewis_: A quick update on embargo feedback would be great [12:08pm] rrodgers: OK - set up a wiki page and have 2 good responses so far [12:09pm] rrodgers: Although I was hoping to get a bit more in the way of community needs [12:09pm] mhwood: The community seems quiet the last few weeks. [12:10pm] StuartLewis_: Think the feedback for stats & be [12:10pm] mdiggory_: I think its difficult to get feedback from the community in WIKI pages unless you have serious stakeholders [12:10pm] rrodgers: Maybe I should time-box the problem to encourage input a la stuartlewis [12:10pm] StuartLewis_: atch editing has been the same ? [12:12pm] rrodgers: mdiggory_: agreed, but how to reach out to them? [12:12pm] mdiggory_: perhaps you should setup a survey and ask more specific questions about embargo needs or somehow we can inspire the Community Outreach Commitee to spearhead getting feedback from the Managers on steriotypical embargo needs [12:12pm] bradmc: Time-boxing may make sense; are we up against a commencement season issue? [12:15pm] bradmc: Would declaring a straw person plan of execution generate a sense of urgency and foster responses? [12:15pm] mdiggory_: Eventually, the assessment will need to come from us, and if theres limited community feedback that means either (a) they don't care or (b) its detail that is over their heads [12:16pm] mdiggory_: bradmc: sounds like a good idea [12:16pm] StuartLewis_: +1 [12:16pm] rrodgers: I can work on a strawman - but I didn't want to close the option space prematurely [12:17pm] mhwood wonders if the concerned users have migrated to something on dspace.org and aren't following the traditional mailing lists. [12:18pm] mdiggory_: I think the community is looking for leadership from us on resolving these issues, so expecting a lot of feedback on which choice is right may be an unsuccessful approach. [12:19pm] StuartLewis_: I suspect 85% of users know they want an embargo feature, but don't know much more than that. Presenting them with a possible solution may help inform them. [12:19pm] mhwood: That sounds like stat.s too. [12:19pm] mhwood: Or laying out the options. [12:20pm] StuartLewis_: And batch editing [12:20pm] rrodgers: OK - we will pursue that. [12:20pm] mdiggory_: I've tried to do that with both Embargo and Stats from the @mire side. Theya re both projects we have active work on to contribute [12:20pm] StuartLewis_: I've got more feedback from my working prototype than from my initial request for feedback. [12:20pm] rrodgers: stuartlewis: w/r/t batch editing, we should have an ItemUpdate tool that ought to complement the spreadsheet stuff.. [12:21pm] StuartLewis_: rrodgers: What would it do? [12:22pm] mdiggory_: If by ItemUpdate tool you mean something thats like REST for Items, I'd say that would be what I would base work on Batch UPdate upon [12:22pm] rrodgers: Set or clear metadata & bitstreams from an input tree (like ItemImport) [12:23pm] bradmc realizes he's down to one personality. [12:23pm] rrodgers: So that it operates on granularity below the Item [12:24pm] mhwood: A common interface that can be fed by a variety of external tools sounds good. [12:24pm] mdiggory_: rrodgers: I agree, but think we want to have some synergy between this and orther projects like GSoC REST for DSpace etc [12:25pm] StuartLewis_: Batch edit could do that for metadata I think, as I'd like to see if be able to act on identifiers other than itemid. E.g. it could act on owning collection. But a dedicated tool would be nice. I'm sure lots of people will ask for it to deal with bitstreams too, but not sure if that is out of scope for a csv based solution. [12:25pm] mhwood: Commandline tool layered on top of service? [12:25pm] bradmc: mhwood +1 [12:25pm] mdiggory_: REST is a design guideline more than a service, this a mistake many make [12:26pm] mhwood adds to his reading list. [12:26pm] rrodgers: StuartLewis_: the goal isn't to put it all in one tool - but have a toolbox for batch operations... [12:27pm] StuartLewis_: Yes, definitely. Just I hope it will be flexible enough to do it anyway. [12:27pm] mdiggory_: mhwood: but what you point out could be a result of approaching it that way [12:29pm] mdiggory_: rrodgers: stuartlewis I guess the challenge is if you talking about batch services on top of hte existing Data Model, or integrated into it? [12:29pm] mdiggory_: I assume on top of it? [12:29pm] rrodgers: Not sure what you mean [12:30pm] rrodgers: I'm not proposing any changes to the data model or API... [12:30pm] StuartLewis_: The code only sits in org.dspace.app.bulkedit and makes no other changes. [12:30pm] mdiggory_: well, right now, take Item for instance, it removes and adds all the metadata for the Item on every update of the Item metadata. [12:31pm] mdiggory_: which is rather inefficient for updating... [12:31pm] rrodgers: But that doesn't preclude field-specific operations [12:31pm] StuartLewis_: Yes - yuck. And IIRC there is no way to remove one metadata element. You have to clear them all, then reload them all. [12:32pm] rrodgers: No no - you just read what's there and replace what you want & write back... [12:32pm] mdiggory_: So you mean "on top of the Data Model" [12:32pm] mdiggory_: as is [12:32pm] StuartLewis_: Yes - thats what my code does. But would be nice to remove individual elements to be more efficient. [12:33pm] rrodgers: Efficiency here is relative to doing it in the Admin UI [12:33pm] StuartLewis_: True! ? [12:34pm] mdiggory_: But IMO its thes sorts of shortcuts that continue to propagate and promote a bad design [12:35pm] rrodgers: It's not a shortcut - it is using the existing API. I completely agree that that could be better, but that's why we have 2.0 [12:36pm] mdiggory_: the assumption that everything can be solved by limiting it to an administrative activity results in a system that does not scale and processes that are inefficient to perform. [12:37pm] mhwood: By "administrative activity" you mean: a human sitting at the web UI and pushing buttons? [12:38pm] mdiggory_: by administrative activity I mean "can only be done by "Repository Administrator" role [12:38pm] mdiggory_: but... hey this is a design discussion that I may have inadvertently dragged us into... [12:39pm] mdiggory_: and something we should do in the batch_update project?! [12:39pm] mhwood: The line between architecture and design detail is sometimes blurry. [12:41pm] mdiggory_: Ok, maybe its best to activate another topic [12:42pm] StuartLewis_: I'll send a copy of my code out to devel later this week and will be happy to receive comments. [12:43pm] mdiggory_: DS2 update, we are working on a few things this week [12:43pm] rrodgers: OK on GSOC, I contacted Andrius and he is still cleaning up from some finals, but is starting to look at the new landscape [12:43pm] mdiggory_: ok... GSOC first [12:43pm] rrodgers: Sorry, you go ahead if you want [12:43pm] mhwood: OK, but it sounds like we all need to have some common ideas of what sort of details lead us in the 1.6 -> 2.0 direction and what would be leading us away from it. [12:44pm] mdiggory_: I think in terms of GSoC we need to work to get the students more communicative in the community. [12:44pm] mdiggory_: I understand Andrius operated on a later schedule last year and I suspect this is the case for the students this year [12:46pm] rrodgers: Yes, I think that will recur this summer [12:46pm] mdiggory_: I do not have a tremendous amount of time to lead GSoC activities to promote getting everyone engaged and in conversation with each other this year. Thus we are have not even yet held a meeting to welcome everyone [12:47pm] mdiggory_: I wonder if we can at least be getting more regular updates from both mentors and students, for instanc eon a weekly basis [12:48pm] StuartLewis_: Yes - would be good. [12:48pm] rrodgers: I'm bandwidth-limited as well, but should we make it a standing part of this meeting? [12:48pm] bradmc: +1 rrodgers [12:49pm] StuartLewis_: +1 [12:49pm] mdiggory_: One of the topics to talk about with DSpace 2 is that we are considering consolidating the dspace-architecture list into the dspace-dev list and using "subject" headings to classify the discussions, I wonder if we should do that for GSoC as well. But I get the sense that students are "shy" and mentors tend to end up working in private with them rather than via the list. [12:50pm] mdiggory_: Is there some way that would be more efficient? [12:51pm] mdiggory_ considers maybe we mandate all email communication be done in dspace-dev for GSoC and that mentors enforce this? [12:52pm] mdiggory_: by enforce, I mena mentors tell students to use list for email communication [12:52pm] StuartLewis_: Some communication is not suitable for public dissemination, but on the whole, yes, that would be good. [12:52pm] StuartLewis_: Might also foster more use of dev by other users on their own projects which would be good to see. [12:53pm] mdiggory_: stuartlewis: yes we are starting to see that already (Authority work) [12:55pm] StuartLewis_: We could also try to encourage people to post with other tags (e.g. 'whatimworkingon to be able to give details of small local proejcts they are doing that other people may be interested in) [12:56pm] mdiggory_: Ok, not much time left for me. Looks like we have about 5 minutes [12:56pm] rrodgers: I'd be happy to encourage (rather than require) students to CC dev list with a tag or tags... [12:57pm] mdiggory_: I would like to encourage students to work publically, this is an aspect of working on Open Source that GSoC is supposed to promote [12:57pm] rrodgers: I worry (as mdiggory_ did) that they will be intimidated and communicate less if we require it [12:58pm] StuartLewis_: We've required short weekly updates in the past - that would be a good start. [12:58pm] mdiggory_: I think it has to do with how its presented to them. I.E. "More Eyes makes Design Easier", "More Eyes makes your Project Better" [1:00pm] mdiggory_: "More Eyes makes for Better Solutions" "More Eyes make for a Better Grade" [1:00pm] mdiggory_: "Mo Eyes = Mo Money" [1:01pm] StuartLewis_: Shame there is no grades of payment to help encourage this! ? [1:01pm] mhwood: I think "more eyes" is a turn-off. Getting help in generating ideas sounds more attractive. [1:01pm] mdiggory_: Well... theres the midterm evaluation and rejection of that project. [1:02pm] mdiggory_: Failure at Midterm = No Mo Money [1:02pm] StuartLewis_: Failure is drastic though. Would be good to have a half way house. [1:03pm] StuartLewis_: But this is the wrong venue for that discussion! ? #gsoc [1:04pm] StuartLewis_: DS2 update? [1:04pm] mdiggory_: stuartlewis: I tend to agree with you, but Google seems to want to keep things more Black and White [1:04pm] mdiggory_: DS2 Update... [1:04pm] mdiggory_: We are reorganizing some of the dspace 2 project structure in the next [1:04pm] mdiggory_: week [1:05pm] mdiggory_: in preparation to be able to support more community project involvement [1:05pm] mdiggory_: this will mean separate svn project spaces for what is considered "core" and "modules" [1:06pm] mdiggory_: we are redeveloping the data model a little to support working with metadata at a more granular level [1:07pm] mdiggory_: I.E. StorageEntity is becoming less of a Container for properties and more just an Identifier representing a resource in the system [1:08pm] mdiggory_: StorageService interfaces are morphing to support querying and update of properties (and this will probibly be across entities as well) [1:08pm] mdiggory_: Thus it addresses some of rrodgers comments about batch update earlier int he chat [1:09pm] mdiggory_: we are working on designs for an executable jar deployment strategy that will work similar to Apache Sling / Jackrabbit that will initialize and launch an isntallation [1:10pm] StuartLewis_: That sounds cool. Will be welcomed by many. [1:11pm] mdiggory_: On an aside there is vary interesting thread in the ORE discussion list about ORE, DSpace and TAMU Harvester I'd recommend listening in on. [1:11pm] mdiggory_: http://groups.google.com/group/oai-ore/browse_thread/thread/20d75d231ab27ccb/a3a3e3d51da38139?pli=1 [1:12pm] mdiggory_: Which is another topic... for DSpace 1.6 is there a timeline [1:12pm] mdiggory_: and a tentative release date? [1:13pm] mdiggory_: I.E. should these projects that we want to see in 1.6 somehow be "scheduled" [1:13pm] rrodgers: I'd say not until we have a concrete sense on Stats, embargo & batch edit.. [1:14pm] StuartLewis_: Maybe try to time it for the DSUG... in October is it? [1:14pm] StuartLewis_: Does that sound realistic? [1:14pm] rrodgers: That doesn't sound too scary to me [1:14pm] mhwood: I think that the projects need a timeframe to shoot for, to help decide how much work can be accomplished. [1:15pm] StuartLewis_: Jun-Jul-Aug development, September test / refine, October release? [1:16pm] mdiggory_: I would say that should be when we announce what will be in the release and announce the release plan [1:16pm] mdiggory_: I.E. June, July, Aug, Sept for development [1:16pm] mdiggory_: October freeze [1:16pm] mdiggory_: November release [1:17pm] mdiggory_: where is DSUG? [1:17pm] rrodgers: Sweden [1:18pm] mdiggory_: A final topic before I have sign off, the Authority work of Larry Stone and Christophe Duprez is at a point where we need to talk about commit rights on prototype branches in OSL. [1:18pm] StuartLewis_: Either the final launch, or the first RC launch at ~DSUG would be a good morale and community booster. [1:18pm] mdiggory_: With the new svn repository, we need to discuss organizizng the sandbox and policies around it [1:19pm] rrodgers: I don't oppose that, but I have to run now - can we put on the top of next agenda? [1:19pm] mdiggory_: StuartLewis_: Yes, an RC would be good at that point [1:20pm] mdiggory_: and because we had setup a freeze, there would be a fixed list of new feature for 1.6 that could be announced at the conference [1:20pm] StuartLewis_: And LiveCDs given out containing the RC for people to try, and encourage testing? [1:22pm] mdiggory_: Per SVn, I have not yet created a "prototypes" sandbox for working on new branches. But I expect we can do so fairly easily, what I'm looking for from the committers is agreement on allowing new committers in that space and possibly a fast-track process for getting that decided on [1:22pm] mhwood: RC at DSUG sounds like a good plan and a useful target. [1:24pm] mdiggory_: For instance: developers int he community who want to work on prototypes can request access to create a branch in a /svn/repo/prototypes or /svn/repo/dspace/prototypes location within the OSL repository [1:24pm] StuartLewis_: +1 for giving people access to their own prototype branches, one of the big reasons we moved to our own SVN [1:24pm] mdiggory_: and have commit rights ont hat branch [1:25pm] rrodgers: +1 as well, with details suitably ironed out. [1:25pm] rrodgers: bye all [1:26pm] mhwood: Yes, much easier to work on addons in a common SCM. [1:27pm] mdiggory_: Yes, with a common history operating in the same svn space, merging does become easier [1:28pm] mdiggory_: Ok, I need to sign off now as well. I think I will draft an email for feedback on the listserv so that there can be a feedback period longer than this meeting [1:28pm] mhwood: Thank you. [1:29pm] mdiggory_: Great meeting. Thank you too. [1:29pm] mdiggory_ returns to lurking for the moment [1:29pm] bradmc: Thanks all, and thanks for the moderation support! ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
