Skip to end of metadata
Go to start of metadata

Meeting Details

  • Moderator: <moderator's login name>
  • Protocol: cds
  • Attendees:
    • cds
    • ima
    • msp
    • tig
  • Start: 14:15h
  • End: 15:40h

Agenda

Leftover ToDos from Last Meeting

  • The KEG editor actually does depend on the Pragmatics component. The graphic thus doesn't need to be changed.

Discussion

  • We like the idea of splitting the product into different components and repositories. In particular, the split we discussed in the previous meeting seems reasonable.
  • Miro isn't too fond of the idea of releasing the General component separately.
    • The solution is to release the General component together with the other, major components. Thus, not as a separate component.
  • Releases:
    • Developers in repository 3 develop against the latest release of repository 2, not the current source code. Repository 3 would release a month after repository 2 has released.
    • Both repositories release the then-current state of General implicitly.
    • Release repository 2 in odd months, repository 3 in even months. If nothing much has happened, don't release.
  • How does plug-in version management scale with an increased number of releases?
    • API tooling could be used. Miro found it to be slow and instable, however.
    • Miro thinks that with smaller components, manual version management would be feasible even with a two-month release cycle.
    • Tim thinks that developers responsible for a component can choose how they manage versions for themselves.
    • The General component might be a special case:
      • Versions must be changed instantaneously. As soon as someone changes stuff that justifies a version change, he must change the version immediately.
  • Management tools:
    • Confluence would keep a single space for the whole project.
    • Jira would get three different projects.
    • FishEye would have one project with three different repositories.
    • Bamboo would have two or three different projects. (repository 2, repository 3, complete RCA?)
      • Repository 2 could be built nightly.
      • Repository 3 could be built nightly against the most recent build tag of repository 2.
      • An RCA nightly build might not work. We might only be able to release a new RCA each time Repository 3 releases. That would be OK, since Repository 3 contains most of the demonstrator projects anyway.
  • Project split:
    • Miro strongly suggests getting rid of repository 1 altogether. The General component would be distributed to Repository 2 and Repository 3.
    • A problem would be what to make of core.ui.
    • Actually, Repository 3 would have to contain the Pragmatics component as well since it changes a lot and Repository 3 components depend on it. If that's the case, we're not sure if there are any advantages left of splitting the project in the first place.
    • Three options:
      • Don't split at all.
      • Split into Layout and Everything Else.
      • Go with the three-repository split.

Pros and Cons with Respect to Our Goals

We formulated our goals during the previous meeting. In this section, we discuss pros and cons.

Easier Development for Students

  • Contra: It might actually become more complicated for students (and developers in general) that are active in more than one repository.

Easier for Third Parties

  • Pro: Splitting the Layout component from the rest would make it easier for the rest of the world to use it.

Improved Management

  • Pro: Easier releases because of smaller releases.
  • Pro: No blocking between two different parts of the project.
  • Pro: More releases!
  • Pro: Less political delaying of releases: if the next release is only two months away, moving a feature to the next release doesn't hurt all that much.

What We Have to Do

  1. Miro prepares a proposal for splitting the project into Layout and Everything Else.
  2. We'll hold another meeting on what to do about Repository 3.
  • No labels