[Xesam] NRL; Need your input - Leo proposes to allow from now on only "one patch per ticket" because we are slow and discussion is endless

Evgeny Egorochkin phreedom.stdin at gmail.com
Tue Nov 17 16:57:44 PST 2009 

В сообщении от Вторник 17 ноября 2009 21:57:54 автор Leo Sauermann написал:
> Hi Peoples,
> 
> Evgeny - please send all ontology related emails to the xesam list.

This was not an email as such. It was a notification about a ticket which I 
feel needs urgent resolution and it isn't really related to ontologies 
themselves, rather backend implementations.

I did CC all people who I knew were involved with writing actual code.

> good news:
> I found out why we are so slow  -- and how to fix that.
> 
> its because we don't use patches, as every good project does.... how
> stupid of us.
> 
> I looked at the tickets and I found that some of the tickets carry an
> undertone of
> "something is wrong, can't exactly say what, we need to change
> everything, I think you guys did the ontologies totally wrong".
> 
> For example, here:
> https://sourceforge.net/apps/trac/oscaf/ticket/14
> This ticket contains:
> * a vague request to remove around 15 properties

Or you can look at it as a specific list of properties which I propose for 
removal or merging with their superproperties

> * very vague answers and comments about other properties.
> * many errors and unprecisely researched assumptions about what may be
> or what is or what should be done

This is too vague ;) and should be discussed on per-property basis with 
specific explanations.

When there were 2 identical properties I wrote property1 = property2, which is 
pretty self-explanatory. When there were more complex cases like date and time 
properties I tried to explain.

Taking one specific example you mention, nid3:length:

nid3:length
	a       rdf:Property ;
	rdfs:comment """TLEN
The 'Length' frame contains the length of the audiofile in milliseconds, 
represented as a numeric string.""" ;
	rdfs:domain nid3:ID3Audio ;
	rdfs:label "length" ;
	rdfs:range rdfs:Literal .

The posible issues are:

* type of nfo:duration. xsd:duration can store fractional seconds, and 
milliseconds as a consequence

* preserving the original content of the property in a literal instead of 
extracting the value. This really matters only if the value is malformed.

I don't think this is useful. If our specialized ID3 extractor can't make 
sense of the contents of the property, it's very unlikely that any other 
application will.

If there are any other issues with nid3:length that I missed, please list 
them.

> * an undertone saying that the approach of 1:1 compability with existing
> standards (ID3, EXIF) is totally yesterday and we must move on.

It's not about yesterday, it's about something being convenient to us. If 
there's already an established ontology like http://www.kanzaki.com/ns/exif I 
don't mind using it for compatibility with the outside world, but as you say 
inference is cheap which means we don't have to be tied to it.

I think making our ontologies interoperate seamlessly is a higher priority 
than seamless interoperation with outside ontologies.

