[Xesam] Request for an overview

[Evgeny Egorochkin]

On Thursday 23 July 2009 17:59:46 Philip Van Hoof wrote:
> We had a conference where we discussed several things. I was just
> checking the current status. We was me, Jürg, Sebastian Trüg, Rob
> Taylor, Ivan Frade (if I missed somebody, let me know. Not sure if Jos
> Vandenoever also discussed ontology with us).
>
> What I noticed so far:
>
> - Apparently has a project called OSCAF been setup on sourceforce.
>
>   http://sourceforge.net/projects/oscaf/

This is not news ;)

> - Although I had the impression that at the conference most people where
>   reluctant to opt for trac, trac is nevertheless being installed as the
>   ticket system.

It isn't being installed in the sense that it was installed quite some time 
ago. In fact, Roberto Guido felt it was either a consensus decision or a 
significant number of people abstained because it was more of a bikeshed 
argument(more likely) and he proceeded to transfer open tickets from 
semanticdesktop.org to oscaf.sf.net ~4 weeks ago.

>   I don't know how 'okay' this is for all people. My impression at least
>   was that this isn't ok.

Now I don't know either ;)

> - I also had the impression that most people would prefer git,
>   nonetheless is SVN being installed as repository. This is probably not
>   a very big issue, just pointing out.

It's not being installed, it's the only option offered by sf.net at this 
moment, although my bet is they will eventually give in to people asking for 
git.

> - Sebastian has starting implementing the layout changes that we
>   discussed at the conference. This is nice, thanks!
>
>
> Important items that we need:
>
> o. Formal decisions on branch management. Apparently is Evgeny's opinion
>    (discussion on IRC) that trunk should be stable, and that development
>    happens in branches. Sebastian Trüg's (and my opinion, too) appears
>    to be that trunk is development and we'll have stable version
>    branches.

Maybe I was misinterpreted. My opinion on trunk is "no ticket -  no commit" 
policy which I already proposed. That is no commits without discussion. This 
doesn't guarantee stability though.

Some stability would be provided by unstable/xesam branch, which means we can 
decide to break it but are reluctant to do it and therefore we cherry-pick 
patches appropriately. More stability would be provided by stable/nepomuk 
branch which should be stable enough to make hairy-pointed bosses happy.

As to having various experimental branches, they are useful if you're working 
on a proposal(and I'm already using git for this).

Getting your proposal accepted is another matter. You need to show your 
proposal to other people, and this is what git could do. But you also need to 
document the decision-making process itself, which means you have to submit 
your patch as text, not a commit ID, to the issue tracker so that people could 
comment on your ideas and your implementation.

Moreover, discarded proposals are nevertheless useful because it lets people 
not repeat what's been done already, lets you revive discussion if you find a 
way to fix some of deal-breaker flaws that were found.

Having lots of stale branches in official git repository with discarded patches 
is not as tidy as having tickets which don't get in the way, yet can be easily 
fetched.

The point of a standard is *getting rid* of branches. trunk/unstable/stable 
should be essentially snapshots of the same and the only branch.

>    I conclude that there's no conclusion on this, and that we should
>    soon make a decision. This will of course matter for the projects
>    depending on the shared ontology project.
>
> o. A decision on the bugtracking system (this is urgent)

As long as somebody handles one more data import, I won't object too much. My 
vote is probably not so much for Trac but against Bugzilla because it's 
outright unfriendly, hostile and lacks lots of nice features that are helpful 
to our project and are provided by Trac.

Please consider the fact that our tracker is not a bug tracker, but an issue 
tracker. This means we are going to have a lot more documentation-like lengthy 
posts than short one-line comments.

The difference would be probably much like wikipedia as it is now vs its 
plaintext dump. It woul be affected much more than a twitter dump.

Plus some minor but very convenient features specific to issue trackers like 
ability to provide an actual link to a commit you can view using changeset:#, 
easy to use reports, integrated wiki which can easily reference tickets and 
commits for some low-level technical data.

> o. A product in that bugtracking system

Trac at oscaf.sf.net is totally under our control. We can add whatever we 
please anytime.

> o. A component for each ontology on that product

Again, mostly done(NAO, NRL, NMM, new ontology drafts) although we still keep 
NIE ontologies we inherited as a single product. It's a matter of ~15 minutes 
to split it up I guess.

>   o. Each component will have a default assignee

Agree.

>   o. Some of the developers will be put in CC for all ontologies

Agree

>   o. Patches containing Tracker's initial ontology-change requests. We
>      have quite a few change requests already, indeed.

Trying to process and document them, just don't know where ;)

> o. Structural decisions on who will maintain what

Already sort of agreed when it comes to ontologies. At least I can commit to 
back up any effort that falls apart till at least the end of this year.

When it comes to infrastructure, we don't have anyone who decided to be 
responsible as opposed to just helping here and there. This is gong to be more 
of an issue for some time if oscaf.sf.net is abandoned.

> o. The layout changes (but Sebastian already started this, awesome!)

And he'll definitely finish it soon.

>   o. Build environment ( remember autotools being mentioned)
>   o. The TriG files and the directory layout for them
>   o. A file describing the dependency tree of the ontologies

Probably worth a separate discussion. Overall I object this because it can't 
be made to work 100% of time: ontologies can have circular dependencies, you 
might want to accept 3rd-party ontologies, such as applications installing 
data extractor plugins. Better load all ontologies at once and validate at 
once or whatever you want to do with them.

At least in C++ it's trivial to first populate a dataset like 
map<string,map<string,set<string> > > and then extract whatever ontology bits 
you find useful.

>   o. Documentation about custom ontology install procedure
>   o. Tools for generating documentation (part of the build environment)
>
> I noticed some confusion on who is doing what, how what is being done
> and where it is being done. Therefor I think it would be useful if
> people would (more clearly) point such things out on this mailing list,
> and use it more often to articulate decisions made at conference
> meetings (as these days they are happening, at a high frequency).

+1

-- Evgeny