Child pages
  • Committers Call 2011-07-18
Skip to end of metadata
Go to start of metadata

Participants

Bess Sadler
Eddie Shin
Matt Zumwalt
John Scofield
Justin Coyne
Julie Meloni (notetaker)

Agenda

Scheduling this Call (& what it is, vs others)
Hydra cModel vs AFModel
State of Active Fedora
HYDRA-541: enhancing relationships convenience methods
Jira Review: Weekly sprint for 19 July

Notes

Scheduling this Call

After last week's Doodle Poll resulted in no clear change, we decided to set up another Doodle poll that included the top choices plus a new addition: 8:30am PDT/11:30am EDT (starting the call a half-hour later than we do now).

The link to the new poll is: http://www.doodle.com/tb62vsigidshsbkh

Everyone who wants a voice in the date/time should vote again; we will make a decision on Thursday and send the (potentially new) call time to the list on Friday, July 22nd.

To reiterate the purpose of the committers call: Jira review, public announcements, large questions of concern to all

Hydra cModel vs AFModel

Take a look at the whiteboard photo Matt sent to the list. (email: "Whiteboard Hydra cModel vs AFModel"). This came out of work going on with Hydra in Hull, and has to do with setting up a configuration layer to tell ActiveFedora "if you see this combination of cModels, treat it as this AFModel". Currently, the AFModel is what points to a Ruby class, while the cModels are there as documentation; with this change, you can inspect a cModel and tell it what to do. This does not change any existing work/workflow but instead allows for flexibility and new possibilities moving forward. For example, dropping Hydra on top of existing Fedora reposiory & not have to touch a bunch of cModel/AFmodel definitions.

State of Active Fedora

Some problems with ongoing/incomplete work that is in master & also in a released version of the gem brought up issues in Git workflow. The problems in brief have to do with environment variables, configuration files, order of load, and cascading issues caused therein especially when cases are not tested (see Bess's previous emails "default environment?" and "let's write shorter more testable methods"). Bess is going to continue her work in these areas because a fresh pair of eyes on this code is useful to everyone. However, eyes of someone more familiar with the code itself are also necessary to look at the changes made. John/Matt are going to look over solrizer-fedora changes, Eddie will help with init issues and look over work on ActiveFedora. Goal is to get solrizer-fedora and ActiveFedora in sync and in use to avoid bottlenecks in ongoing work (especially in Hull).

More on Git Workflow

The Git workflow diagram that was passed around before was discussed again in general (http://nvie.com/posts/a-successful-git-branching-model/) but discussion centered around the most basic guidelines: develop in a branch, make major changes in a branch, others look over work before a merge to master, nothing merged to master until more than one person (yourself) looks at it. "Major" defined as new features and refactorings; bug fixes are not (typically) major.

Matt reiterates the Guidelines for Committers and points out the link to Diaspora's workflow especially as concerns rebasing. Julie is going to look at the content in the Guidelines and see if we can't make things more clear/more useful.

For Next Week

  • We will focus on Jira review first, followed by additional announcements/questions.
  • No labels