> This ticket does not contain:
> * a precise N3 diff of what to remove and what to add to the ontologies
> (ha, because when you remove a property, you also have to add some
> comment saying why and what and how to do it now. a "deprecation
> message", you know.)

The process of deprecation wasn't established and even discussed at that time. 

When we actually decided to deprecate something [1], I filed one more ticket to 
establish the proper way to do this [2]

[1] https://sourceforge.net/apps/trac/oscaf/ticket/32
[2] https://sourceforge.net/apps/trac/oscaf/ticket/37

> If your read the discussion, you will notice that this causes us to mix
> political discussions ("be backward compatible or not") with concrete
> suggestions ("remove nid3:comments!") with general architecture changes
> ("we must have equivalent property relations or constraints").
> 
> Of course, as now 15 topics are discussed in one ticket, including
> political minefields, we will never reach agreement quickly.

> Of course, as you all know, in other projects such tickets would be
> immediately closed as invalid saying
> "submit a patch for a single bug and then we can talk".
> and these other projects took some years to come to this practice, you
> know how it works....

This is a problem indeed. There's however another problem: regardless of if 
you file 1 ticket or 10 tickets for each minor detail, they still remain 
closely related. You can't just close one without considering the rest.

So my approach was to post a "discussion" or RFC ticket to put everything into 
perspective and then split it into smaller and more specific issues.
Hopefully this eventually leads to documenting the entire decision space and a 
correct solution to the problem.

The ticket in question is tightly related or has directly caused the 
following, more specific, tickets:
https://sourceforge.net/apps/trac/oscaf/ticket/35
https://sourceforge.net/apps/trac/oscaf/ticket/42
https://sourceforge.net/apps/trac/oscaf/ticket/52

> To spare us more endless discussions, I propose that from now on, we
> only allow
> 
> "one issue per ticket and a patch to fix it"

Mandating a patch isn't necessarily a good idea. Taking it to extreme, 
consider a patch that would suggest using someother:string instead of 
xsd:string.

Compare the patch itself with its human-readable description. The effort to 
make the patch and the fact that *the patch has to be verified for correctness* 
and the easiest way to do this for a maintainer is take the textual 
description and make the patch himself.

It's often easier to read an explanation than the patch itself.

A real-world example would be NDO [3] which came with a patch, was a good idea 
but it got totally reworked.

[3] https://sourceforge.net/apps/trac/oscaf/ticket/4

> the ticket submitter must state her or his change request with a precise
> N3 statement saying what must be removed and what must be added
> (a "diff" or "patch")

Requiring patches is even more unfriendly to people outside of the core 
developers. You really need to know how everything fits together to make a 
proper patch which means that contributed patches will either way be discarded 
or reworked.

> if a submitter does not comply, the ticket is invalid and gone within a
> minute.

One more thing that projects accept gladly is feature requests. No they don't 
come with patches

> if the submitter does comply, a decision can be done within a week,
> because its only one decision, and its "yes/no".
> If the answer is "no", the submitter can try again with a slightly
> changed suggestion in a new ticket.

Which doesn't mean the discussion takes less time. You simply have more 
tickets with a faster turnaround.

> I don't have to remind you that this is how open source patching works,
> and that patches have the great property that there can be a "yes/no"
> vote on accepting them,
> and moving on with life.

A "no" may mean the patch should be modified, which means discussion.
The discussion has to take place somewhere.

One of ontology maintenance policies [4]  we have ATM says
"No ticket - no commit policy. This is important to document our decisions. 
Every change must be discussed in the issue tracker before being committed. 
Every comment of parties affected by the decision must be posted to the ticket 
regardless of the way the comment was communicated(email, conference etc). The 
exception to this policy is minor technical defects such as typos and 
formatting."

I have intentionally formulated it this way to concentrate all discussions and 
opinions in a single place: issue tracker.

If you enforce the patch policy it means that initial discussion and feature 
request happens elsewhere which makes it harder to find out why something was 
done the way it was done.

You could try an mark discussion tickets somehow like adding another ticket 
type: discussion. But then you can discuss defects, enchancements, tasks so 
it's not entirely correct.

Either way I'm not pretending the current policies are perfect, just explaning 
why they are like this.

[4] https://sourceforge.net/apps/trac/oscaf/wiki/OntologyMaintenance

> Also, it is common practice to allow only "one fix per patch".
> again, you all know why.

I agree with this. If there are several independent matters, it makes sense to 
make several commits.

> if you don't agree,
> please say so and suggest something better.
> 
> If you do agree,
> please give some positive feedback and your own view on this,
> rephrase my improper language and copy this into the wiki page:
> https://sourceforge.net/apps/trac/oscaf/wiki/OntologyMaintenance
> 
> and send an answer to this mail.
> 
> does this help?
> i hope it does.
> 
> best
> Leo
> 
> 
> 
> It was Evgeny Egorochkin who said at the right time 12.11.2009 04:46 the
> 
> following words:
> > Hi fellow Nepomukians,
> >
> > You input is needed on this ticket:
> > http://sourceforge.net/apps/trac/oscaf/ticket/52
> >
> > It involves some Nepomuk fundamentals such as NRL, so I'm trying to get a
> > bit more feedback than usual.
> >
> > Thanks!
> >
> > -- Evgeny
>

More information about the Xesam mailing list