Team,
I want to comment as I missed the meeting this morning... Excuses
CC'ing other interested parties as well.
On Wed, Jun 17, 2009 at 10:11 AM, Bradley McLean<b...@dspace.org> wrote:
> Bradley McLean wrote:
> [12:13pm] mhwood: There was unfinished talk about how the social
> structure of DS2.0 development may currently differ from what we're used to.
> [12:13pm] rrodgers: I told him that the group felt DS2 was the place to
> concentrate.
Excellent, and I will be volunteering my support in this area as well
now that he is ready to ramp up. I recommend that we recommend a
different approach for Andrius given his past expereince with DSpace
development. IMO, once properly organized, the DS2 workspace will be
ready to support a "provider" project for the Fedora/DSpace Storage
Implementation. I propose that Andrius work directly within this
DS2/provider project space and we add his work to CI and build
processes for DSpace 2.0 as his code evolves and is testable.
I also recommend that we (and he) engage with Chris Wilper about this
working against their mavenization efforts with Fedora. I'd like to
see us arriving at a "distribution" by the end of his project that
includes DSpace and Fedora deployed in concert.
> [12:14pm] rrodgers: Second, on 1.6 - unless I hear anything else within
> a few days, I'll post a straw man for Embargo, as we discussed
> [12:14pm] rrodgers: in order to focus thinking
> [12:15pm] rrodgers: I'm done
> [12:17pm] mhwood: 1.6 statistics: I see that a lot of material has been
> added to the wiki page. kshepherd: I owe you a response to an email. The
> lists have been quiet.
> [12:17pm] bradmc: mdiggory doesn't seem to be with us today; I don't
> know that we'll get to the social structure answers. My sense is that we
> need to orchestrate a hand-off from the JISC funded team to the DS (DS1)
> community, and then operate in the DS1 fashion. The JISC phase is ending.
To be clear, the members of the DS2 JISC developer team are "not going
away" even though the round of JISC funding is coming to an end.
Certain members may reduce activity from this point going forward, but
Ben, Myself (and I assume Graham) will remain active.
I'm not convinced yet that the DS1 monolithic release management
approach will be wholly applicable here and it will have to be
adapted. We started this intiative in the DS1 project space be
pealing off language packs and recommending the development of new
modules under the "modules" space in the svn repository, these modules
have different release cycles and decision making on appropriate
release time. There DS1 activity that is most critical to bring over
is the release management cycle (and designated release coordinator)
for new distributions not the monolithic project management approach.
I am still reorganizing the project space to support greater
separation or core and addon modules and likewise a release strategy
to support asynchronous release of individual modules independent of
the core. (I.E. Maven like release of plugins) and a separate project
space for constructing distributions from the modules.
I want to see the structure for this in place prior a DS1 release
management model getting activated (I expect to have this completed
within the next couple weeks). IMO a DS1 release management model will
first apply to the Kernel and portions of the Core, not the individual
addon and ui projects.
I feel:
1.) Each project area (kernel, core, module/xxx) should have a
"Release Coordinator" that manages new releases of that module.
2.) There will be a "Distribution" project that brings together the
appropriate modules that constitute a "release". I expect this
project to have an "overarching release coordinator".
3.) The sandbox, et al. will be a space to incubate both new
prototypes, but also new modules within the community.
> [12:18pm] bradmc: (That's all on DS2)
> [12:18pm] rrodgers: Seems like a reasonable strategy
> [12:19pm] catobear: rrodgers: Thanks for letting me know; I'll post
> again in an hour
> [12:20pm] bradmc: So, as with all handoffs or releases, there's a bit of
> a struggle to get to the right state for the handoff. That's still under
> debate.
There will be a tremendous amount of overlap given that the developers
are still involved though the funding model has changed. My concern
is presenting this to the community as if it were the case that
developers were not going to stay involved. Thus MWoods concerns
below about "Orchestration". IMO, in the developer community,
developer focus on the project is neither waning nor changing hands,
but instead "expanding". The effort is more to bring DS1 developers
under the umbrella of DS2 work activities, train them on how to work
with the software and get feedback/contribution from them to
accelerate development. And an excellent byproduct of this initiative
would be the creation of documentation on the build process and how to
contribute. In some ways, to attain this, I feel it would be
excellent to have a guinea pig or trail blazer with enough interest in
DS2 to allow us to use them as a trainee. I'm looking across the room
at RRodgers and Andrius while saying this ;-)
> [12:20pm] mhwood: Orchestrate how? What's needed?
> [12:21pm] bradmc: A how-to-get started wiki page, an agreement to move
> communications into the DS1 lists and close the DS2 lists, and a
> baseline release tag.
> [12:22pm] bradmc: Then, a subsequent set of discussions in the merged
> community on what next, as well as any social changes (evolving from
> DS1) that are desired.
Yes... very soon, and these decision need to be inclusive of both
groups (because they actually have much of the same membership)
> [12:23pm] rrodgers: Indeed - in fact we may be looking at a 3-way merge
> with some Fedora stuff as well...
> [12:24pm] rrodgers: (primarily - I would assume - in the area of common
> services)
> [12:24pm] bradmc: rrodgers: Yes, although that seems like a subsequent
> conversation (just for clarity).
AS I propose above. I think this should be engaged in the devel list
with Andrius and other interested parties to secure a very successful
and immediately usable integration in DS2 that may be presentable at
the DSUG meeting next fall..
> [12:24pm] mhwood: Concurrently? Challenging. We can't work out a
> sequence, so we can deal with stuff pairwise?
It is already happening concurrently (or multilaterally) :-)
> [12:24pm] rrodgers: bradmc: true, it's complicated enough now
> [12:26pm] • bradmc dons his DuraSpace hat
> [12:26pm] bradmc: We have two distinct communities (Dspace and Fedora)
> with their own governance, and we aren't going to change that
> immediately. We will help any efforts to move in that direction.
To foster this, we need to have multiple individuals building bridges
into that Fedora community where ever possible. Chris, Dan and I have
had very interesting conversations at OR09. I want to see these
continue and broaden to include other developers and researchers. I
hope this is where the Duraspace Foundation might assist us. OR09's
parallel meeting made interaction between the communities challenging.
BoF helped some. But, ideally a summit that included developers from
both communities would be a very positive opportunity to focus on the
topic exclusively for a few days.
> [12:26pm] • bradmc takes off that hat
> [12:26pm] rrodgers: what's the view from Mt Olympus?
> [12:27pm] bradmc: So we should have DS1 and DS2 get their merged
> community issues sorted, then tackle the mix-and-match of components and
> tech with Fedora
I think there is a misinterpretation here. I think the topic of Fedora
parts in DSpace is not about merging communities but reuse of Fedora
as a 3rd party dependency in the DSpace GSoC project, focusing on 2.0
and exploring the problem space from the DSpace side. Because Fedora
is an independent application and the interaction with Fedora will
more than likely be driven through its web services initially. The
topic of merging development teams/communities is a very larger topic
with longer term scope that the DS2/Fedora efforts.
> [12:27pm] bradmc: Which should naturally lead to some ideas on how to
> organize those efforts.
> [12:27pm] mhwood: Modularity helps. Map out a minimal "spine" for the
> product with well-defined interfaces and let everything else be an add-on.
> [12:27pm] bradmc: mhwood: +1
> [12:31pm] mhwood: DSpace/Fedora sharing effort probably ought to
> concentrate on DS2.
> [12:31pm] bradmc: I think both DSpace and Fedora are moving towards that
> modularity, which helps. For the record, Fedora is moving to Maven as
> well, so we'll potentially have a framework for cross or shared
> dependencies and models.
> [12:31pm] bradmc: That just scratches the surface of the problem, however.
> [12:32pm] bollini-web left the chat room. ("CGI:IRC")
> [12:33pm] rrodgers: Speaking of which - we should probably spend some
> (not here and now) trying to give Richard Jones some guidance on his
> SWORD questions
> [12:33pm] bradmc: I think there's a challenge of defining a migration
> from DS1.x forward. DS2 seems a likely candidate for bridging to a
> shared DSpace/Fedora environment, but I suspect there is a real
> challenge in bridging out of DS1 to anything.
> [12:33pm] rrodgers: some +time
> [12:33pm] mhwood: First: compare the ways that the two products aim to
> be modular. How difficult to harmonize *that*? Can we readily get to a
> state where they can just share (some) modules, or will we need
> adaptation layers?
> [12:34pm] bradmc: mhwood: Well, it could be done on a piecewise basis,
> at various APIs; or it may make more sense to get two sides to embrace a
> common component architecture.
> [12:35pm] bradmc: Personal bias: a very lightweight one.
> [12:35pm] bradmc: There has been some interest around OSGi on both sides
> lately, but not any clarity yet.
Yes, this will evolve as the DS2 project organization stabilizes.
While a GSoC project around OSGi may have been interesting, its
important to note that the whole DS2 Kernel is designed to be
available and usable regardless of the Container that is providing the
intialization and configuration of that Kernel. IMO, any transition
to OSGi will not be dissimilar in implementation than the Spring/Guice
approaches. The use of Fedora components within DSpace suggests
integration at the Java level. This will be a very exciting activity
IMO, but should be done after the initial DS2 product has come to
greater fruition than it is at this moment lest it derail/stall the
development activity currently going on this moment.
I would like to know if anyone from the DSpace community is attending
the RIRI 2009 meeting?
Cheers,
Mark
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
