[doap-interest] Stuff I'd like to model

[Edd Dumbill]

On Wed, 2004-07-28 at 16:46 -0500, Shaun McCance wrote:
> Branches
> I'd like to be able to specify branches of programs, not so much in the
> CVS sense (though I'll come to that later), but the "series of related
> releases" sense.  So 2.6.0, 2.6.1, and 2.6.2 would all be on the 2.6
> branch.  2.6.2 could very well be released after 2.7.0.  This is common
> practice.  What's on a branch might vary from project to project (i.e.
> bug fixes only, features but no incompatibilities, etc.).  That sort of
> information isn't useful to me at the moment, but it might be useful to
> others.  Perhaps series is a better term for this.

I had hoped that the release stuff in DOAP would be able to cope with
this as a minimum

<release>
  <Version>
    <name>2.6</name>
    <created>2004-08-05</created>
    <revision>2.6.1</revision>
  </Version>
</release>

Perhaps the problem here is that Version/name might be better named
Version/branch?
    
> Aggregate Projects
> I'd like to model the GNOME Desktop as a Project.  It doesn't have any
> single CVS location, or any single tarball.  Rather, it's a collection
> of other projects.  In particular, I'd like to say that the GNOME 2.7.x
> series contains the gnome-desktop 2.7.x series, the metacity 2.8.x
> series, the yelp 2.6.x series, etc.  Also, that the GNOME 2.7.4 release
> contains gnome-desktop 2.7.4, metacity 2.8.1, yelp 2.6.1, etc.

So maybe we want a subclass of Project (say, MetaProject?) which is able
to say, for each subproject;

<contains>
  <Project>
    <homepage rdf:resource="..." />
    <release>
      <Version>
        <name>2.6</name>
      </Version>
    </release>
    <rdfs:seeAlso rdf:resource="..." /> <!-- ptr to subproject DOAP -->
  </Project>
</contains> 

Maybe it isn't even necessary to subclass.

> Branches and Tags, CVS Style
> It's common practice to tag releases in CVS.  So to get Yelp 2.6.1, you
> can check out the yelp module with the tag YELP_2_6_1.  I'd like to give
> the CVS tag for any particular doap:Version.  Along the same lines, it's
> common for continued development of a branch/series (as above) to happen
> on a branch in CVS.  So I'd like to give the CVS branch for continued
> development of a series.

Am thinking that an extension cvs: namespace might be handy to get this
sort of metadata in.  I mean to write up guidelines on extending DOAP in
this sort of way.

> Subprojects
> This is similar to aggregate projects above.  In fact, they can probably
> both be modelled the same way.  It's just a matter of what level the
> actual tarball releases are made at.   So gnome-utils contains logview,
> gsearchtool, gdictsrc, and gfloppy.  These are sort of projects in their
> own right, sometimes even with seperate maintainers, but they don't have
> their own CVS module or tarball releases.

Tricky.  If they have their own homepages then they are Projects in the
DOAP sense.  If they don't because they're too insignificant, then they
are probably a new entity which we could call a Component and think
about defining in some other way.

> Documentation
> DOAP provides doap:documenter, which is nice.  But it doesn't provide a
> whole lot of information about the documentation itself.  Documentation
> can be a project in its own right, and I'd like to model that.

Right.  And where it's available in HTML online, it'd be nice for DOAP
to link to it in a meaningful way.

> Nautilus
> doesn't have its own documentation.  Rather, the documentation for it is
> in the GNOME User Guide, which is shipped in gnome-user-docs.  Even for
> projects that do ship their own documentation, I'd like to consider the
> documentation to be a subproject (as above), and link them.

Maybe this might be best solved by an extension namespace to deal with
documentation issues.  The subproject then may or may not be required.
e.g. there are various HOWTOs which aren't official subprojects in any
way.

-- Edd